C y b e r A t t a c k s

“Dr. Amoroso’s fi fth book Cyber Attacks: Protecting National Infrastructure outlines the chal- lenges of protecting our nation’s infrastructure from cyber attack using security techniques established to protect much smaller and less complex environments. He proposes a brand new type of national infrastructure protection methodology and outlines a strategy presented as a series of ten basic design and operations principles ranging from deception to response. The bulk of the text covers each of these principles in technical detail. While several of these principles would be daunting to implement and practice they provide the fi rst clear and con- cise framework for discussion of this critical challenge. This text is thought-provoking and should be a ‘must read’ for anyone concerned with cybersecurity in the private or government sector.”

— Clayton W. Naeve, Ph.D. , Senior Vice President and Chief Information Offi cer,

Endowed Chair in Bioinformatics, St. Jude Children’s Research Hospital,

Memphis, TN

“Dr. Ed Amoroso reveals in plain English the threats and weaknesses of our critical infra- structure balanced against practices that reduce the exposures. This is an excellent guide to the understanding of the cyber-scape that the security professional navigates. The book takes complex concepts of security and simplifi es it into coherent and simple to understand concepts.”

— Arnold Felberbaum , Chief IT Security & Compliance Offi cer,

Reed Elsevier

“The national infrastructure, which is now vital to communication, commerce and entertain- ment in everyday life, is highly vulnerable to malicious attacks and terrorist threats. Today, it is possible for botnets to penetrate millions of computers around the world in few minutes, and to attack the valuable national infrastructure.

“As the New York Times reported, the growing number of threats by botnets suggests that this cyber security issue has become a serious problem, and we are losing the war against these attacks.

“While computer security technologies will be useful for network systems, the reality tells us that this conventional approach is not effective enough for the complex, large-scale national infrastructure. “Not only does the author provide comprehensive methodologies based on 25 years of expe- rience in cyber security at AT&T, but he also suggests ‘security through obscurity,’ which attempts to use secrecy to provide security.”

— Byeong Gi Lee , President, IEEE Communications Society, and

Commissioner of the Korea Communications Commission (KCC)

C y b e r A t t a c k s Protecting National Infrastructure

Edward G. Amoroso

AMSTERDAM • BOSTON • HEIDELBERG • LONDON

NEW YORK • OXFORD • PARIS • SAN DIEGO

SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYO Butterworth-Heinemann is an imprint of Elsevier

Acquiring Editor: Pam Chester Development Editor: Gregory Chalson Project Manager: Paul Gottehrer Designer: Alisa Andreola

Butterworth-Heinemann is an imprint of Elsevier 30 Corporate Drive, Suite 400, Burlington, MA 01803, USA

© 2011 Elsevier Inc. All rights reserved

No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. Details on how to seek permission, further information about the Publisher’s permissions policies and our arrangements with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions .

This book and the individual contributions contained in it are protected under copyright by the Publisher (other than as may be noted herein).

Notices Knowledge and best practice in this fi eld are constantly changing. As new research and experience broaden our understanding, changes in research methods or professional practices, may become necessary. Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information or methods described herein. In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility.

To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions, or ideas contained in the material herein.

Library of Congress Cataloging-in-Publication Data Amoroso, Edward G. Cyber attacks : protecting national infrastructure / Edward Amoroso. p. cm. Includes index. ISBN 978-0-12-384917-5 1. Cyberterrorism—United States—Prevention. 2. Computer security—United States. 3. National security—United States. I. Title. HV6773.2.A47 2011 363.325�90046780973—dc22 2010040626

British Library Cataloguing-in-Publication Data A catalogue record for this book is available from the British Library.

Printed in the United States of America 10 11 12 13 14 10 9 8 7 6 5 4 3 2 1

For information on all BH publications visit our website at www.elsevierdirect.com/security

CONTENTS v

CONTENTS Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Chapter 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 National Cyber Threats, Vulnerabilities, and Attacks . . . . . . . . . . . . . . . . 4 Botnet Threat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 National Cyber Security Methodology Components . . . . . . . . . . . . . . . 9 Deception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Separation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Discretion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Implementing the Principles Nationally . . . . . . . . . . . . . . . . . . . . . . . . 28

Chapter 2 Deception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Scanning Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Deliberately Open Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Discovery Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Deceptive Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Exploitation Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Procurement Tricks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Exposing Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Interfaces Between Humans and Computers . . . . . . . . . . . . . . . . . . . . 47 National Deception Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

vi CONTENTS

Chapter 3 Separation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 What Is Separation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Functional Separation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 National Infrastructure Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 DDOS Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 SCADA Separation Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Physical Separation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Insider Separation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Asset Separation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Multilevel Security (MLS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Chapter 4 Diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Diversity and Worm Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Desktop Computer System Diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Diversity Paradox of Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . 80 Network Technology Diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Physical Diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 National Diversity Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Chapter 5 Commonality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Meaningful Best Practices for Infrastructure Protection . . . . . . . . . . . . 92 Locally Relevant and Appropriate Security Policy . . . . . . . . . . . . . . . . 95 Culture of Security Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Infrastructure Simplifi cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Certifi cation and Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Career Path and Reward Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Responsible Past Security Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 National Commonality Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Chapter 6 Depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Effectiveness of Depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Layered Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Layered E-Mail Virus and Spam Protection . . . . . . . . . . . . . . . . . . . . . . 119

CONTENTS vii

Layered Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Layered Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Layered Intrusion Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 National Program of Depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Chapter 7 Discretion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Trusted Computing Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Security Through Obscurity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Information Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Information Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Obscurity Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Organizational Compartments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 National Discretion Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Chapter 8 Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Collecting Network Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Collecting System Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Security Information and Event Management . . . . . . . . . . . . . . . . . . 154 Large-Scale Trending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Tracking a Worm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 National Collection Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Chapter 9 Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Conventional Security Correlation Methods . . . . . . . . . . . . . . . . . . . . 167 Quality and Reliability Issues in Data Correlation . . . . . . . . . . . . . . . . 169 Correlating Data to Detect a Worm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Correlating Data to Detect a Botnet . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Large-Scale Correlation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 National Correlation Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Chapter 10 Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Detecting Infrastructure Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Managing Vulnerability Information . . . . . . . . . . . . . . . . . . . . . . . . . . 184

viii CONTENTS

Cyber Security Intelligence Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Risk Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Security Operations Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 National Awareness Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Chapter 11 Response. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Pre- Versus Post-Attack Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Indications and Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Incident Response Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Forensic Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Law Enforcement Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Disaster Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 National Response Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Appendix Sample National Infrastructure Protection Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Sample Deception Requirements (Chapter 2) . . . . . . . . . . . . . . . . . . . 208 Sample Separation Requirements (Chapter 3) . . . . . . . . . . . . . . . . . . 209 Sample Diversity Requirements (Chapter 4) . . . . . . . . . . . . . . . . . . . . . 211 Sample Commonality Requirements (Chapter 5) . . . . . . . . . . . . . . . . 212 Sample Depth Requirements (Chapter 6) . . . . . . . . . . . . . . . . . . . . . . 213 Sample Discretion Requirements (Chapter 7) . . . . . . . . . . . . . . . . . . . 214 Sample Collection Requirements (Chapter 8) . . . . . . . . . . . . . . . . . . . 214 Sample Correlation Requirements (Chapter 9) . . . . . . . . . . . . . . . . . . 215 Sample Awareness Requirements (Chapter 10) . . . . . . . . . . . . . . . . . 216 Sample Response Requirements (Chapter 11) . . . . . . . . . . . . . . . . . . 216

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

PREFACE ix

PREFACE

Man did not enter into society to become worse than he was before, nor to have fewer rights than he had before, but to have those rights better secured.

Thomas Paine in Common Sense

Before you invest any of your time with this book, please take a moment and look over the following points. They outline my basic philosophy of national infrastructure security. I think that your reaction to these points will give you a pretty good idea of what your reaction will be to the book. 1. Citizens of free nations cannot hope to express or enjoy

their freedoms if basic security protections are not provided. Security does not suppress freedom—it makes freedom possible.

2. In virtually every modern nation, computers and networks power critical infrastructure elements. As a result, cyber attackers can use computers and networks to damage or ruin the infrastructures that citizens rely on.

3. Security protections, such as those in security books, were designed for small-scale environments such as enterprise computing environments. These protections do not extrapo- late to the protection of massively complex infrastructure.

4. Effective national cyber protections will be driven largely by cooperation and coordination between commercial, indus- trial, and government organizations. Thus, organizational management issues will be as important to national defense as technical issues.

5. Security is a process of risk reduction, not risk removal. Therefore, concrete steps can and should be taken to reduce, but not remove, the risk of cyber attack to national infrastructure.

6. The current risk of catastrophic cyber attack to national infra- structure must be viewed as extremely high, by any realistic measure. Taking little or no action to reduce this risk would be a foolish national decision. The chapters of this book are organized around ten basic

principles that will reduce the risk of cyber attack to national infrastructure in a substantive manner. They are driven by

x PREFACE

experiences gained managing the security of one of the largest, most complex infrastructures in the world, by years of learning from various commercial and government organizations, and by years of interaction with students and academic researchers in the security fi eld. They are also driven by personal experiences dealing with a wide range of successful and unsuccessful cyber attacks, including ones directed at infrastructure of considerable value. The implementation of the ten principles in this book will require national resolve and changes to the way computing and networking elements are designed, built, and operated in the context of national infrastructure. My hope is that the sugges- tions offered in these pages will make this process easier.

ACKNOWLEDGMENT xi

ACKNOWLEDGMENT

The cyber security experts in the AT&T Chief Security Offi ce, my colleagues across AT&T Labs and the AT&T Chief Technology Offi ce, my colleagues across the entire AT&T business, and my graduate and undergraduate students in the Computer Science Department at the Stevens Institute of Technology, have had a profound impact on my thinking and on the contents of this book. In addition, many prominent enterprise customers of AT&T with whom I’ve had the pleasure of serving, especially those in the United States Federal Government, have been great infl uencers in the preparation of this material.

I’d also like to extend a great thanks to my wife Lee, daugh- ter Stephanie (17), son Matthew (15), and daughter Alicia (9) for their collective patience with my busy schedule.

Edward G. Amoroso Florham Park, NJ September 2010

This page intentionally left blank

1 Cyber Attacks. DOI: © Elsevier Inc. All rights reserved.

10.1016/B978-0-12-384917-5.00001-9 2011

INTRODUCTION Somewhere in his writings—and I regret having forgotten where— John Von Neumann draws attention to what seemed to him a contrast. He remarked that for simple mechanisms it is often easier to describe how they work than what they do, while for more complicated mechanisms it was usually the other way round .

Edsger W. Dijkstra 1

National infrastructure refers to the complex, underlying delivery and support systems for all large-scale services considered abso- lutely essential to a nation. These services include emergency response, law enforcement databases, supervisory control and data acquisition (SCADA) systems, power control networks, mili- tary support services, consumer entertainment systems, fi nancial applications, and mobile telecommunications. Some national services are provided directly by government, but most are pro- vided by commercial groups such as Internet service provid- ers, airlines, and banks. In addition, certain services considered essential to one nation might include infrastructure support that is controlled by organizations from another nation. This global interdependency is consistent with the trends referred to collec- tively by Thomas Friedman as a “fl at world.” 2

National infrastructure, especially in the United States, has always been vulnerable to malicious physical attacks such as equipment tampering, cable cuts, facility bombing, and asset theft. The events of September 11, 2001, for example, are the most prominent and recent instance of a massive physical attack directed at national infrastructure. During the past couple of decades, however, vast portions of national infrastructure have become reliant on software, computers, and networks. This reli- ance typically includes remote access, often over the Internet, to

1

1 E.W. Dijkstra, Selected Writings on Computing: A Personal Perspective , Springer-Verlag, New York, 1982, pp. 212–213. 2 T. Friedman, The World Is Flat: A Brief History of the Twenty-First Century , Farrar, Straus, and Giroux, New York, 2007. (Friedman provides a useful economic backdrop to the global aspect of the cyber attack trends suggested in this chapter.)

2 Chapter 1 INTRODUCTION

the systems that control national services. Adversaries thus can initiate cyber attacks on infrastructure using worms, viruses, leaks, and the like. These attacks indirectly target national infra- structure through their associated automated controls systems (see Figure 1.1 ).

A seemingly obvious approach to dealing with this national cyber threat would involve the use of well-known computer security techniques. After all, computer security has matured substantially in the past couple of decades, and considerable expertise now exists on how to protect software, computers, and networks. In such a national scheme, safeguards such as fi re- walls, intrusion detection systems, antivirus software, passwords, scanners, audit trails, and encryption would be directly embed- ded into infrastructure, just as they are currently in small-scale environments. These national security systems would be con- nected to a centralized threat management system, and inci- dent response would follow a familiar sort of enterprise process. Furthermore, to ensure security policy compliance, one would expect the usual programs of end-user awareness, security train- ing, and third-party audit to be directed toward the people build- ing and operating national infrastructure. Virtually every national infrastructure protection initiative proposed to date has followed this seemingly straightforward path. 3

While well-known computer security techniques will certainly be useful for national infrastructure, most practical experience to date suggests that this conventional approach will not be suf- fi cient. A primary reason is the size, scale, and scope inherent in complex national infrastructure. For example, where an enter- prise might involve manageably sized assets, national infrastruc- ture will require unusually powerful computing support with the ability to handle enormous volumes of data. Such volumes

Indirect Cyber Attacks

Direct Physical Attacks

“Worms, Viruses, Leaks”

“Tampering, Cuts,

Bombs”

National

Infrastructure

Automated Control

Software

Computers

Networks

Figure 1.1 National infrastructure cyber and physical attacks.

3 Executive Offi ce of the President, Cyberspace Policy Review: Assuring a Trusted and Resilient Information and Communications Infrastructure , U.S. White House, Washington, D.C., 2009 ( http://handle.dtic.mil/100.2/ADA501541 ).

Chapter 1 INTRODUCTION 3

will easily exceed the storage and processing capacity of typical enterprise security tools such as a commercial threat manage- ment system. Unfortunately, this incompatibility confl icts with current initiatives in government and industry to reduce costs through the use of common commercial off-the-shelf products.

In addition, whereas enterprise systems can rely on manual intervention by a local expert during a security disaster, large- scale national infrastructure generally requires a carefully orches- trated response by teams of security experts using predetermined processes. These teams of experts will often work in different groups, organizations, or even countries. In the worst cases, they will cooperate only if forced by government, often sharing just the minimum amount of information to avoid legal conse- quences. An additional problem is that the complexity associated with national infrastructure leads to the bizarre situation where response teams often have partial or incorrect understand- ing about how the underlying systems work. For these reasons, seemingly convenient attempts to apply existing small-scale security processes to large-scale infrastructure attacks will ulti- mately fail (see Figure 1.2 ).

As a result, a brand-new type of national infrastructure protec- tion methodology is required—one that combines the best ele- ments of existing computer and network security techniques with the unique and diffi cult challenges associated with complex, large- scale national services. This book offers just such a protection methodology for national infrastructure. It is based on a quarter century of practical experience designing, building, and operating

Small-Scale

Small Volume

Possibly Manual

Local Expert

High

Focused

High Volume

Large-Scale

Process-Based

Distributed Expertise

Partial or Incorrect

Broad

Collection

Emergency

Expertise

Knowledge

Analysis

Large-Scale Attributes Complicate Cyber Security

Figure 1.2 Differences between small- and large-scale cyber security.

National infrastructure databases far exceed the size of even the largest commercial databases.

4 Chapter 1 INTRODUCTION

cyber security systems for government, commercial, and con- sumer infrastructure. It is represented as a series of protection principles that can be applied to new or existing systems. Because of the unique needs of national infrastructure, especially its mas- sive size, scale, and scope, some aspects of the methodology will be unfamiliar to the computer security community. In fact, certain elements of the approach, such as our favorable view of “security through obscurity,” might appear in direct confl ict with conven- tional views of how computers and networks should be protected.

National Cyber Threats, Vulnerabilities, and Attacks Conventional computer security is based on the oft-repeated tax- onomy of security threats which includes confi dentiality, integrity, availability, and theft. In the broadest sense, all four diverse threat types will have applicability in national infrastructure. For example, protections are required equally to deal with sensitive information leaks (confi dentiality ), worms affecting the operation of some criti- cal application (integrity), botnets knocking out an important system (availability), or citizens having their identities compromised (theft). Certainly, the availability threat to national services must be viewed as particularly important, given the nature of the threat and its rela- tion to national assets. One should thus expect particular attention to availability threats to national infrastructure. Nevertheless, it makes sense to acknowledge that all four types of security threats in the conventional taxonomy of computer security must be addressed in any national infrastructure protection methodology.

Vulnerabilities are more diffi cult to associate with any taxon- omy. Obviously, national infrastructure must address well-known problems such as improperly confi gured equipment, poorly designed local area networks, unpatched system software, exploit- able bugs in application code, and locally disgruntled employ- ees. The problem is that the most fundamental vulnerability in national infrastructure involves the staggering complexity inher- ent in the underlying systems. This complexity is so pervasive that many times security incidents uncover aspects of computing functionality that were previously unknown to anyone, including sometimes the system designers. Furthermore, in certain cases, the optimal security solution involves simplifying and cleaning up poorly conceived infrastructure. This is bad news, because most large organizations are inept at simplifying much of anything.

The best one can do for a comprehensive view of the vulner- abilities associated with national infrastructure is to address their

Any of the most common security concerns— confi dentiality, integrity, availability, and theft— threaten our national infrastructure.

Chapter 1 INTRODUCTION 5

relative exploitation points. This can be done with an abstract national infrastructure cyber security model that includes three types of malicious adversaries: external adversary (hackers on the Internet), internal adversary (trusted insiders), and supplier adversary (vendors and partners). Using this model, three exploi- tation points emerge for national infrastructure: remote access (Internet and telework), system administration and normal usage (management and use of software, computers, and networks), and supply chain (procurement and outsourcing) (see Figure 1.3 ).

These three exploitation points and three types of adversaries can be associated with a variety of possible motivations for initi- ating either a full or test attack on national infrastructure.

Remote

Access System

Administration and

Normal Usage

External

Adversary

Three Exploitation Points

National Infrastructure

Three Adversaries

Supply

Chain

Internal

Adversary

Software

Computers

Networks Supplier

Adversary

Figure 1.3 Adversaries and exploitation points in national infrastructure.

Five Possible Motivations for an Infrastructure Attack

● Country-sponsored warfare —National infrastructure attacks sponsored and funded by enemy countries must be considered the most signifi cant potential motivation, because the intensity of adversary capability and willingness to attack is potentially unlimited.

● Terrorist attack —The terrorist motivation is also signifi cant, especially because groups driven by terror can easily obtain suffi cient capability and funding to perform signifi cant attacks on infrastructure.

● Commercially motivated attack —When one company chooses to utilize cyber attacks to gain a commercial advantage, it becomes a national infrastructure incident if the target company is a purveyor of some national asset.

● Financially driven criminal attack —Identify theft is the most common example of a fi nancially driven attack by criminal groups, but other cases exist, such as companies being extorted to avoid a cyber incident.

● Hacking —One must not forget that many types of attacks are still driven by the motivation of hackers, who are often just mischievous youths trying to learn or to build a reputation within the hacking community. This is much less a sinister motivation, and national leaders should try to identify better ways to tap this boundless capability and energy.

6 Chapter 1 INTRODUCTION

Each of the three exploitation points might be utilized in a cyber attack on national infrastructure. For example, a supplier might use a poorly designed supply chain to insert Trojan horse code into a software component that controls some national asset, or a hacker on the Internet might take advantage of some unprotected Internet access point to break into a vulnerable ser- vice. Similarly, an insider might use trusted access for either sys- tem administration or normal system usage to create an attack. The potential also exists for an external adversary to gain valu- able insider access through patient, measured means, such as gaining employment in an infrastructure-supporting organiza- tion and then becoming trusted through a long process of work performance. In each case, the possibility exists that a limited type of engagement might be performed as part of a planned test or exercise. This seems especially likely if the attack is country or terrorist sponsored, because it is consistent with past practice.

At each exploitation point, the vulnerability being used might be a well-known problem previously reported in an authoritative public advisory, or it could be a proprietary issue kept hidden by a local organization. It is entirely appropriate for a recognized authority to make a detailed public vulnerability advisory if the benefi ts of notifying the good guys outweigh the risks of alert- ing the bad guys. This cost–benefi t result usually occurs when many organizations can directly benefi t from the information and can thus take immediate action. When the reported vulner- ability is unique and isolated, however, then reporting the details might be irresponsible, especially if the notifi cation process does not enable a more timely fi x. This is a key issue, because many government authorities continue to consider new rules for man- datory reporting. If the information being demanded is not prop- erly protected, then the reporting process might result in more harm than good.

Botnet Threat Perhaps the most insidious type of attack that exists today is the botnet . 4 In short, a botnet involves remote control of a collec- tion of compromised end-user machines, usually broadband- connected PCs. The controlled end-user machines, which are referred to as bots , are programmed to attack some target that is designated by the botnet controller. The attack is tough to stop

4 Much of the material on botnets in this chapter is derived from work done by Brian Rexroad, David Gross, and several others from AT&T.

When to issue a vulnerability risk advisory and when to keep the risk confi dential must be determined on a case- by-case basis, depending on the threat.

Chapter 1 INTRODUCTION 7

because end-user machines are typically administered in an inef- fective manner. Furthermore, once the attack begins, it occurs from sources potentially scattered across geographic, political, and service provider boundaries. Perhaps worse, bots are pro- grammed to take commands from multiple controller systems, so any attempts to destroy a given controller result in the bots sim- ply homing to another one.

The Five Entities That Comprise a Botnet Attack ● Botnet operator —This is the individual, group, or country that creates the botnet, including its setup and operation.

When the botnet is used for fi nancial gain, it is the operator who will benefi t. Law enforcement and cyber security initiatives have found it very diffi cult to identify the operators. The press, in particular, has done a poor job reporting on the presumed identity of botnet operators, often suggesting sponsorship by some country when little supporting evidence exists.

● Botnet controller —This is the set of servers that command and control the operation of a botnet. Usually these servers have been maliciously compromised for this purpose. Many times, the real owner of a server that has been compromised will not even realize what has occurred. The type of activity directed by a controller includes all recruitment, setup, communication, and attack activity. Typical botnets include a handful of controllers, usually distributed across the globe in a non-obvious manner.

● Collection of bots —These are the end-user, broadband-connected PCs infected with botnet malware. They are usually owned and operated by normal citizens, who become unwitting and unknowing dupes in a botnet attack. When a botnet includes a concentration of PCs in a given region, observers often incorrectly attribute the attack to that region. The use of smart mobile devices in a botnet will grow as upstream capacity and device processing power increase.

● Botnet software drop —Most botnets include servers designed to store software that might be useful for the botnets during their lifecycle. Military personnel might refer to this as an arsenal . Like controllers, botnet software drop points are usually servers compromised for this purpose, often unknown to the normal server operator.

● Botnet target —This is the location that is targeted in the attack. Usually, it is a website, but it can really be any device, system, or network that is visible to the bots. In most cases, botnets target prominent and often controversial websites, simply because they are visible via the Internet and generally have a great deal at stake in terms of their availability. This increases gain and leverage for the attacker. Logically, however, botnets can target anything visible.

The way a botnet works is that the controller is set up to com- municate with the bots via some designated protocol, most often Internet Relay Chat (IRC). This is done via malware inserted into the end-user PCs that comprise the bots. A great challenge in this regard is that home PCs and laptops are so poorly administered. Amazingly, over time, the day-to-day system and security admin- istration task for home computers has gravitated to the end user.

8 Chapter 1 INTRODUCTION

This obligation results in both a poor user experience and gen- eral dissatisfaction with the security task. For example, when a typical computer buyer brings a new machine home, it has prob- ably been preloaded with security software by the retailer. From this point onward, however, that home buyer is then tasked with all responsibility for protecting the machine. This includes keep- ing fi rewall, intrusion detection, antivirus, and antispam software up to date, as well as ensuring that all software patches are cur- rent. When these tasks are not well attended, the result is a more vulnerable machine that is easily turned into a bot. (Sadly, even if a machine is properly managed, expert bot software designers might fi nd a way to install the malware anyway.)

Once a group of PCs has been compromised into bots, attacks can thus be launched by the controller via a command to the bots, which would then do as they are instructed. This might not occur instantaneously with the infection; in fact, experi- ence suggests that many botnets lay dormant for a great deal of time. Nevertheless, all sorts of attacks are possible in a bot- net arrangement, including the now-familiar distributed denial of service attack (DDOS). In such a case, the bots create more inbound traffi c than the target gateway can handle. For example, if some theoretical gateway allows for 1 Gbps of inbound traffi c, and the botnet creates an inbound stream larger than 1 Gbps, then a logjam results at the inbound gateway, and a denial of service condition occurs (see Figure 1.4 ).

Any serious present study of cyber security must acknowl- edge the unique threat posed by botnets. Virtually any Internet- connected system is vulnerable to major outages from a botnet-originated DDOS attack. The physics of the situation are especially depressing; that is, a botnet that might steal 500 Kbps

Broadband

Carriers

Capacity Excess

Creates Jam

Bots

Target A’s

Designated

Carrier

1 Gbps

Ingress Target A

1 Gbps DDOS Traffic

Aimed at Target A

Figure 1.4 Sample DDOS attack from a botnet.

Home PC users may never know they are being used for a botnet scheme.

A DDOS attack is like a cyber traffi c jam.

Chapter 1 INTRODUCTION 9

of upstream capacity from each bot (which would generally allow for concurrent normal computing and networking) would only need three bots to collapse a target T1 connection. Following this logic, only 16,000 bots would be required theoretically to fi ll up a 10-Gbps connection. Because most of the thousands of bot- nets that have been observed on the Internet are at least this size, the threat is obvious; however, many recent and prominent bot- nets such as Storm and Confi cker are much larger, comprising as many as several million bots, so the threat to national infrastruc- ture is severe and immediate.

National Cyber Security Methodology Components Our proposed methodology for protecting national infrastruc- ture is presented as a series of ten basic design and operation principles. The implication is that, by using these principles as a guide for either improving existing infrastructure components or building new ones, the security result will be desirable, includ- ing a reduced risk from botnets. The methodology addresses all four types of security threats to national infrastructure; it also deals with all three types of adversaries to national infrastructure, as well as the three exploitation points detailed in the infrastruc- ture model. The list of principles in the methodology serves as a guide to the remainder of this chapter, as well as an outline for the remaining chapters of the book: ● Chapter 2: Deception —The openly advertised use of deception

creates uncertainty for adversaries because they will not know if a discovered problem is real or a trap. The more common hid- den use of deception allows for real-time behavioral analysis if an intruder is caught in a trap. Programs of national infrastruc- ture protection must include the appropriate use of deception, especially to reduce the malicious partner and supplier risk.

● Chapter 3: Separation —Network separation is currently accomplished using fi rewalls, but programs of national infra- structure protection will require three specifi c changes. Specifi cally, national infrastructure must include network- based fi rewalls on high-capacity backbones to throttle DDOS attacks, internal fi rewalls to segregate infrastructure and reduce the risk of sabotage, and better tailoring of fi rewall fea- tures for specifi c applications such as SCADA protocols. 5

5 R. Kurtz, Securing SCADA Systems , Wiley, New York, 2006. (Kurtz provides an excellent overview of SCADA systems and the current state of the practice in securing them.)

10 Chapter 1 INTRODUCTION

● Chapter 4: Diversity —Maintaining diversity in the products, services, and technologies supporting national infrastruc- ture reduces the chances that one common weakness can be exploited to produce a cascading attack. A massive program of coordinated procurement and supplier management is required to achieve a desired level of national diversity across all assets. This will be tough, because it confl icts with most cost-motivated information technology procurement initia- tives designed to minimize diversity in infrastructure.

● Chapter 5: Commonality —The consistent use of security best practices in the administration of national infrastructure ensures that no infrastructure component is either poorly managed or left completely unguarded. National programs of standards selection and audit validation, especially with an emphasis on uniform programs of simplifi cation, are thus required. This can certainly include citizen end users, but one should never rely on high levels of security compliance in the broad population.

● Chapter 6: Depth —The use of defense in depth in national infrastructure ensures that no critical asset is reliant on a single security layer; thus, if any layer should fail, an addi- tional layer is always present to mitigate an attack. Analysis is required at the national level to ensure that all critical assets are protected by at least two layers, preferably more.

● Chapter 7: Discretion —The use of personal discretion in the sharing of information about national assets is a practical technique that many computer security experts fi nd diffi cult to accept because it confl icts with popular views on “security through obscurity.” Nevertheless, large-scale infrastructure protection cannot be done properly unless a national culture of discretion and secrecy is nurtured. It goes without saying that such discretion should never be put in place to obscure illegal or unethical practices.

● Chapter 8: Collection —The collection of audit log informa- tion is a necessary component of an infrastructure security scheme, but it introduces privacy, size, and scale issues not seen in smaller computer and network settings. National infrastructure protection will require a data collection approach that is acceptable to the citizenry and provides the requisite level of detail for security analysis.

● Chapter 9: Correlation —Correlation is the most fundamen- tal of all analysis techniques for cyber security, but modern attack methods such as botnets greatly complicate its use for attack-related indicators. National-level correlation must be performed using all available sources and the best available

Chapter 1 INTRODUCTION 11

technology and algorithms. Correlating information around a botnet attack is one of the more challenging present tasks in cyber security.

● Chapter 10: Awareness —Maintaining situational awareness is more important in large-scale infrastructure protection than in traditional computer and network security because it helps to coordinate the real-time aspect of multiple infrastructure components. A program of national situational awareness must be in place to ensure proper management decision- making for national assets.

● Chapter 11: Response —Incident response for national infra- structure protection is especially diffi cult because it gener- ally involves complex dependencies and interactions between disparate government and commercial groups. It is best accomplished at the national level when it focuses on early indications, rather than on incidents that have already begun to damage national assets. The balance of this chapter will introduce each principle, with

discussion on its current use in computer and network security, as well as its expected benefi ts for national infrastructure protection.

Deception The principle of deception involves the deliberate introduc- tion of misleading functionality or misinformation into national infrastructure for the purpose of tricking an adversary. The idea is that an adversary would be presented with a view of national infrastructure functionality that might include services or inter- face components that are present for the sole purpose of fakery. Computer scientists refer to this functionality as a honey pot , but the use of deception for national infrastructure could go far beyond this conventional view. Specifi cally, deception can be used to protect against certain types of cyber attacks that no other security method will handle. Law enforcement agen- cies have been using deception effectively for many years, often catching cyber stalkers and criminals by spoofi ng the reported identity of an end point. Even in the presence of such obvi- ous success, however, the cyber security community has yet to embrace deception as a mainstream protection measure.

Deception in computing typically involves a layer of clev- erly designed trap functionality strategically embedded into the internal and external interfaces for services. Stated more simply, deception involves fake functionality embedded into real inter- faces. An example might be a deliberately planted trap link on

Deception is an oft-used tool by law enforcement agencies to catch cyber stalkers and predators.

12 Chapter 1 INTRODUCTION

a website that would lead potential intruders into an environ- ment designed to highlight adversary behavior. When the decep- tion is open and not secret, it might introduce uncertainty for adversaries in the exploitation of real vulnerabilities, because the adversary might suspect that the discovered entry point is a trap. When it is hidden and stealth, which is the more common situa- tion, it serves as the basis for real-time forensic analysis of adver- sary behavior. In either case, the result is a public interface that includes real services, deliberate honey pot traps, and the inevi- table exploitable vulnerabilities that unfortunately will be pres- ent in all nontrivial interfaces (see Figure 1.5 ).

Only relatively minor tests of honey pot technology have been reported to date, usually in the context of a research effort. Almost no reports are available on the day-to-day use of decep- tion as a structural component of a real enterprise security program. In fact, the vast majority of security programs for com- panies, government agencies, and national infrastructure would include no such functionality. Academic computer scientists have shown little interest in this type of security, as evidenced by the relatively thin body of literature on the subject. This lack of interest might stem from the discomfort associated with using computing to mislead. Another explanation might be the relative ineffectiveness of deception against the botnet threat, which is clearly the most important security issue on the Internet today. Regardless of the cause, this tendency to avoid the use of decep- tion is unfortunate, because many cyber attacks, such as subtle break-ins by trusted insiders and Trojan horses being maliciously inserted by suppliers into delivered software, cannot be easily remedied by any other means.

The most direct benefi t of deception is that it enables foren- sic analysis of intruder activity. By using a honey pot, unique insights into attack methods can be gained by watching what is occurring in real time. Such deception obviously works best in a hidden, stealth mode, unknown to the intruder, because if

Interface to

Valid Services

Trap Interface

to Honey Pot

Should Resemble

Valid Services

Vulnerabilities Possible

Uncertainty

Real

Assets

Honey

Pot

???

Figure 1.5 Components of an interface with deception.

Deception is less effective against botnets than other types of attack methods.

Chapter 1 INTRODUCTION 13

the intruder realizes that some vulnerable exploitation point is a fake, then no exploitation will occur. Honey pot pioneers Cliff Stoll, Bill Cheswick, and Lance Spitzner have provided a major- ity of the reported experience in real-time forensics using honey pots. They have all suggested that the most diffi cult task involves creating believability in the trap. It is worth noting that connect- ing a honey pot to real assets is a terrible idea.

An additional potential benefi t of deception is that it can introduce the clever idea that some discovered vulnerability might instead be a deliberately placed trap. Obviously, such an approach is only effective if the use of deception is not hidden; that is, the adversary must know that deception is an approved and accepted technique used for protection. It should therefore be obvious that the major advantage here is that an accidental vulnerability, one that might previously have been an open door for an intruder, will suddenly look like a possible trap. A further profound notion, perhaps for open discussion, is whether just the implied statement that deception might be present (perhaps without real justifi cation) would actually reduce risk. Suppliers, for example, might be less willing to take the risk of Trojan horse insertion if the procuring organization advertises an open research and development program of detailed software test and inspection against this type of attack.

Separation The principle of separation involves enforcement of access policy restrictions on the users and resources in a computing environ- ment. Access policy restrictions result in separation domains, which are arguably the most common security architectural concept in use today. This is good news, because the creation of access-policy-based separation domains will be essential in the protection of national infrastructure. Most companies today will typically use fi rewalls to create perimeters around their presumed enterprise, and access decisions are embedded in the associated rules sets. This use of enterprise fi rewalls for separation is com- plemented by several other common access techniques: ● Authentication and identity management —These methods are

used to validate and manage the identities on which separa- tion decisions are made. They are essential in every enterprise but cannot be relied upon solely for infrastructure security. Malicious insiders, for example, will be authorized under such systems. In addition, external attacks such as DDOS are unaf- fected by authentication and identity management.

Do not connect honey pots to real assets!

14 Chapter 1 INTRODUCTION

● Logical access controls —The access controls inherent in oper- ating systems and applications provide some degree of sepa- ration, but they are also weak in the presence of compromised insiders. Furthermore, underlying vulnerabilities in appli- cations and operating systems can often be used to subvert these methods.

● LAN controls —Access control lists on local area network (LAN) components can provide separation based on infor- mation such as Internet Protocol (IP) or media access control (MAC) address. In this regard, they are very much like fi rewalls but typically do not extend their scope beyond an isolated segment.

● Firewalls —For large-scale infrastructure, fi rewalls are particu- larly useful, because they separate one network from another. Today, every Internet-based connection is almost certainly protected by some sort of fi rewall functionality. This approach worked especially well in the early years of the Internet, when the number of Internet connections to the enterprise was small. Firewalls do remain useful, however, even with the massive connectivity of most groups to the Internet. As a result, national infrastructure should continue to include the use of fi rewalls to protect known perimeter gateways to the Internet. Given the massive scale and complexity associated with

national infrastructure, three specifi c separation enhancements are required, and all are extensions of the fi rewall concept.

Required Separation Enhancements for National Infrastructure Protection

1. The use of network-based fi rewalls is absolutely required for many national infrastructure applications, especially ones vulnerable to DDOS attacks from the Internet. This use of network-based mediation can take advantage of high-capacity network backbones if the service provider is involved in running the fi rewalls.

2. The use of fi rewalls to segregate and isolate internal infrastructure components from one another is a mandatory technique for simplifying the implementation of access control policies in an organization. When insiders have malicious intent, any exploit they might attempt should be explicitly contained by internal fi rewalls.

3. The use of commercial off-the-shelf fi rewalls, especially for SCADA usage, will require tailoring of the fi rewall to the unique protocol needs of the application. It is not acceptable for national infrastructure protection to retrofi t the use of a generic, commercial, off-the-shelf tool that is not optimized for its specifi c use (see Figure 1.6 ).

Chapter 1 INTRODUCTION 15

With the advent of cloud computing, many enterprise and government agency security managers have come to acknowl- edge the benefi ts of network-based fi rewall processing. The approach scales well and helps to deal with the uncontrolled complexity one typically fi nds in national infrastructure. That said, the reality is that most national assets are still secured by placing a fi rewall at each of the hundreds or thousands of pre- sumed choke points. This approach does not scale and leads to a false sense of security. It should also be recognized that the fi rewall is not the only device subjected to such scale problems. Intrusion detection systems, antivirus fi ltering, threat manage- ment, and denial of service fi ltering also require a network-based approach to function properly in national infrastructure.

An additional problem that exists in current national infrastruc- ture is the relative lack of architectural separation used in an internal, trusted network. Most security engineers know that large systems are best protected by dividing them into smaller systems. Firewalls or packet fi ltering routers can be used to segregate an enterprise net- work into manageable domains. Unfortunately, the current state of the practice in infrastructure protection rarely includes a disciplined approach to separating internal assets. This is unfortunate, because it allows an intruder in one domain to have access to a more expan- sive view of the organizational infrastructure. The threat increases when the fi rewall has not been optimized for applications such as SCADA that require specialized protocol support.

Required New Separation

Mechanisms

(Less Familiar)

Existing Separation

Mechanisms

(Less Familiar)

Internet Service Provider

Commercial and

Government

Infrastructure

Commercial

Off-the-Shelf

Perimeter

Firewalls

Authentification and

Identity Management,

Logical Access Controls,

LAN Controls

Internal

Firewalls

Tailored

Firewalls

(SCADA)

Network-Based

Firewalls

(Carrier)

Figure 1.6 Firewall enhancements for national infrastructure.

Parceling a network into manageable smaller domains creates an environment that is easier to protect.

16 Chapter 1 INTRODUCTION

Diversity The principle of diversity involves the selection and use of tech- nology and systems that are intentionally different in substan- tive ways. These differences can include technology source, programming language, computing platform, physical location, and product vendor. For national infrastructure, realizing such diversity requires a coordinated program of procurement to ensure a proper mix of technologies and vendors. The purpose of introducing these differences is to deliberately create a measure of non-interoperability so that an attack cannot easily cascade from one component to another through exploitation of some common vulnerability. Certainly, it would be possible, even in a diverse environment, for an exploit to cascade, but the likelihood is reduced as the diversity profi le increases.

This concept is somewhat controversial, because so much of computer science theory and information technology prac- tice in the past couple of decades has been focused on maxi- mizing interoperability of technologies. This might help explain the relative lack of attentiveness that diversity considerations receive in these fi elds. By way of analogy, however, cyber attacks on national infrastructure are mitigated by diversity technol- ogy just as disease propagation is reduced by a diverse biologi- cal ecosystem. That is, a problem that originates in one area of infrastructure with the intention of automatic propagation will only succeed in the presence of some degree of interoperability. If the technologies are suffi ciently diverse, then the attack propa- gation will be reduced or even stopped. As such, national asset managers are obliged to consider means for introducing diver- sity in a cost-effective manner to realize its security benefi ts (see Figure 1.7 ).

Attack Target

Component

3

Attack Target

Component

2

Non-Diverse

(Attack Propagates)

Diverse

(Attack Propagation Stops)

Attack

Adversary Target

Component

1

Figure 1.7 Introducing diversity to national infrastructure.

Chapter 1 INTRODUCTION 17

Diversity is especially tough to implement in national infra- structure for several reasons. First, it must be acknowledged that a single, major software vendor tends to currently dominate the personal computer (PC) operating system business landscape in most government and enterprise settings. This is not likely to change, so national infrastructure security initiatives must sim- ply accept an ecosystem lacking in diversity in the PC landscape. The profi le for operating system software on computer servers is slightly better from a diversity perspective, but the choices remain limited to a very small number of available sources. Mobile oper- ating systems currently offer considerable diversity, but one can- not help but expect to see a trend toward greater consolidation.

Second, diversity confl icts with the often-found organiza- tional goal of simplifying supplier and vendor relationships; that is, when a common technology is used throughout an organiza- tion, day-to-day maintenance, administration, and training costs are minimized. Furthermore, by purchasing in bulk, better terms are often available from a vendor. In contrast, the use of diversity could result in a reduction in the level of service provided in an organization. For example, suppose that an Internet service pro- vider offers particularly secure and reliable network services to an organization. Perhaps the reliability is even measured to some impressive quantitative availability metric. If the organization is committed to diversity, then one might be forced to actually introduce a second provider with lower levels of reliability.

In spite of these drawbacks, diversity carries benefi ts that are indisputable for large-scale infrastructure. One of the great chal- lenges in national infrastructure protection will thus involve fi nd- ing ways to diversify technology products and services without increasing costs and losing business leverage with vendors.

Consistency The principle of consistency involves uniform attention to secu- rity best practices across national infrastructure components. Determining which best practices are relevant for which national asset requires a combination of local knowledge about the asset, as well as broader knowledge of security vulnerabilities in generic infrastructure protection. Thus, the most mature approach to consistency will combine compliance with relevant standards such as the Sarbanes–Oxley controls in the United States, with locally derived security policies that are tailored to the organiza- tional mission. This implies that every organization charged with the design or operation of national infrastructure must have a

Enforcing diversity of products and services might seem counterintuitive if you have a reliable provider.

18 Chapter 1 INTRODUCTION

local security policy. Amazingly, some large groups do not have such a policy today.

The types of best practices that are likely to be relevant for national infrastructure include well-defi ned software lifecycle methodologies, timely processes for patching software and sys- tems, segregation of duty controls in system administration, threat management of all collected security information, secu- rity awareness training for all system administrators, operational confi gurations for infrastructure management, and use of soft- ware security tools to ensure proper integrity management. Most security experts agree on which best practices to include in a generic set of security requirements, as evidenced by the inclu- sion of a common core set of practices in every security standard. Attentiveness to consistency is thus one of the less controversial of our recommended principles.

The greatest challenge in implementing best practice consis- tency across infrastructure involves auditing. The typical audit process is performed by an independent third-party entity doing an analysis of target infrastructure to determine consistency with a desired standard. The result of the audit is usually a numeric score, which is then reported widely and used for management decisions. In the United States, agencies of the federal govern- ment are audited against a cyber security standard known as FISMA (Federal Information Security Management Act). While auditing does lead to improved best practice coverage, there are often problems. For example, many audits are done poorly, which results in confusion and improper management deci- sions. In addition, with all the emphasis on numeric ratings, many agencies focus more on their score than on good security practice.

Today, organizations charged with protecting national infra- structure are subjected to several types of security audits. Streamlining these standards would certainly be a good idea, but some additional items for consideration include improving the types of common training provided to security administrators, as well as including past practice in infrastructure protection in common audit standards. The most obvious practical consid- eration for national infrastructure, however, would be national- level agreement on which standard or standards would be used to determine competence to protect national assets. While this is a straightforward concept, it could be tough to obtain wide con- currence among all national participants. A related issue involves commonality in national infrastructure operational confi gu- rations; this reduces the chances that a rogue confi guration

A good audit score is important but should not replace good security practices.

A national standard of competence for protecting our assets is needed.

Chapter 1 INTRODUCTION 19

installed for malicious purposes, perhaps by compromised insiders.

Depth The principle of depth involves the use of multiple security layers of protection for national infrastructure assets. These layers pro- tect assets from both internal and external attacks via the familiar “defense in depth” approach; that is, multiple layers reduce the risk of attack by increasing the chances that at least one layer will be effective. This should appear to be a somewhat sketchy situ- ation, however, from the perspective of traditional engineering. Civil engineers, for example, would never be comfortable design- ing a structure with multiple fl awed supports in the hopes that one of them will hold the load. Unfortunately, cyber security experts have no choice but to rely on this fl awed notion, perhaps highlighting the relative immaturity of security as an engineering discipline.

One hint as to why depth is such an important requirement is that national infrastructure components are currently con- trolled by software, and everyone knows that the current state of software engineering is abysmal. Compared to other types of engineering, software stands out as the only one that accepts the creation of knowingly fl awed products as acceptable. The result is that all nontrivial software has exploitable vulnerabilities, so the idea that one should create multiple layers of security defense is unavoidable. It is worth mentioning that the degree of diversity in these layers will also have a direct impact on their effectiveness (see Figure 1.8 ).

To maximize the usefulness of defense layers in national infra- structure, it is recommended that a combination of functional

Software engineering standards do not contain the same level of quality as civil and other engineering standards.

Attack Gets

Through Here...

...Hopefully

Stopped Here

Multiple Layers of Protection

Adversary Target Asset

Asset Protected

Via Depth Approach

Figure 1.8 National infrastructure security through defense in depth.

20 Chapter 1 INTRODUCTION

and procedural controls be included. For example, a common fi rst layer of defense is to install an access control mechanism for the admission of devices to the local area network. This could involve router controls in a small network or fi rewall access rules in an enterprise. In either case, this fi rst line of defense is clearly functional. As such, a good choice for a second layer of defense might involve something procedural, such as the deployment of scanning to determine if inappropriate devices have gotten through the fi rst layer. Such diversity will increase the chances that the cause of failure in one layer is unlikely to cause a similar failure in another layer.

A great complication in national infrastructure protection is that many layers of defense assume the existence of a defi ned net- work perimeter. For example, the presence of many fl aws in enter- prise security found by auditors is mitigated by the recognition that intruders would have to penetrate the enterprise perimeter to exploit these weaknesses. Unfortunately, for most national assets, fi nding a perimeter is no longer possible. The assets of a country, for example, are almost impossible to defi ne within some geo- graphic or political boundary, much less a network one. Security managers must therefore be creative in identifying controls that will be meaningful for complex assets whose properties are not always evident. The risk of getting this wrong is that in providing multiple layers of defense, one might misapply the protections and leave some portion of the asset base with no layers in place.

Discretion The principle of discretion involves individuals and groups making good decisions to obscure sensitive information about national infrastructure. This is done by combining formal man- datory information protection programs with informal discre- tionary behavior. Formal mandatory programs have been in place for many years in the U.S. federal government, where docu- ments are associated with classifi cations, and policy enforce- ment is based on clearances granted to individuals. In the most intense environments, such as top-secret compartments in the intelligence community, violations of access policies could be interpreted as espionage, with all of the associated criminal implications. For this reason, prominent breaches of highly clas- sifi ed government information are not common.

In commercial settings, formal information protection pro- grams are gaining wider acceptance because of the increased need to protect personally identifi able information (PII) such as

Naturally, top-secret information within the intelligence community is at great risk for attack or infi ltration.

Chapter 1 INTRODUCTION 21

credit card numbers. Employees of companies around the world are starting to understand the importance of obscuring certain aspects of corporate activity, and this is healthy for national infra- structure protection. In fact, programs of discretion for national infrastructure protection will require a combination of corpo- rate and government security policy enforcement, perhaps with custom-designed information markings for national assets. The resultant discretionary policy serves as a layer of protection to prevent national infrastructure-related information from reach- ing individuals who have no need to know such information.

A barrier in our recommended application of discretion is the maligned notion of “security through obscurity.” Security experts, especially cryptographers, have long complained that obscurity is an unacceptable protection approach. They correctly reference the problems of trying to secure a system by hiding its underly- ing detail. Inevitably, an adversary discovers the hidden design secrets and the security protection is lost. For this reason, con- ventional computer security correctly dictates an open approach to software, design, and algorithms. An advantage of this open approach is the social review that comes with widespread adver- tisement; for example, the likelihood is low of software ever being correct without a signifi cant amount of intense review by experts. So, the general computer security argument against “security through obscurity” is largely valid in most cases.

Nevertheless, any manager charged with the protection of nontrivial, large-scale infrastructure will tell you that discretion and, yes, obscurity are indispensable components in a protec- tion program. Obscuring details around technology used, soft- ware deployed, systems purchased, and confi gurations managed will help to avoid or at least slow down certain types of attacks. Hackers often claim that by discovering this type of informa- tion about a company and then advertising the weaknesses they are actually doing the local security team a favor. They suggest that such advertisement is required to motivate a security team toward a solution, but this is actually nonsense. Programs around proper discretion and obscurity for infrastructure information are indispensable and must be coordinated at the national level.

Collection The principle of collection involves automated gathering of sys- tem-related information about national infrastructure to enable security analysis. Such collection is usually done in real time and involves probes or hooks in applications, system software, net- work elements, or hardware devices that gather information of

“Security through obscurity” may actually leave assets more vulnerable to attack than an open approach would.

22 Chapter 1 INTRODUCTION

interest. The use of audit trails in small-scale computer security is an example of a long-standing collection practice that introduces very little controversy among experts as to its utility. Security devices such as fi rewalls produce log fi les, and systems purported to have some degree of security usefulness will also generate an audit trail output. The practice is so common that a new type of product, called a security information management system (SIMS), has been developed to process all this data.

The primary operational challenge in setting up the right type of collection process for computers and networks has been two- fold: First, decisions must be made about what types of informa- tion are to be collected. If this decision is made correctly, then the information collected should correspond to exactly the type of data required for security analysis, and nothing else. Second, decisions must be made about how much information is actu- ally collected. This might involve the use of existing system func- tions, such as enabling the automatic generation of statistics on a router; or it could involve the introduction of some new type of function that deliberately gathers the desired information. Once these considerations are handled, appropriate mechanisms for collecting data from national infrastructure can be embedded into the security architecture (see Figure 1.9 ).

The technical and operational challenges associated with the collection of logs and audit trails are heightened in the protec- tion of national assets. Because national infrastructure is so com- plex, determining what information should be collected turns out to be a diffi cult exercise. In particular, the potential arises with large-scale collection to intrude on the privacy of individu- als and groups within a nation. As such, any initiative to protect

Typical Infrastructure

Collection Points

Type and Volume

Issues

Device Status Monitors

Distributed Across

Government and Industry

Interpretation

and Action

Operating System Logs

Network Monitors

Application Hooks

Transport

Issues

Privacy

Issues

Data

Collection

Repositories

Figure 1.9 Collecting national infrastructure-related security information.

Chapter 1 INTRODUCTION 23

infrastructure through the collection of data must include at least some measure of privacy policy determination. Similarly, the vol- umes of data collected from large infrastructure can exceed prac- tical limits. Telecommunications collection systems designed to protect the integrity of a service provider backbone, for example, can easily generate many terabytes of data in hours of processing.

In both cases, technical and operational expertise must be applied to ensure that the appropriate data is collected in the proper amounts. The good news is that virtually all security protection algorithms require no deep, probing information of the type that might generate privacy or volumetric issues. The challenge arises instead when collection is done without proper advance analysis which often results in the collection of more data than is needed. This can easily lead to privacy problems in some national collection repositories, so planning is particularly necessary. In any event, a national strategy of data collection is required, with the usual sorts of legal and policy guidance on who collects what and under which circumstances. As we sug- gested above, this exercise must be guided by the requirements for security analysis—and nothing else.

Correlation The principle of correlation involves a specifi c type of analysis that can be performed on factors related to national infrastructure protection. The goal of correlation is to identify whether security- related indicators might emerge from the analysis. For example, if some national computing asset begins operating in a sluggish man- ner, then other factors would be examined for a possible correlative relationship. One could imagine the local and wide area networks being analyzed for traffi c that might be of an attack nature. In addi- tion, similar computing assets might be examined to determine if they are experiencing a similar functional problem. Also, all soft- ware and services embedded in the national asset might be ana- lyzed for known vulnerabilities. In each case, the purpose of the correlation is to combine and compare factors to help explain a given security issue. This type of comparison-oriented analysis is indispensable for national infrastructure because of its complexity.

Interestingly, almost every major national infrastructure pro- tection initiative attempted to date has included a fusion cen- ter for real-time correlation of data. A fusion center is a physical security operations center with means for collecting and ana- lyzing multiple sources of ingress data. It is not uncommon for such a center to include massive display screens with colorful,

What and how much data to collect is an operational challenge.

Only collect as much data as is necessary for security purposes.

Monitoring and analyzing networks and data collection may reveal a hidden or emerging security threat.

24 Chapter 1 INTRODUCTION

visualized representations, nor is it uncommon to fi nd such cen- ters in the military with teams of enlisted people performing the manual chores. This is an important point, because, while such automated fusion is certainly promising, best practice in cor- relation for national infrastructure protection must include the requirement that human judgment be included in the analysis. Thus, regardless of whether resources are centralized into one physical location, the reality is that human beings will need to be included in the processing (see Figure 1.10 ).

In practice, fusion centers and the associated processes and correlation algorithms have been tough to implement, even in small-scale environments. Botnets, for example, involve the use of source systems that are selected almost arbitrarily. As such, the use of correlation to determine where and why the attack is occurring has been useless. In fact, correlating geographic infor- mation with the sources of botnet activity has even led to many false conclusions about who is attacking whom. Countless hours have been spent by security teams poring through botnet infor- mation trying to determine the source, and the best one can

Correlation Process

Output

Recommended

Actions

Multiple

Ingress Data

Feeds

Comparison and

Analysis of

Relevant Factors

Derive

Real-Time

Conclusions

Figure 1.10 National infrastructure high-level correlation approach.

Three Steps to Improve Current Correlation Capabilities

1. The actual computer science around correlation algorithms needs to be better investigated. Little attention has been placed in academic computer science and applied mathematics departments to multifactor correlation of real-time security data. This could be changed with appropriate funding and grant emphasis from the government.

2. The ability to identify reliable data feeds needs to be greatly improved. Too much attention has been placed on ad hoc collection of volunteered feeds, and this complicates the ability for analysis to perform meaningful correlation.

3. The design and operation of a national-level fusion center must be given serious consideration. Some means must be identifi ed for putting aside political and funding problems in order to accomplish this important objective.

Chapter 1 INTRODUCTION 25

hope for might be information about controllers or software drops. In the end, current correlation approaches fall short.

What is needed to improve present correlation capabilities for national infrastructure protection involves multiple steps.

Awareness The principle of awareness involves an organization under- standing the differences, in real time and at all times, between observed and normal status in national infrastructure. This status can include risks, vulnerabilities, and behavior in the target infra- structure. Behavior refers here to the mix of user activity, system processing, network traffi c, and computing volumes in the soft- ware, computers, and systems that comprise infrastructure. The implication is that the organization can somehow characterize a given situation as being either normal or abnormal. Furthermore, the organization must have the ability to detect and measure differences between these two behavioral states. Correlation analysis is usually inherent in such determinations, but the real challenge is less the algorithms and more the processes that must be in place to ensure situational awareness every hour of every day. For example, if a new vulnerability arises that has impact on the local infrastructure, then this knowledge must be obtained and factored into management decisions immediately.

Managers of national infrastructure generally do not have to be convinced that situational awareness is important. The big issue instead is how to achieve this goal. In practice, real-time aware- ness requires attentiveness and vigilance rarely found in normal computer security. Data must fi rst be collected and enabled to fl ow into a fusion center at all times so correlation can take place. The results of the correlation must be used to establish a profi led baseline of behavior so differences can be measured. This sounds easier than it is, because so many odd situations have the ability to mimic normal behavior (when it is really a problem) or a problem (when it really is nothing). Nevertheless, national infrastructure protection demands that managers of assets create a locally rele- vant means for being able to comment accurately on the state of security at all times. This allows for proper management decisions about security (see Figure 1.11 ).

Interestingly, situational awareness has not been considered a major component of the computer security equation to date. The concept plays no substantive role in small-scale security, such as in a home network, because when the computing base to be protected is simple enough, characterizing real-time situational status is just not necessary. Similarly, when a security manager puts in place security controls for a small enterprise, situational

Awareness builds on collection and correlation, but is not limited to those areas alone.

26 Chapter 1 INTRODUCTION

awareness is not the highest priority. Generally, the closest one might expect to some degree of real-time awareness for a small system might be an occasional review of system log fi les. So, the transition from small-scale to large-scale infrastructure protec- tion does require a new attentiveness to situational awareness that is not well developed. It is also worth noting that the general notion of “user awareness” of security is also not the principle specifi ed here. While it is helpful for end users to have knowl- edge of security, any professionally designed program of national infrastructure security must presume that a high percentage of end users will always make the wrong sorts of security deci- sions if allowed. The implication is that national infrastructure protection must never rely on the decision-making of end users through programs of awareness.

A further advance that is necessary for situational awareness involves enhancements in approaches to security metrics report- ing. Where the non-cyber national intelligence community has done a great job developing means for delivering daily intelligence briefs to senior government offi cials, the cyber security commu- nity has rarely considered this approach. The reality is that, for sit- uation awareness to become a structural component of national infrastructure protection, valid metrics must be developed to accurately portray status, and these must be codifi ed into a suit- able type of regular intelligence report that senior offi cials can use to determine security status. It would not be unreasonable to expect this cyber security intelligence to fl ow from a central point such as a fusion center, but in general this is not a requirement.

Response The principle of response involves assurance that processes are in place to react to any security-related indicator that becomes

Large-scale infrastructure protection requires a higher level of awareness than most groups currently employ.

Targeted at

Managers Collection

Raw Data

Combined Automation and Manual Process

Fusion

Intelligence

Situational

Awareness

Figure 1.11 Real-time situation awareness process fl ow.

Chapter 1 INTRODUCTION 27

available. These indicators should fl ow into the response pro- cess primarily from the situational awareness layer. National infrastructure response should emphasize indicators rather than incidents. In most current computer security applications, the response team waits for serious problems to occur, usually including complaints from users, applications running poorly, and networks operating in a sluggish manner. Once this occurs, the response team springs into action, even though by this time the security game has already been lost. For essential national infrastructure services, the idea of waiting for the service to degrade before responding does not make logical sense.

An additional response-related change for national infra- structure protection is that the maligned concept of “false posi- tive” must be reconsidered. In current small-scale environments, a major goal of the computer security team is to minimize the number of response cases that are initiated only to fi nd that nothing was wrong after all. This is an easy goal to reach by sim- ply waiting for disasters to be confi rmed beyond a shadow of a doubt before response is initiated. For national infrastructure, however, this is obviously unacceptable. Instead, response must follow indicators, and the concept of minimizing false positives must not be part of the approach. The only quantitative metric that must be minimized in national-level response is risk (see Figure 1.12 ).

A challenge that must be considered in establishing response functions for national asset protection is that relevant indica- tors often arise long before any harmful effects are seen. This suggests that infrastructure protecting must have accurate situ- ational awareness that considers much more than just visible impacts such as users having trouble, networks being down, or services being unavailable. Instead, often subtle indicators must

• Higher False-Positive Rate

• Lower Security Risk

• Recommended for National Infrastructure

Response Process

(pre-attack)

indicator indicator indicator

• Lower False-Positive Rate

• Higher Security Risk

• Use for National Infrastructure Only If Required

effect effect effect

Response Process

(post-attack)

attack threshold time

Figure 1.12 National infrastructure security response approach.

28 Chapter 1 INTRODUCTION

be analyzed carefully, which is where the challenges arise with false positives. When response teams agree to consider such indi- cators, it becomes more likely that such indicators are benign. A great secret to proper incident response for national infrastruc- ture is that higher false positive rates might actually be a good sign.

It is worth noting that the principles of collection, correlation, awareness, and response are all consistent with the implemen- tation of a national fusion center. Clearly, response activities are often dependent on a real-time, ubiquitous operations center to coordinate activities, contact key individuals, collect data as it becomes available, and document progress in the response activ- ities. As such, it should not be unexpected that national-level response for cyber security should include some sort of central- ized national center. The creation of such a facility should be the centerpiece of any national infrastructure protection program and should involve the active participation of all organizations with responsibility for national services.

Implementing the Principles Nationally To effectively apply this full set of security principles in practice for national infrastructure protection, several practical imple- mentation considerations emerge: ● Commissions and groups —Numerous commissions and

groups have been created over the years with the purpose of national infrastructure protection. Most have had some minor positive impact on infrastructure security, but none has had suffi cient impact to reduce present national risk to accept- able levels. An observation here is that many of these commis- sions and groups have become the end rather than the means toward a cyber security solution. When this occurs, their likeli- hood of success diminishes considerably. Future commissions and groups should take this into consideration.

● Information sharing —Too much attention is placed on infor- mation sharing between government and industry, perhaps because information sharing would seem on the surface to carry much benefi t to both parties. The advice here is that a comprehensive information sharing program is not easy to implement simply because organizations prefer to maintain a low profi le when fi ghting a vulnerability or attack. In addi- tion, the presumption that some organization—government or commercial—might have some nugget of information that could solve a cyber attack or reduce risk is not generally

A higher rate of false positives must be tolerated for national infrastructure protection.

Chapter 1 INTRODUCTION 29

consistent with practice. Thus, the motivation for a commer- cial entity to share vulnerability or incident-related informa- tion with the government is low; very little value generally comes from such sharing.

● International cooperation —National initiatives focused on creating government cyber security legislation must acknowl- edge that the Internet is global, as are the shared services such as the domain name system (DNS) that all national and global assets are so dependent upon. Thus, any program of national infrastructure protection must include provisions for interna- tional cooperation, and such cooperation implies agreements between participants that will be followed as long as everyone perceives benefi t.

● Technical and operational costs —To implement the princi- ples described above, considerable technical and operational costs will need to be covered across government and commer- cial environments. While it is tempting to presume that the purveyors of national infrastructure can simply absorb these costs into normal business budgets, this has not been the case in the past. Instead, the emphasis should be on rewards and incentives for organizations that make the decision to imple- ment these principles. This point is critical because it suggests that the best possible use of government funds might be as straightforward as helping to directly fund initiatives that will help to secure national assets. The bulk of our discussion in the ensuing chapters is techni-

cal in nature; that is, programmatic and political issues are conve- niently ignored. This does not diminish their importance, but rather is driven by our decision to separate our concerns and focus in this book on the details of “what” must be done, rather than “how.”

This page intentionally left blank

31 Cyber Attacks. DOI: © Elsevier Inc. All rights reserved.

10.1016/B978-0-12-384917-5.00002-0 2011

DECEPTION

Create a highly controlled network. Within that network, you place production systems and then monitor, capture, and analyze all activity that happens within that network Because this is not a production network, but rather our Honeynet, any traffic is suspicious by nature .

The Honeynet Project 1

The use of deception in computing involves deliberately mislead- ing an adversary by creating a system component that looks real but is in fact a trap. The system component, sometimes referred to as a honey pot , is usually functionality embedded in a computing or networking system, but it can also be a physical asset designed to trick an intruder. In both cases, a common interface is presented to an adversary who might access real functionality connected to real assets, but who might also unknowingly access deceptive functionality connected to bogus assets. In a well-designed decep- tive system, the distinction between real and trap functionality should not be apparent to the intruder (see Figure 2.1 ).

The purpose of deception, ultimately, is to enhance security, so in the context of national infrastructure it can be used for large-scale protection of assets. The reason why deception works is that it helps accomplish any or all of the following four security objectives: ● Attention —The attention of an adversary can be diverted from

real assets toward bogus ones. ● Energy —The valuable time and energy of an adversary can be

wasted on bogus targets.

2

1 The Honeynet Project, Know Your Enemy: Revealing the Security Tools, Tactics, and Motives of the Blackhat Community , Addison–Wesley Professional, New York, 2002. (I highly recommend this amazing and original book.) See also B. Cheswick and S. Bellovin, Firewalls and Internet Security: Repelling the Wily Hacker , 1st ed., Addison– Wesley Professional, New York, 1994; C. Stoll, The Cuckoo’s Egg: Tracking a Spy Through the Maze of Computer Espionage , Pocket Books, New York, 2005.

32 Chapter 2 DECEPTION

● Uncertainty —Uncertainty can be created around the veracity of a discovered vulnerability.

● Analysis —A basis can be provided for real-time security analy- sis of adversary behavior. The fact that deception diverts the attention of adversaries,

while also wasting their time and energy, should be familiar to anyone who has ever used a honey pot on a network. As long as the trap is set properly and the honey pot is suffi ciently realistic, adversaries might direct their time, attention, and energy toward something that is useless from an attack perspective. They might even plant time bombs in trap functionality that they believe will be of subsequent use in targeting real assets. Obviously, in a honey pot, this is not the case. This type of deception is a pow- erful deterrent, because it defuses a cyber attack in a way that could fool an adversary for an extended period of time.

The possibility that deception might create uncertainty around the veracity of a discovered vulnerability has been poorly explored to date. The idea here is that when an intruder inevitably stumbles onto an exploitable hole it would be nice if that intruder were led to believe that the hole might be a trap. Thus, under the right circumstances, the intruder might actu- ally choose to avoid exploitation of a vulnerability for fear that it has been intentionally planted. While this might seem diffi cult to implement in many settings, the concept is powerful because it allows security managers to defuse existing vulnerabilities without even knowing about them . This is a signifi cant enough concept that it deserves repeating: The use of deception in com- puting allows system security managers to reduce the risk of vul- nerabilities that they might not even know are present .

The fact that real-time analysis can be performed on a honey pot is reasonably well known in the computing community today.

Connected to

Real Assets

Connected to

Bogus Assets

Computing

Functionality

(Real)

Computing

Functionality

(Deceptive)

Normal

User

Normal Access

Common

Interface

Malicious

User

Normal Access

Figure 2.1 Use of deception in computing.

Deception is a powerful security tool, as it protects even unknown vulnerabilities.

Chapter 2 DECEPTION 33

Perhaps this is because it is a widely accepted best practice that security administrators should try to observe the behavior of intruders that have been detected. Most intrusion detection sys- tems, for example, include threat management back-end systems that are designed to support such an objective. In the best case, the forensic analysis gathered during deception is suffi ciently detailed to allow for identifi cation of the adversary and possibly even pros- ecution. In the most typical case, however, accurate traceability to the original human source of a problem is rarely accomplished.

Luckily, the success of deceptive traps is assisted by the fact that intruders will almost always view designers and opera- tors of national assets as being sloppy in their actions, defi cient in their training, and incompetent in their knowledge. This extremely negative opinion of the individuals running national infrastructure is a core belief in virtually every hacking com- munity in the world (and is arguably justifi ed in some environ- ments). Ironically, this low expectation is an important element that helps make stealth deception much more feasible, because honey pots do not always have to mimic a perfectly managed environment. Instead, adversaries can generally be led to fi nd a system environment that is poorly administered, and they will not bat an eyelash. This helps the deception designer.

The less well-understood case of openly advertised deception relies on the adversary believing that designers and operators of national assets are competent enough to plant a believable trap into a national asset. This view represents a hurdle, because the hacking community will need to see convincing evidence before they will ever believe that anyone associated with a large organization would be competent enough to manage a complex program of deceptive computing. This is too bad, because open use of deception carries great advantages, as we will explain in more detail below. In any event, the psychology of understanding and managing adversary views is not straightforward. This soft issue must become part of the national infrastructure protection equation but will obviously require a new set of skills among security experts.

The most common implementation of deception involves the insertion of fake attack entry points, such as open service ports, that adversaries might expect to see in a normal system. The hope is that an adversary would discover (perhaps with a scan- ner) and then connect to these open service ports, which would in turn then lead to a honey pot. As suggested above, creating realism in a honey pot is not an easy task, but several design options do exist. One approach involves routing inbound open port connections to physically separate bogus systems that are isolated from real assets. This allows for a “forklift”-type copying

Honey pots should not necessarily mimic perfect environments.

Effective cyber deception involves understanding your adversary.

34 Chapter 2 DECEPTION

of real functionality (perhaps with sensitive data sanitized) to an isolated, safe location where no real damage can be done.

Recall that, if the deception is advertised openly, the possibil- ity arises that an adversary will not bother to attempt an attack. Admittedly, this scenario is a stretch, but the possibility does arise and is worth mentioning. Nevertheless, we will assume for the balance of this discussion that the adversary fi nds the decep- tive entry point, presumes that it is real, and decides to move forward with an attack. If the subsequent deception is properly managed, then the adversary should be led down a controlled process path with four distinct attack stages: scanning , discovery , exploitation , and exposing (see Figure 2.2 ).

During the initial scanning stage, an adversary is search- ing through whatever means is available for exploitable entry points. The presumption in this stage is that the service inter- face includes trap functionality, such as bogus links on prox- ied websites that lead to a honey pot for collecting information. It is worth noting, however, that this “searching” process does not always imply the use of a network by an adversary. Instead, the adversary might be searching for exploitable entry points in contracts, processes, locked cabinets, safes, or even relation- ships with national infrastructure personnel. In practice, one might even expect a combination of computing and noncomput- ing searches for information about exploitable entry points. The deception must be designed accordingly.

During the discovery phase, an adversary fi nds an exploit- able entry point, which might be real or fake. If the vulnerability is real, then one hopes that good back-end security is in place to avoid an infrastructure disaster. Nevertheless, the decision on the

Forensics Performed

in This Stage

National Asset

Interface

Trap

Honey

Pot

Scanning Discovery Exploitation Exposing

Adversary

Figure 2.2 Stages of deception for national infrastructure protection.

Bear in mind that a cyber honey pot might require coordination with a tangible exploitable point outside the cyber world.

Chapter 2 DECEPTION 35

part of the intruder to exploit a discovered vulnerability, real or fake, is an important trigger point. Good infrastructure security systems would need to connect this exploitation point to a threat management system that would either open a security trouble ticket or would alert a security administrator that an intruder has either started an attack or fallen for the deceptive bait. Obviously, such alerts should not signal an intruder that a trap is present.

During the exploitation stage, the adversary makes use of the discovered vulnerability for whatever purposes they might have. If the vulnerability is real, then the usual infrastructure break-in scenario results. If the vulnerability is a trap, however, then its effectiveness will be directly related to the realism of the honey pot. For both stealth and non-stealth deception, this is the initial stage during which data becomes available for forensic analy- sis. A design consideration is that the actual asset must never become compromised as a result of the trap. This requirement will likely result in deceptive functionality running on computing “islands” that are functionally separated from the real assets.

During the exposing stage in deception, adversary behavior becomes available for observation. Honey pots should include suffi cient monitoring to expose adversary technique, intent, and identity. This is generally the stage during which management decisions are made about whether response actions are war- ranted. It is also a stage where real-time human actions are often required to help make the deceptive functionality look real. As we stated above, a great advantage that arises here is the low expec- tation the adversary will have regarding system administrative competency on the part of the infrastructure team. This allows the security team to use the excuse of poor setup to cover func- tional gaps that might exist in the deception.

Any one of the four stages of deception can raise signifi cant legal and social issues, so any program of national infrastruc- ture protection must have participation from the national legal community to determine what is considered acceptable. The difference between a passive trap and an active lure, for exam- ple, is subtle and must be clarifi ed before a live deployment is made into infrastructure. From a social perspective, one might hope that the acceptance that exists for using deception to catch online stalkers would be extended to the cyber security commu- nity for catching adversaries targeting national infrastructure.

Scanning Stage In this fi rst stage, the presumption is that an adversary is scan- ning whatever is available to fi nd exploitation points to attack

Actual assets must remain separate and protected so they are not compromised by a honey pot trap.

Monitoring honey pots takes security to the next level: potential for responsive action.

36 Chapter 2 DECEPTION

national infrastructure. This scanning can include online searches for web-based information, network scans to determine port availability, and even offl ine searches of documents for rele- vant information. Deception can be used to divert these scanning attempts by creating false entry points with planted vulnerabili- ties. To deal with the offl ine case, the deception can extend to noncomputing situations such as intentionally leaving a nor- mally locked cabinet or safe door open with bogus documents inserted to deceive a malicious insider.

The deceptive design goal during scanning is to make avail- able an interface with three distinct components: authorized services , real vulnerabilities , and bogus vulnerabilities . In a per- fect world, there would be no vulnerabilities, only authorized services. Unfortunately, given the extreme complexity associated with national infrastructure services, this is an unrealistic expec- tation, so real vulnerabilities will always be present in some way, shape, or form. When deception is used, these real vulnerabilities are complemented by fake ones and should be indistinguishable. Thus, an adversary will see three components when presented with a national asset interface with deception (see Figure 2.3 ).

Bogus vulnerabilities will generally be inserted based on the usual sorts of problems found in software. This is one of the few cases where the defi ciencies of the software engineering disci- pline can actually be put to good use for security. One might imag- ine situations where new vulnerabilities are discovered and then immediately implemented as traps in systems that require protec- tion. Nevertheless, planted holes do not always have to be based on such exploitable software bugs or system misconfi gurations. In some cases, they might correspond to properly administered func- tionality, but that might not be considered acceptable for local use.

Valid User

Adversary

National Asset

Authorized Service

Uncertainty About

Which is Real

Three Components of

Service Interface

Real

Vulnerabilities

Bogus

Vulnerabilities

Honey

Pots

Figure 2.3 National asset service interface with deception.

Chapter 2 DECEPTION 37

Honey Pots can be Built into Websites A good example of a trap based on properly administered functionality might be a promiscuous tab on a website that openly solicits leaks of information; this is found sometimes on some of the more controversial blog sites. If legal and policy acceptance is given, then these links might be connected in a local proxied Intranet to a honey pot collection site. Insiders to an organization might then consider leaking information directly using this link to the seemingly valid Internet site, only to be duped into providing the leak to the local security team. Again, this should only be considered for deployment if all legal and policy requirements are met, but the example does help illustrate the possibilities.

A prominent goal of deception is to observe the adversary in action. This is done via real-time collection of data about intruder activity, along with reasoned analysis about intent. For example, if the intruder seems to be guessing passwords over and over again to gain access to a honey pot system, the administrator might decide in real time to simply grant access. A great challenge is that the automation possibilities of such response are not currently well understood and are barely included in security research pro- grams. This is too bad, because such cases could really challenge and ultimately improve the skills of a good security administra- tor. One could even imagine national groups sponsoring contests between live intruders and live administrators who are battling against each other in real time in a contrived honey pot.

Deliberately Open Ports Intruders routinely search the Internet for servers that allow connections to exploitable inbound services. These services are exploitable generally because they contain some weakness such as a buffer overfl ow condition that can be tripped to gain privi- leged access. Once privileged access is obtained, the intruder can perform administrative tasks such as changing system fi les, installing malware, and stealing sensitive information. All good system administrators understand the importance of harden- ing servers by disabling all exploitable and unnecessary services. The problem is that hardening is a complex process that is made more diffi cult in environments where the operating system is proprietary and less transparent. Amazingly, most software and server vendors still deliver their products in confi gurations that include most services being default enabled.

The deliberate insertion of open service ports on an Internet- facing server is the most straightforward of all deceptive computing

Allowing an intruder access increases your risk level but also allows the security administrator to monitor the intruder’s moves.

38 Chapter 2 DECEPTION

practices. The deliberately open ports are connected to back-end honey pot functionality, which is connected to monitoring systems for the purpose of observation and analysis. The result is that serv- ers would thus present adversaries of national infrastructure with three different views of open service ports: (1) valid open ports one might expect, such as HTTP, DNS, and SMTP; (2) open ports that are inadvertently left open and might correspond to exploit- able software; and (3) open ports that are deliberately inserted and connected to bogus assets in a honey pot. As long as it is generally understood that deception could potentially be deployed, there could be some uncertainty on the part of the adversary about which open ports are deliberate and which are inadvertent (see Figure 2.4 ).

Security managers who use port scanners as part of a normal program of enterprise network protection often cringe at this use of deception. What happens is that their scanners will fi nd these open ports, which will result in the generation of reports that highlight the presumed vulnerabilities to managers, users, and auditors. Certainly, the output can be manually cropped to avoid such exposure, but this might not scale well to a large enterprise. Unfortunately, solutions are not easily identifi ed that solve this incompatibility between the authorized use of port scanners and the deliberate use of open ports as traps. It represents yet another area for research and development in deceptive computing.

Valid Open Ports

TCP 80: HTTP

TCP 53: DNS

TCP 25: SMTP

. . .

To Real Assets

To Bogus Assets

Trap Open Ports (Deliberate):

UDP 1820

UDP 1830

. . .

System A

Valid Open Ports

TCP 80: HTTP

TCP 53: DNS

TCP 25: SMTP

. . .

To Real Assets

To Bogus Assets

Open Ports (Inadvertant):

UDP 1334

UDP 1862

. . .

System B

Which is deliberate and which is inadvertent?

Intruder

Figure 2.4 Use of deceptive open ports to bogus assets.

Another challenge is for security managers to knowingly keep open ports after running scanners that highlight these vulnerabilities.

Chapter 2 DECEPTION 39

An additional consideration with the deliberate use of open ports is that care must be taken on the back end to ensure that real assets cannot be exploited. Not surprisingly, practical tech- niques for doing this are not well known. For example, if the back-end deceptive software connected to deliberately open ports shares resources with valid assets, then the potential exists for negative side effects. The only reasonable approach today would involve deliberately open ports on bogus servers that are honey pots with no valid resources. These servers should be subtly embedded into server complexes so they look normal, but they should be hardwired to separate honey pot assets. This reduces the likelihood of negative side effects on normal servers (see Figure 2.5 ).

In practice, the real challenge to the deceptive use of open ports is creating port-connected functionality that is suffi ciently valid to fool an expert adversary but also properly separated from valid services so no adversary could make use of the honey pot to advance an attack. Because computer science does not cur- rently offer much foundational assistance in this regard, national infrastructure protection initiatives must include immediate programs of research and development to push this technique forward.

Discovery Stage The discovery stage corresponds to the adversary fi nding and accepting the security bait embedded in the trap. The two corre- sponding security goals during this stage are to make an intruder believe that real vulnerabilities could be bogus and that bogus

Honey

Pot

Complex of Internet-Connected Servers

Servers

Should

Look Same

(Normal and

Honey Pot)

Subtly Embedded

Honey Pot Server

Normal

Server

Normal

Server

Figure 2.5 Embedding a honey pot server into a normal server complex.

40 Chapter 2 DECEPTION

vulnerabilities could be real. The fi rst of these goals is accom- plished by making the deception program well-established and openly known. Specifi c techniques for doing this include the following: ● Sponsored research —The use of deception in national infra-

structure could become generally presumed through the open sponsorship and funding of unclassifi ed research and devel- opment work in this area.

● Published case studies —The open publication of case studies where deception has been used effectively in national asset protection increases the likelihood that an adversary might consider a found vulnerability to be deliberate.

● Open solicitations —Requests for Information (RFIs) and Requests for Proposals (RFPs) should be openly issued by national asset protectors. This implies that funding must be directed toward security projects that would actually use deceptive methods. Interestingly, the potential that an adversary will hesitate

before exploiting a real vulnerability increases only when the use of deception appears to be a real possibility. It would seem a hollow goal, for example, to simply announce that deception is being used without honest efforts to really deploy such decep- tions in national infrastructure. This is akin to placing a home protection sign in the landscaping without ever installing a real security system. For openly advertised deception to work, the national infrastructure team must be fully committed to actually doing the engineering, deployment, and operation.

The second goal of making bogus vulnerabilities look real will be familiar to computer security experts who have considered the use of honey pots. The technique of duplication is often used in honey pot design, where a bogus system is a perfect copy of a real one but without the back-end connectivity to the real asset being protected. This is generally done by duplicating the front- end interface to a real system and placing the duplicate next to a back-end honey pot. Duplication greatly increases realism and is actually quite easy to implement in practice (see Figure 2.6 ).

As suggested above, the advantage of duplication in honey pot design is that it maximizes authenticity. If one fi nds, for example, a real vulnerability in some front-end server, then an image of that vulnerable server could be used in future deceptive confi g- urations. Programs of national infrastructure protection should thus fi nd ways to effectively connect vulnerability discovery pro- cesses to honey pot design. Thus, when a truly interesting vulner- ability is found, it can become the front end to a future deceptive trap.

Openly advertised use of deception may cause adversaries to question whether a discovered vulnerability is valid or bogus.

Turn discovered vulnerabilities into advantages by mimicking them in honey pot traps.

Chapter 2 DECEPTION 41

Deceptive Documents The creation and special placement of deceptive documents is an example method for tricking adversaries during discovery. This technique, which can be done electronically or manually, is espe- cially useful for detecting the presence of a malicious insider and will only work under two conditions: ● Content —The bogus document must include information that

is convincingly realistic. Duplication of a valid document with changes to the most sensitive components is a straightforward means for doing this.

● Protection —The placement of the bogus document should include suffi cient protections to make the document appear truly realistic. If the protection approach is thin, then this will raise immediate suspicion. Sabotage can be detected by pro- tecting the bogus document in an environment that cannot be accessed by anyone other than trusted insiders. An illustrative approach for national infrastructure protec-

tion would follow these steps: First, a document is created with information that references a specially created bogus asset, such as a phone number, physical location, or server. The informa- tion should never be real, but it should be very realistic. Next, the document is stored in a highly protected location, such as a locked safe (computer or physical). The presumption is that under normal circumstances the document should sit idly in the locked safe, as it should have no real purpose to anyone. Finally, the specially created bogus asset is monitored carefully for any attempted compromise. If someone fi nds and grabs the document, then one can conclude that some insider is not to be trusted.

Should BE NO OBVIOUS

or VISIBLE DIFFERENCES

to an ADVERSARY Off-line Duplication

(“Make a Copy of the Real Interface”)

Real Front-End

Interface

Real Back-End

Asset

Same Front-End

Interface

Back-End

Honey Pot

Figure 2.6 Duplication in honey pot design.

42 Chapter 2 DECEPTION

It should be obvious that the example scheme shown in Figure 2.7 works as well for an electronic document protected by encryption and access control as for a manual paper document locked in a protected safe. In both cases, one would expect that no one would ever correlate these bogus references. If it turns out that the monitoring shows access to these bogus assets in some related way, then one would have to assume that the pro- tected enclave has been compromised. (Monitoring a hotel might require complex logistics, such as the use of hidden cameras.) In any event, these assets would provide a platform for subsequent analysis of exploitation activity by the adversary.

Exploitation Stage The third stage of the deception lifecycle for an adversary involves exploitation of a discovered vulnerability. This is a key

Steps to Planting a Bogus Document To effectively plant a bogus document, consider following these steps: 1. Create a fi le with instructions for obtaining what would appear to be extremely sensitive information. The fi le could

include a phone number, an Internet address for a server, and perhaps a room location in some hotel. 2. Encrypt the fi le and store it on a server (or print and lock it in a safe) that one would presume to be protected from

inside or outside access. 3. Put monitoring of the server or safe in place, with no expectation of a time limit. In fact, the monitoring might go on

indefi nitely, because one would expect to see no correlative behavior on these monitored assets (see Figure 2.7 ).

Protected Enclave

(Should Prevent Normal Access)

Correlative Monitoring

(Only Invoked if Bogus Document Used) Adversary

Believes

Bogus

Document Bogus AssetsBogus Document

In-line references to . . .

telephone (987) 654-3210

address 192.123.4567

hotel rm. 1a, 23 main st.

(987)

654-3210

1a, 23 main st.

192.

123.4567

Figure 2.7 Planting a bogus document in a protected enclave.

Chapter 2 DECEPTION 43

step in the decision process for an adversary because it is usu- ally the fi rst stage in which policy rules or even laws are actu- ally violated. That is, when an intruder begins to create a cyber attack, the initial steps are preparatory and generally do not vio- late any specifi c policy rules or laws. Sometimes security experts refer to this early activity as low radar actions , and when they are detected they are referred to as indications and warnings . Determining whether to respond to indications and warnings is a challenge, because response requires time and energy. If the track record of the security team involves many response actions to indications and warnings that are largely false positives, then the organization is often tempted to reduce the response trig- ger point. This is a bad idea for national infrastructure, because the chances increase that a real event will occur that is not responded to promptly.

As such, the protection of national infrastructure should involve a mind shift away from trying to reduce false positive responses to indications and warnings. Instead, the goal should be to deal with all instances in which indication and warning actions would appear to be building up to the threshold at which exploitation begins. This is especially important, because this threshold marks the fi rst stage during which real assets, if tar- geted, might actually be damaged (see Figure 2.8 ).

The key requirement at this decision point is that any exploi- tation of a bogus asset must not cause disclosure, integrity, theft, or availability problems with any real asset. Such non- interference between bogus and real assets is easiest to accom- plish when these assets are kept as separate as possible. Physical separation of assets is straightforward; a real software applica- tion with real data, for example, could be separated from a bogus application with fake data by simply hosting each on different

Post-Attack

Stages

Pre-Attack

Stages

ExploitationDiscoveryScanning

Decision to

Exploit Discovered

Vulnerability Vulnerability

Discovered

Figure 2.8 Pre- and post-attack stages at the exploitation stage.

Responding to a large number of false positives is necessary to adequately protect national infrastructure.

44 Chapter 2 DECEPTION

servers, perhaps even on different networks. This is how most honey pots operate, and the risk of interference is generally low.

Achieving noninterference in an environment where resources are shared between real and fake assets is more challenging. To accomplish this goal, the deception designer must be creative. For example, if some business process is to be shared by both real and fake functionality, then care must be taken by the decep- tion operators to ensure that real systems are not degraded in any way. Very little research has been done in this area, especially for availability threats. Allowing a malicious adversary to execute programs on a live, valid system, for example, would provide opportunities for malicious resource exhaustion. Nevertheless, the general approach has considerable promise and deserves more attention.

A related issue involves the possibility that intrusion detection and incident response systems might be fooled during exploita- tion into believing that trap functionality is real. White hat teams in companies have dealt with this problem for years, and they must coordinate with security teams to ensure that their activity does not cause a false alarm. This can be accomplished in several ways: ● Process coordination —This involves the honey pot team coor-

dinating their activities in advance with the infrastructure security teams. The problem is that it tends to highlight the deception and might destroy some hidden transparency, espe- cially if the deception is designed to detect malicious insiders.

● Trap isolation —This involves making certain that security systems, such as intrusion detection probes, are not in the deceptive path. Ongoing architectural analysis is required in this case to make sure that the condition holds throughout the system lifecycle.

● Back-end insiders —If the security team includes some trusted insiders involved in response activities, then they might be able to ensure that a response to deceptive action does not waste time and resources. This works best if the insider is a decision-maker.

● Process allowance —In this case, the detection and response activities are allowed to proceed. This is the recommended case if the deception is considered sensitive and must be totally hidden from insiders. The exploitation stage is the most dangerous part of the

deceptive lifecycle because it involves real malicious activity from an adversary. Infrastructure teams must learn to under- stand and respect the potential for real damage if this stage is not managed carefully.

When bogus and real assets reside on the same server, vulnerability risk increases dramatically.

Chapter 2 DECEPTION 45

Procurement Tricks One way to understand adversary behavior is to compare it in dif- ferent environments. An example involves a deception designer creating two separate supplier solicitations for a given product or service. One solicitation would be for a benign, noncritical, non- sensitive application; the other would be for an obviously sensi- tive, nationally critical application. In both cases, exactly the same product or service would be requested, but when they are deliv- ered to each application detailed examination would be initiated to identify differences. Any differences found in the delivered product by the intentionally planted “critical buyer” and “benign buyer” would be viewed as potential exploits (see Figure 2.9 ).

The deception described above only works if suffi cient foren- sic capability exists to compare the two delivered products. For any product or service, this could include comparison of rela- tive software size, system performance, product documenta- tion, service functionality, or technical support. One could even imagine a second level of deception using social engineering where an impassioned plea would be made to the supplier for some undocumented type of emergency support, usually remote administration. If either of the delivered products is set up for such remote administration, then the national asset manager would know that something is wrong.

Delivered

Product

Deception Designer

Exactly

Same

Differences

Must Be

Explained

Should Be

Exactly Same

Ensure

Specs

Same

Monitor

Supplier

Activity

Carefully

Compare

Products

Delivered

Product

Supplier

Create

Two

Buyers

Benign Buyer

(e.g., school)

Critical Buyer

(e.g., military)

Order

Specification

Order

Specification

Figure 2.9 Using deception against malicious suppliers.

46 Chapter 2 DECEPTION

The procurement lifecycle is one of the most underestimated components in national infrastructure protection from an attack perspective. Generally, security teams focus on selecting, test- ing, installing, and operating functionality, with seemingly mun- dane procurement tasks left to the supply chain team. This is a huge mistake, and adversaries understand this point well. Thus, national infrastructure protection initiatives must extend to the procurement process, and the clever use of deception is a power- ful tool in this regard.

Exposing Stage The fi nal stage in the deception lifecycle involves the adversary exposing behavior to the deception operator. Presumably, in this stage, the adversary is now hacking away at the trap functionality, convinced that all systems and assets are real. All sorts of possi- bilities arise in terms of how this hacking will proceed. It could be a fl urry of intense activity in a short period of time or it could be a drawn-out process of low and slow actions, so the decep- tion team must have patience. Also, during this stage, the adver- sary might expose the use of well-known hacking techniques and tools or, alternatively, could demonstrate use of techniques not previously seen by the security team (see Figure 2.10 ).

The challenge in this stage is that the deception must allow a window for observation of intruder activity, but must also be hidden. It must provide a convenient interface for the deception team to collect data but also must provide a way for commands to be issued or changes to be made in real time. Unfortunately, few commercial products exist that are designed to support these features. Specifi c functional requirements for the monitoring

Real-Time Forensic Analysis

of Adversary Behavior

Exploitation/ExposingDiscoveryScanning

Vulnerability is

Discovered

Decision to Exploit

Vulnerability

Figure 2.10 Adversary exposing stage during deception.

National infrastructure protection must extend from procurement to operating functionality in order to be truly effective.

Chapter 2 DECEPTION 47

environment during the exposing stage of deception include the following: ● Suffi cient detail —The monitoring environment must provide

suffi cient detail so the deception operator can determine what is going on. For example, overly cryptic audit logs in terse for- mat with gaps in certain areas would not be the best approach. The usual administrative interface to an operating system (generally through a command interface) is often the most desirable approach. One should not expect fancy, colorful dis- plays for the monitoring task because most security analysts prefer the convenience of a terse command line interface.

● Hidden probes —Monitoring in this stage of the deception works only if it is completely hidden. If an adversary fi g- ures out that someone is watching, then behavior modifi ca- tion would occur immediately. Simple tasks must therefore be implemented such as suppressed listing of any processes launched by the deception team (unless desired). The art of creating realistic functionality to hide probes requires support and nurturing in the security community.

● Real-time observation —The deception operator should have access to information about exposed behavior as it happens. The degree of real time for such monitoring (e.g., instantaneous, within seconds, within minutes) would depend on the local cir- cumstances. In most cases, this observation is simply done by watching system logs, but more advanced tools are required to record and store information about intruder behavior. As we suggested above, in all cases of deception monitoring

the key design goal should be to ensure a believable environ- ment. No suspicious or unexplainable processes should be pres- ent that could tip off an intruder that logging is ongoing. Fake audit logs are also a good way to create believability; if a honey pot is developed using an operating system with normal audit logging, then this should be enabled. A good adversary will likely turn it off. The idea is that hidden monitoring would have to be put in place underneath the normal logging—and this would be functionality that the adversary could not turn off.

Interfaces Between Humans and Computers The gathering of forensic evidence during the analysis of intruder behavior in a honey pot often relies on detailed understanding of how systems, protocols, and services interact. Specifi cally, this type of communication can be performed in four different ways: human-to-human , human-to-computer , computer-to-human , and

Observing intruder activity can be an informative but risky process during the exposure stage.

48 Chapter 2 DECEPTION

computer-to-computer . If we take the fi rst term (human or com- puter) to mean the intruder and we take the second term to mean the honey pot manager, then we can make some logical distinctions.

First, it should be obvious that, in an automated attack such as a botnet, the real-time behavior of the attack system will not change based on some subjective observation of honey pot func- tionality. Certainly, the interpretation of the results of the bot- net could easily affect the thinking of the botnet operator, but the real-time functionality is not going to be affected. As such, the most powerful cases in real-time forensic analysis of honey pot behavior will be the cases where human-to-human and human-to-computer interactions are being attempted by an intruder. Let’s examine each in turn.

The most common human-to-human interaction in national infrastructure involves help desk or customer care support func- tions, and the corresponding attack approach involves social engineering of such activity. The current state of the art in deal- ing with this vulnerability is to train operators and customer care personnel to detect attempts at social engineering and to report them to the security team. Deception, however, introduces a more interesting option. If the likelihood is high that social engi- neering is being attempted, then an advanced approach to pro- tection might involve deceiving the adversary into believing that they have succeeded. This can be accomplished quite easily by simply training operators to divert social engineering attempts to specially established help desks that are phony. The operators at these phony desks would reverse social engineer such attackers to get them to expose their identity or motivation (see Figure 2.11 ).

The most common human-to-computer interaction occurs when an intruder is trying to gain unauthorized access through a series of live, interactive commands. The idea is that intruders should be led to believe that their activity is invoking services on the target system, as in the usual type of operating system hacking. A good example might involve an intruder repeatedly trying to execute some command or operation in a trap system. If

1. Attempt to Social Engineer

Help Desk

(Real)

2. Suspicious Call Diverted

3. Reverse Social Engineering (Attempt to Determine Identity)

Help Desk

(Deceptive)

Figure 2.11 Deceptively exploiting the human-to-human interface.

Real-time forensic analysis is not possible for every scenario, such as a botnet attack.

Chapter 2 DECEPTION 49

the security team notices this intent and can act quickly enough, the desired command or operation could be deliberately led to execute. This is a tricky engagement, because an expert adver- sary might notice that the target confi guration is changing, which obviously is not normal.

National Deception Program One might hope that some sort of national deception program could be created based on a collection of traps strategically planted across national infrastructure components, tied together by some sort of deception analysis backbone. Such an approach is unlikely, because deception remains a poorly understood secu- rity approach, and infrastructure managers would be very hesi- tant to allow traps to be implanted in production systems. These traps, if they malfunction or do not work as advertised, could trick authorized users or impede normal operations.

Any realistic assessment of current security and information technology practice suggests that large-scale adoption of decep- tion for national infrastructure protection would not be widely accepted today. As a result, programs of national deception would be better designed based on the following assumptions: ● Selective infrastructure use —One must assume that cer-

tain infrastructure components are likely to include decep- tive traps but that others will not. At the time of this writing, many infrastructure teams are still grappling with basic com- puter security concepts; the idea that they would agree to install traps is not realistic. As such, any program of national deception must assume that not all components would utilize honey pots in the same manner.

● Sharing of results and insights —Programs of national decep- tion can and should include a mechanism for the sharing of results and insights gained through operational use of traps and honey pots. Certainly, insight obtained through forensic analysis of adversary behavior can be shared in a structured manner.

● Reuse of tools and methods —National deception programs could serve as means for making honey pot and trap software available for deployment. In some cases, deception tools and methods that work in one infrastructure area can be reused in another. The most common criticism of deception in large-scale

national security is that automated tools such as botnets are not affected by trap functionality. While it is true that botnets attack

An expert adversary may become aware of the security team observing the attempted intrusion.

50 Chapter 2 DECEPTION

infrastructure in a blindly automated manner regardless of whether the target is real or fake, the possibility remains that trap functionality might have some positive impact. A good example might be national coordination of numerous bogus endpoints that might be ready and willing to accept botnet software. If these endpoints are designed properly, one could imagine them being deliberately designed to mess up the botnet communication, perhaps by targeting the controllers themselves. This approach is often referred to as a tarpit , and one might imagine this method being quite interesting for degrading the effectiveness of a botnet.

51 Cyber Attacks. DOI: © Elsevier Inc. All rights reserved.

10.1016/B978-0-12-384917-5.00003-2 2011

SEPARATION

A limitation of firewalls is that they can only be as good as their access controls and filters. They might fail to detect subversive packets. In some situations, they might be bypassed altogether. For example, if a computer behind a firewall has a dial-up port, as is all too common, an intruder can get access by dialing the machine .

Dorothy Denning 1

The separation of network assets from malicious intruders using a fi rewall is perhaps the most familiar protection approach in all of computer security. Today, you will fi nd some sort of fi rewall deployed in or around virtually every computer, application, sys- tem, and network in the world. They serve as the centerpiece in most organizations’ security functionality, including intrusion detection, antivirus fi ltering, and even identity management. An enormous fi rewall industry has emerged to support such mas- sive deployment and use, and this industry has done nothing but continue to grow for years and years.

In spite of this widespread adoption, fi rewalls as separation mechanisms for large-scale infrastructure have worked to only a limited degree. The networks and systems associated with national infrastructure assets tend to be complex, with a multi- tude of different entry points for intruders through a variety of Internet service providers. In addition, the connectivity require- ments for complex networks often result in large rule sets that permit access for many different types of services and source addresses. Worse, the complexity of large-scale networks often leads to unknown, unprotected entry points into and out of the enterprise (see Figure 3.1 ).

Certainly, the use of traditional perimeter fi rewalls will con- tinue to play a role in the protection of national assets, as we will describe below. Egress fi ltering, for example, is often most effi ciently performed at the perceived perimeter of an organiza- tion. Similarly, when two or more organizations share a private

3

1 D. Denning, Information Warfare and Security , Addison–Wesley, New York, 1999, p. 354.

Firewalls are valuable and frequently employed but may not provide enough protection to large-scale networks.

52 Chapter 3 SEPARATION

connection, the connection endpoints are often the most natu- ral place to perform fi rewall fi ltering, especially if traditional circuit-switched connections are involved. To achieve optimal separation in the protection of large-scale national assets, how- ever, three new fi rewall approaches will be required: ● Network-based separation —Because the perimeter of any

complex national infrastructure component will be diffi cult to defi ne accurately, the use of separation methods such as network-based fi rewalls is imperative. Such cloud-based func- tionality allows a broader, more accurate view of the egress and ingress activity for an organization. It also provides a richer environment for fi ltering high-capacity attacks. The fi ltering of denial of service attacks aimed at infrastructure, for example, can only be stopped with special types of cloud- based fi ltering fi rewalls strategically placed in the network.

● Internal separation —National infrastructure protection will require a program of internal asset separation using fi rewalls strategically placed in infrastructure. This type of separation of internal assets using fi rewalls or other separation mecha- nisms (such as operating system access controls) is not gener- ally present in most infrastructure environments. Instead, the

Perimeter

Single Firewall

Simple

Network

Single

Internet Service

Provider

Large,

Non-Uniform

Rule Bases

Complexity

of Multiple

Providers

Unknown,

Unprotected

Link

Complex

Connectivity

to Firewall

Multiple

Internet

Service

Providers

Complex

Network

Figure 3.1 Firewalls in simple and complex networks.

Chapter 3 SEPARATION 53

idea persists that insiders should have unrestricted access to internal resources and that perimeter fi rewalls should protect resources from untrusted, external access. This model breaks down in complex infrastructure environments because it is so easy to plant insiders or penetrate complex network perimeters.

● Tailored separation —With the use of specialized protocols in national infrastructure management, especially supervisory control and data acquisition (SCADA), tailoring fi rewalls to handle unique protocols and services is a requirement. This is a challenge because commercial fi rewalls are generally designed for generic use in a wide market and tailoring will require a more focused effort. The result will be more accurate fi rewall operation without the need to open large numbers of service ports to enable SCADA applications. The reader might be amused to consider the irony pre-

sented today by network connectivity and security separation. Twenty years ago, the central problem in computer network- ing involved the rampant interoperability that existed between systems. Making two computers connect over a network was a signifi cant challenge, one that computer scientists worked hard to overcome. In some instances, large projects would be initi- ated with the goal of connecting systems together over networks. Amazingly, the challenge we deal with today is not one of con- nectivity, but rather one of separation. This comes from the ubiq- uity of the Internet Protocol (IP), which enables almost every system on the planet to be connected with trivial effort. Thus, where previously we did not know how to interconnect systems, today we don’t know how to separate them!

What Is Separation? In the context of national infrastructure protection, separation is viewed as a technique that accomplishes one of the following security objectives: ● Adversary separation —The fi rst separation goal involves sepa-

rating an asset from an adversary to reduce the risk of direct attack. Whatever implementation is chosen should result in the intruder having no direct means for accessing national assets.

● Component distribution —The second separation goal involves architecturally separating components in an infrastructure to distribute the risk of compromise. The idea here is that a com- promise in one area of infrastructure should not be allowed to propagate directly.

Now that we are able to connect systems with ease, we must learn to separate them for protection!

Commercially available fi rewalls are not designed for the large-scale complexity of our national infrastructure networks.

54 Chapter 3 SEPARATION

The access restrictions that result from either of these separa- tion approaches can be achieved through functional or physical means. Functional means involve software, computers, and net- works, whereas physical means include tangible separations such as locks, safes, and cabinets. In practice, most separation access restrictions must be designed to focus on either the insider or outsider threat. The relationship between these different separa- tion options can be examined based on the three primary factors involved in the use of separation for protecting infrastructure (see box).

A Working Taxonomy of Separation Techniques The three primary factors involved in the use of separation for protecting infrastructure include the source of the threat (insider or outsider), the target of the security control (adversary or asset), and the approach used in the security control (functional or physical). We can thus use these three factors to create a separation taxonomy that might help to compare and contrast the various options for separating infrastructure from adversaries (see Figure 3.2 ).

The fi rst column in the taxonomy shows that separation controls are focused on keeping either insiders or outsiders away from some asset. The key difference here is that insiders would typically be more trusted and would have more opportunity to gain special types of access. The second column indicates that the separation controls are focused on either keeping an adversary away from some asset or inherently separating components of the actual asset, perhaps through distribution. The third column identifi es whether the separation approach uses computing functionality or would rely instead on some tangible, physical control.

Threat

Insider Adversary Functional Internal access control

Outsider Adversary Functional Internet-facing firewall

Insider Asset Functional Application separation

Functional

Adversary

Techniques

Functional

Asset

Techniques

Physical

Adversary

and Asset

Techniques

Outsider Asset Functional Application distribution

Insider Adversary Physical Project compartmentalization

Outsider Adversary Physical Information classification

Insider Asset Physical Internal network diversity

Outsider Asset Physical Physical host distribution

Target Approach Example

Figure 3.2 Taxonomy of separation techniques.

Chapter 3 SEPARATION 55

Functional Separation Functional separation of an adversary from any computing asset is most commonly achieved using an access control mechanism with the requisite authentication and identity management. Access controls defi ne which users can perform which actions on which entities. The access rules should be predetermined in a security policy. They should specify, for example, which users can access a given application, and, obviously, the validation of user identity must be accurate. In some cases, security policy rules must be more dynamic, as in whether a new type of traffi c stream is allowed to proceed to some Internet ingress point. This might be determined by real-time analysis of the network fl ow.

An access policy thus emerges for every organization that identifi es desired allowances for users requesting to perform actions on system entities. Firewall policies are the most com- mon example of this; for example, users trying to connect to a web server might be subjected to an access control policy that would determine if this was to be permitted. Similarly, the IP addresses of some organization might be keyed into a fi rewall rule to allow access to some designated system. A major prob- lem that occurs in practice with fi rewalls is that the rule base can grow to an enormous size, with perhaps thousands of rules. The result is complexity and a high potential for error. National infrastructure initiatives must identify rewards and incentives for organizations to keep their fi rewall rule bases as small as pos- sible. Some organizations have used optimization tools for this purpose, and this practice should be encouraged for national assets.

From the fi rst two rows of the taxonomy, it should be clear that internal access controls demonstrate a functional means for separating insider adversaries from an asset, whereas Internet fi rewalls achieve roughly the same end for outside adversaries. These fi rewalls might be traditional devices, as one might fi nd in an enterprise, or special fi ltering devices placed in the network to throttle volume attacks. The third and fourth rows show that logical separation of an application is a good way to complicate an insider attack; this is comparably done for outsiders by distributing the application across different Internet-facing hosts. The last four rows in Figure 3.2 demonstrate different ways to use physical means to protect infrastructure, ranging from keeping projects and people separate from an asset to maintaining diversity and distribution of infrastructure assets. The following sections provide more detail on these separation taxonomy elements.

56 Chapter 3 SEPARATION

Two broad categories of security can be followed when trying to achieve functional separation of adversaries from any type of national infrastructure assets. The fi rst involves distributing the responsibility for access mediation to the owners of smaller asset components such as individual computers or small networks; the second involves deployment of a large, centralized mediation mechanism through which all access control decisions would be made (see Figure 3.3 ).

The distributed approach has had considerable appeal for the global Internet community to date. It avoids the problem of having to trust a large entity with mediation decisions, it allows for com- mercial entities to market their security tools on a large scale to end users, and it places control of access policy close to the asset, which presumably should increase the likelihood that the policy is appropriate. The massive global distribution of computer security responsibility to every owner of a home personal computer is an example of this approach. End users must decide how to protect their assets, rather than relying on some centralized authority.

Unfortunately, in practice, the distributed approach has led to poor results. Most end users are unqualifi ed to make good deci- sions about security, and even if a large percentage make excellent decisions, the ones who do not create a big enough vulnerability as to place the entire scheme at risk. Botnets, for example, prey on poorly managed end-user computers on broadband connections. When a home computer is infected with malware, there really is no centralized authority for performing a cleansing function. This lack of centralization on the Internet thus results in a huge secu- rity risk. Obviously, the Internet will never be redesigned to include centralized control; that would be impractical, if not impossible.

One Firewall

Centralized MediationDistributed Mediation

Multiple Firewalls

Internet

Figure 3.3 Distributed versus centralized mediation.

In large networks, fi rewall rules can become so numerous that they actually increase the margin for error.

Chapter 3 SEPARATION 57

For national infrastructure, however, the possibility does exist for more centralized control. The belief here is that an increased reliance on centralized protection, especially in con- junction with the network service provider, will improve overall national asset protection methods. This does not imply, how- ever, that distributed protection is not necessary. In fact, in most environments, skilled placement of both centralized and distributed security will be required to avoid national infra- structure attack.

National Infrastructure Firewalls The most common application of a fi rewall involves its place- ment between a system or enterprise to be protected and some untrusted network such as the Internet. In such an arrangement for the protection of a national asset, the following two possibili- ties immediately arise: ● Coverage —The fi rewall might not cover all paths between the

national asset to be protected and the untrusted network such as the Internet. This is a likely case given the general complex- ity associated with most national infrastructure.

● Accuracy —The fi rewall might be forced to allow access to the national asset in a manner that also provides inadvertent, unau- thorized access to certain protected assets. This is common in large-scale settings, especially because specialized protocols such as those in SCADA systems are rarely supported by com- mercial fi rewalls. As a result, the fi rewall operator must compen- sate by leaving certain ports wide open for ingress traffi c. To address these challenges, the design of national security

infrastructure requires a skillful placement of separation func- tionality to ensure that all relevant traffi c is mediated and that no side effects occur when access is granted to a specifi c asset. The two most effective techniques include aggregation of protections in the wide area network and segregation of protections in the local area network (see Figure 3.4 ).

Aggregating fi rewall functionality at a defi ned gateway is not unfamiliar to enterprise security managers. It helps ensure cov- erage of untrusted connections in more complex environments. It also provides a means for focusing the best resources, tools, and staff to one aggregated security complex. Segregation in a local area network is also familiar, albeit perhaps less practiced. It is effective in reducing the likelihood that external access to System A has the side effect of providing external access to System B. It requires management of more devices and does

Centralized control versus multiple, independent fi rewalls—both have their advantages, so which is best for national infrastructure?

58 Chapter 3 SEPARATION

generally imply higher cost. Nevertheless, both of these tech- niques will be important in national infrastructure fi rewall placement.

A major challenge to national infrastructure comes with the massive increase in wireless connectivity that must be presumed for all national assets in the coming years. Most enterprise work- ers now carry around some sort of smart device that is ubiqui- tously connected to the Internet. Such smart devices have begun to resemble computers in that they can support browsing, e-mail access, and even virtual private network (VPN) access to applica- tions that might reside behind a fi rewall. As such, the ease with which components of infrastructure can easily bypass defi ned fi rewall gateways will increase substantially. The result of this increased wireless connectivity, perhaps via 4G deployment, will be that all components of infrastructure will require some sort of common means for ensuring security.

Massive distribution of security to smart wireless endpoint devices may not be the best option, for all the reasons previously cited. It would require massive distribution, again, of the security responsibility to all owners of smart devices. It also requires vigi- lance on the part of every smart device owner, and this is not a reasonable expectation. An alternative approach involves iden- tifying a common transport infrastructure to enforce desired policy. This might best be accomplished via the network trans- port carrier. Network service providers offer several advantages with regard to centralized security: ● Vantage point —The network service provider has a wide van-

tage point that includes all customers, peering points, and

Firewall Aggregation

(Wide Area)

Firewall Segregation

(Local Area)

Internet

A

C

B

Figure 3.4 Wide area fi rewall aggregation and local area fi rewall segregation.

Effective protection of national infrastructure will undoubtedly be expensive due to the increased management of devices.

Smart devices have added another layer of complexity to network protection.

Chapter 3 SEPARATION 59

gateways. Thus, if some incident is occurring on the Internet, the service provider will observe its effects.

● Operations —Network service providers possess the opera- tional capability to ensure up-to-date coverage of signatures, updates, and new security methods, in contrast to the inabil- ity of most end users to keep their security software current.

● Investment —Where most end users, including enterprise groups, are unlikely to have funds suffi cient to install multiple types of diverse or even redundant security tools, service pro- viders can often support a business case for such investment. For these reasons, a future view of fi rewall functionality for

national infrastructure will probably include a new aggregation point—namely, the concept of implementing a network-based fi rewall in the cloud (see Figure 3.5 ).

In the protection of national infrastructure, the use of net- work-based fi rewalls that are embedded in service provider fab- ric will require a new partnership between carriers and end-user groups. Unfortunately, most current telecommunications ser- vice level agreements (SLAs) are not compatible with this notion, focusing instead on packet loss and latency issues, rather than policy enforcement. This results in too many current cases of a national infrastructure provider being attacked, with the ser- vice provider offering little or no support during the incident.

Service

Provider

Fabric

Network-Based Firewall

(Provider Managed)

Internet

A

B

Wireless

Connection

(3G/4G)

C

Wired

Connection

Figure 3.5 Carrier-centric network-based fi rewall.

A fi rewall in the cloud may be the future of fi rewall functionality.

60 Chapter 3 SEPARATION

Obviously, this situation must change for the protection of national assets.

DDOS Filtering A major application of the network-based fi rewall concept includes a special type of mediation device embedded in the wide area network for the purpose of throttling distributed denial of service (DDOS) attacks. This device, which can be crudely referred to as a DDOS fi lter , is essential in modern networking, given the magnifi ed risk of DDOS attacks from botnets. Trying to fi lter DDOS attacks at the enterprise edge does not make sense given the physics of network ingress capacity. If, for example, an enterprise has a 1-Gbps ingress connection from the Internet, then a botnet directing an inbound volume of anything greater than 1 Gbps will overwhelm the connection.

The solution to this volume problem is to move the fi lter- ing upstream into the network. Carrier infrastructure gener- ally provides the best available option here. The way the fi ltering would work is that volumetric increases in ingress traffi c would cause a real-time redirection of traffi c to a DDOS fi ltering com- plex charged with removing botnet-originating traffi c from valid traffi c. Algorithms for performing such fi ltering generally key on the type of traffi c being sent, the relative size of the traffi c, and any other hint that might point to the traffi c being of an attack nature. Once the traffi c has been fi ltered, it is then funneled to the proper ingress point. The result is like a large safety valve or shock absorber in the wide area network that turns on when an attack is under way toward some target enterprise (see Figure 3.6 ).

Quantitative analysis associated with DDOS protection of national infrastructure is troubling. If, for example, we assume that bots can easily steal 500 Kbps of broadband egress from the unknowing infected computer owner, then it would only require three bots to overwhelm a T1 (1.5-Mbps) connection. If one carries out this argument, then botnets with 16,000 bots are suffi cient to overwhelm a 10-Gbps connection. Given the exis- tence of prominent botnets such as Storm and Confi cker, which some experts suggest could have as many as 2 or 3 million bots, the urgency associated with putting DDOS fi ltering in place cannot be understated. An implication is that national infrastruc- ture protection initiatives must include some measure of DDOS fi ltering to reduce the risk of DDOS attacks on national assets.

A serious problem that must be addressed, however, in current DDOS attacks on infrastructure involves a so-called

The risk of DDOS attacks must be effectively addressed.

Moving the fi ltering functionality into the network will allow legitimate traffi c to pass through and the discovery of potential DDOS attacks.

Chapter 3 SEPARATION 61

amplifi cation approach. Modern DDOS attacks are generally designed in recognition of the fact that DDOS fi lters exist to detect large inbound streams of unusual traffi c. Thus, to avoid inbound fi ltering in carrier infrastructure, adversaries have begun to follow two design heuristics. First, they design DDOS traffi c to mimic normal system behavior, often creating transac- tions that look perfectly valid. Second, they design their attack to include small inbound traffi c that utilizes some unique aspect of the target software to create larger outbound responses. The result is a smaller, less obvious inbound stream which then pro- duces much larger outbound response traffi c that can cause the DDOS condition.

1 Gbps

Ingress

>> 1 Gbps DDOS Traffic

Redirected to Filters

<< 1 Gbps Valid Traffic

Tunneled to Target A

Carriers

Target A

Bots >> 1 Gbps DDOS Traffic

Aimed at Target A

Target A’s

Designated

Carrier

Figure 3.6 DDOS fi ltering of inbound attacks on target assets.

The Great Challenge of Filtering Out DDOS Attacks The great challenge regarding current DDOS attacks is that the only way to avoid the sort of problem mentioned in the text is through nontrivial changes in target infrastructure. Two of these nontrivial changes are important to mention here: 1. Stronger authentication of inbound inquiries and transactions from users is imperative. This is not desirable for

e-commerce sites designed to attract users from the Internet and also designed to minimize any procedures that might scare away customers.

2. To minimize the amplifi cation effects of some target system, great care must go into analyzing the behavior of Internet-visible applications to determine if small inquiries can produce much larger responses. This is particularly important for public shared services such as the domain name system, which is quite vulnerable to amplifi cation attacks.

These types of technical considerations must be included in modern national infrastructure protection initiatives.

Modern DDOS attacks take into account a more advanced fi ltering system and thus design the DDOS traffi c accordingly.

62 Chapter 3 SEPARATION

SCADA Separation Architecture Many critical national infrastructure systems include supervi- sory control and data acquisition (SCADA) functionality. These systems can be viewed as the set of software, computers, and networks that provide remote coordination of controls systems for tangible infrastructures such as power generation systems, chemical plants, manufacturing equipment, and transportation systems. The general structure of SCADA systems includes the following components: ● Human-machine interface (HMI) —The interface between the

human operator and the commands relevant to the SCADA system

● Master terminal unit (MTU) —The client system that gathers data locally and transmits it to the remote terminal unit

● Remote terminal unit (RTU) —The server that gathers data remotely and sends control signals to fi eld control systems

● Field control systems —Systems that have a direct interface to fi eld data elements such as sensors, pumps, and switches The primary security separation issue in a SCADA system archi-

tecture is that remote access from an MTU to a given RTU must be properly mediated according to a strong access control policy. 2 The use of fi rewalls between MTUs and RTUs is thus imperative in any SCADA system architecture. This separation must also enforce policy from any type of untrusted network, such as the Internet, into the RTUs. If this type of protection is not present, then the obvious risk emerges that an adversary can remotely access and change or infl uence the operation of a fi eld control system.

As one might expect, all the drawbacks associated with large- scale fi rewall deployment are also present in SCADA systems. Coverage and accuracy issues must be considered, as well as the likelihood that individual components have direct or wireless connections to the Internet through unknown or unapproved channels. This implies that protection of RTUs from unauthor- ized access will require a combination of segregated local area fi rewalls, aggregated enterprise-wide fi rewalls, and carrier- hosted network-based fi rewalls (see Figure 3.7 ).

The biggest issue for SCADA separation security is that most of the associated electromechanical systems were designed and evolved in an environment largely separate from conventional computing and networking. Few computing texts explain the sub- tle details in SCADA system architecture; in fact, computer scien- tists can easily complete an advanced program of study without the slightest exposure to SCADA issues. Thus, in far too many

2 R. Krutz, Securing SCADA Systems , John Wiley & Sons, New York, 2006.

Remote access from MTUs to RTUs opens the door for adversaries to take advantage of this separation.

Chapter 3 SEPARATION 63

SCADA environments, the computerized connections between tangible systems and their control networks have occurred in an ad hoc manner, often as a result of establishing local convenience such as remote access. For this reason, the likelihood is generally low that state-of-the-art protection mechanisms are in place to protect a given SCADA system from cyber attack.

An additional problem that emerges for SCADA fi rewall usage is that commercial fi rewalls do not generally support SCADA protocols. When this occurs, the fi rewall operator must exam- ine which types of ports are required for usage of the protocol, and these would have to be opened. Security experts have long known that one of the great vulnerabilities in a network is the inadvertent opening of ports that can be attacked. Obviously, national infrastructure protection initiatives must be considered that would encourage and enable new types of fi rewall function- ality such as special proxies that could be embedded in SCADA architecture to improve immediate functionality.

Physical Separation One separation technique that is seemingly obvious, but amaz- ingly underrepresented in the computer security literature, is the physical isolation of one network from another. On the sur- face, one would expect that nothing could be simpler for sepa- rating one network from any untrusted environment than just unplugging all external connections. The process is known as

Internet

SCADA

Service

Provider

Fabric

SCADA

Enterprise

Firewall

SCADA

Enterprise

LAN

Network-Based SCADA

Firewall (Provider-Managed)

Wireless

Connection

(3G/4G)

Wired

Connection

Adversary

To Field

Data Element

RTU CMTUs To Field

Data Element

RTU B

To Field

Data Element

RTU B

Figure 3.7 Recommended SCADA system fi rewall architecture.

Protection mechanisms must be updated to effectively protect a SCADA system from cyber attack.

Opening ports, although necessary, is a risky endeavor, as it subjects the SCADA system to increased vulnerabilities.

64 Chapter 3 SEPARATION

air gapping , and it has the great advantage of not requiring any special equipment, software, or systems. It can be done to sepa- rate enterprise networks from the Internet or components of an enterprise network from each other.

The problem with physical separation as a security technique is that as complexity increases in some system or network to be isolated, so does the likelihood that some unknown or unautho- rized external connection will arise. For example, a small com- pany with a modest local area network can generally enjoy high confi dence that external connections to the Internet are well known and properly protected. As the company grows, however, and establishes branch offi ces with diverse equipment, people, and needs, the likelihood that some generally unrecognized external connectivity will arise is high. Physical separation of net- work thus becomes more diffi cult.

So how does one go about creating a truly air-gapped net- work? The answer lies in the following basic principles: ● Clear policy —If a network is to be physically isolated, then

clear policy must be established around what is and what is not considered an acceptable network connection. Organizations would thus need to establish policy checks as part of the net- work connection provision process.

● Boundary scanning —Isolated networks, by defi nition, must have some sort of identifi able boundary. Although this can cer- tainly be complicated by fi rewalls embedded in the isolated net- work, a program of boundary scanning will help to identify leaks.

● Violation consequences —If violations occur, clear conse- quences should be established. Government networks in the U.S. military and intelligence communities, such as SIPRNet and Intelink, are protected by laws governing how individuals must use these classifi ed networks. The consequences of vio- lation are not pleasant.

● Reasonable alternatives —Leaks generally occur in an isolated network because someone needs to establish some sort of communication with an external environment. If a network connection is not a reasonable means to achieve this goal, then the organization must provide or support a reasonable work-around alternative. Perhaps the biggest threat to physical network isolation

involves dual-homing a system to both an enterprise network and some external network such as the Internet. Such dual- homing can easily arise where an end user utilizes the same system to access both the isolated network and the Internet. As laptops have begun to include native 3G wireless access, this like- lihood of dual-homing increases. Regardless of the method, if any

Air gapping allows for physical separation of the network from untrusted environments.

As a company grows, physical separation as a protection feature becomes increasingly complex.

Chapter 3 SEPARATION 65

sort of connectivity is enabled simultaneously to both systems, then the end user creates an inadvertent bridge (see Figure 3.8 ).

It is worth mentioning that the bridge referenced above does not necessarily have to be established simultaneously. If a sys- tem connects to one network and is infected with some sort of malware, then this can be spread to another network upon sub- sequent connectivity. For this reason, laptops and other mobile computing devices need to include some sort of native protec- tion to minimize this problem. Unfortunately, the current state of the art for preventing malware downloads is poor.

A familiar technique for avoiding bridges between networks involves imposing strict policy on end-user devices that can be used to access an isolated system. This might involve preventing certain laptops, PCs, and mobile devices from being connected to the Internet; instead, they would exist solely for isolated net- work usage. This certainly reduces risk, but is an expensive and cumbersome alternative. The advice here is that for critical sys- tems, especially those involving safety and life-critical applica- tions, if such segregation is feasible then it is probably worth the additional expense. In any event, additional research in multi- mode systems that ensure avoidance of dual-homing between networks is imperative and recommended for national infra- structure protection.

Insider Separation The insider threat in national infrastructure protection is espe- cially tough to address because it is relatively easy for determined

Dual-homing creates another area of vulnerability for enterprise networks.

Isolated Environment

Isolated

Network Internet

End Users

Simultaneous

Dual-Homing

Leak

Figure 3.8 Bridging an isolated network via a dual-homing user.

Imposing strict policies regarding connection of laptops, PCs, and mobile devices to a network is both cumbersome and expensive but necessary.

66 Chapter 3 SEPARATION

adversaries to obtain trusted positions in groups with responsi- bility for national assets. This threat has become even more diffi - cult to counter as companies continue to partner, purchase, and outsource across political boundaries. Thus, the ease with which an adversary in one country can gain access to the internal, trusted infrastructure systems of another country is both growing and troubling.

Traditionally, governments have dealt with this challenge through strict requirements on background checking of any individuals who require access to sensitive government systems. This practice continues in many government procurement set- tings, especially ones involving military or intelligence infor- mation. The problem is that national infrastructure includes so much more than just sensitive government systems. It includes SCADA systems, telecommunications networks, transportation infrastructure, fi nancial networks, and the like. Rarely, if ever, are requirements embedded in these commercial environments to ensure some sort of insider controls against unauthorized data collection, inappropriate access to customer records, or admin- istrative access to critical applications. Instead, it is typical for employees to be granted access to the corporate Intranet, from which virtually anything can be obtained.

Techniques for reducing the risk of unauthorized insider access do exist that can be embedded in the design and operation of national infrastructure operation. These techniques include the following: ● Internal fi rewalls —Internal fi rewalls separating components

of national assets can reduce the risk of insider access. Insiders with access to component A, for example, would have to suc- cessfully negotiate through a fi rewall to gain access to com- ponent B. Almost every method for separating insiders from assets will include some sort of internal fi rewall. They can be implemented as fully confi gured fi rewalls, or as packet fi lter- ing routers; but regardless, the method of separating insiders from assets using fi rewalls must become a pervasive control in national infrastructure.

● Deceptive honey pots —As we discussed in Chapter 2, internal honey pots can help identify malicious insiders. If the decep- tion is openly advertised, then malicious insiders might be more uncertain in their sabotage activity; if the deception is stealth, however, then operators might observe malicious behavior and potentially identify the internal source.

● Enforcement of data markings —Many organizations with responsibility for national infrastructure do not properly mark their information. Every company and government agency

An adversarial threat may come from a trusted partner.

The commercially run components of our national infrastructure do not have the same stringent personnel requirements as the government-run components.

Chapter 3 SEPARATION 67

must identify, defi ne, and enforce clearly visible data markings on all information that could be mishandled. Without such markings, the likelihood of proprietary information being made available inadvertently to adversaries increases sub- stantially. Some companies have recently begun to use new data markings for personally identifi able information (PII).

● Data leakage protection (DLP) systems —Techniques for sniff- ing gateway traffi c for sensitive or inappropriate materials are becoming common. Tools called DLP systems are routinely deployed in companies and agencies. At best, they provide weak protection against insider threats, but they do help identify erro- neous leaks. Once deployed, they provide statistics on where and how insiders might be using corporate systems to spill informa- tion. In practice, however, no knowledgeable insider would ever be caught by a data leakage tool. Instead, the leak would be done using non-company-provided computers and networks. One of the more effective controls against insider threats

involves a procedural practice that can be embedded into virtu- ally every operation of an organization. The technique is known as segregation of duties , and it should be familiar to anyone who has dealt with Sarbanes-Oxley requirements in the United States. Security researchers will recognize the related separation of duties notion introduced in the Clark-Wilson integrity model. In both cases, critical work functions are decomposed so that work com- pletion requires multiple individuals to be involved. For example, if a fi nancial task requires two different types of activities for com- pletion, then a segregation of duties requirement would ensure that no one individual could ever perform both operations.

The purpose of this should be obvious. By ensuring that mul- tiple individuals are involved in some sensitive or critical task, the possibility of a single insider committing sabotage is greatly reduced. Of course, multiple individuals could still collude to cre- ate an internal attack, but this is more diffi cult and less likely in most cases. If desired, the risk of multiple individuals creating sabotage can be reduced by more complex segregation of duty policies, perhaps supported by the use of security architectural controls, probably based on internally positioned fi rewalls. In fact, for network-based segregation tasks, the use of internal fi re- walls is the most straightforward implementation.

In general, the concept of segregation of duties can be rep- resented via a work function ABC that is performed either by a single operator A or as a series of work segments by multiple operators. This general schema supports most instances of segre- gation of duties, regardless of the motivation or implementation details (see Figure 3.9 ).

Segregation of duties offers another layer of protection.

Internal fi rewalls create a straightforward de facto separation of duties.

68 Chapter 3 SEPARATION

The idea of breaking down work functions into components is certainly not new. Managers have decomposed functions into smaller tasks for many years; this is how assembly lines origi- nated. Unfortunately, most efforts at work function decomposi- tion result in increased bureaucracy and decreased worker (and end-user) satisfaction. The stereotyped image arises of the gov- ernment bureau where customers must stand in line at this desk for this function and then stand in line at that desk for that func- tion, and so on. The process is clearly infuriating but, ironically, is also diffi cult to sabotage by a malicious insider.

The challenge for national infrastructure protection is to inte- grate segregation of duty policies into all aspects of critical asset management and operation, but to do so in a manner that mini- mizes the increased bureaucracy. This will be especially diffi - cult in government organizations where the local culture always tends to nurture and embrace new bureaucratic processes.

Asset Separation Asset separation involves the distribution, replication, decompo- sition, or segregation of national assets to reduce the risk of an isolated compromise. Each of these separation techniques can be described as follows: ● Distribution involves creating functionality using multiple

cooperating components that work together as a distributed system. The security advantage is that if the distributed system is designed properly then one or more of the components can be compromised without breaking the overall system function.

● Replication involves copying assets across disparate compo- nents so that if one asset is broken then replicated versions

Original Work

Function with One

Operator

Operator A

Work Function ABC

Decomposed

Function with

Segregation of

Duties

Operator BOperator A Operator C

Work Function A Work Function B Work Function C

Figure 3.9 Decomposing work functions for segregation of duty.

How to effectively separate duties without increasing the unwieldy bureaucracy is a challenge that must be addressed.

Chapter 3 SEPARATION 69

will continue to be available. Database systems have been pro- tected in this way for many years. Obviously, no national asset should exist without a degree of replication to reduce risk.

● Decomposition is the breaking down of complex assets into individual components so that isolated compromise of a com- ponent will be less likely to break the overall asset. A common implementation of a complex business process, for example, generally includes some degree of decomposition into smaller parts.

● Segregation is the logical separation of assets through spe- cial access controls, data markings, and policy enforcement. Operating systems, unfortunately, provide weak controls in this regard, largely because of the massive deployment of single- user machines over the past couple of decades. Organizations thus implement logical separation of data by trying to keep it on different PCs and laptops. This is a weak implementation. Each of these techniques is common in modern infrastruc-

ture management. For example, content distribution networks (CDNs) are rarely cited as having a positive impact on national infrastructure security, but the reality is that the distribution and replication inherent in CDNs for hosting are powerful techniques for reducing risk. DDOS attacks, for example, are more diffi cult to complete against CDN-hosted content than for content resident only on an origination host. Attackers have a more diffi cult time targeting a single point of failure in a CDN (see Figure 3.10 ).

It is important to emphasize that the use of a CDN certainly does not ensure protection against a DDOS attack, but the rep- lication and distribution inherent in a CDN will make the attack more diffi cult. By having the domain name system (DNS) point

Segregation is one method of separation.

CarriersBots DDOS Attack Aimed

at Origination Host

Target A’s

Designated

Carrier CDN

Replicated

Hosts

Same Possibly

Unaffected by

DDOS Attack

Origination Host

Network

CDN

CDN

Figure 3.10 Reducing DDOS risk through CDN-hosted content.

70 Chapter 3 SEPARATION

to CDN-distributed assets, the content naturally becomes more robust. National infrastructure designers and operators are thus obliged to ensure that CDN hosting is at least considered for all critically important content, especially multimedia content (streaming and progressive download) and any type of critical software download.

This is becoming more important as multimedia provi- sion becomes more commonly embedded into national assets. In the recent past, the idea of providing video over the Internet was nothing more than a trivial curiosity. Obviously, the mas- sive proliferation of video content on sites such as YouTube.com has made these services more mainstream. National assets that rely on video should thus utilize CDN services to increase their robustness. Additional DDOS protection of content from the backbone service provider would also be recommended.

Multilevel Security (MLS) A technique for logical separation of assets that was popular in the computer security community during the 1980s and 1990s is known as multilevel security (MLS). MLS operating systems and applications were marketed aggressively to the security commu- nity during that time period. A typical implementation involved embedding mandatory access controls and audit trail hooks into the underlying operating system kernel. Assurance methods would then be used to ensure that the trusted component of the kernel was correct, or at least as correct as could be reasonably verifi ed. Today, for reasons largely economic, MLS systems are no longer available, except in the most esoteric classifi ed govern- ment applications.

The idea behind MLS was that, by labeling the fi les and direc- tories of a computer system with meaningful classifi cations and by also labeling the users of that system with meaningful clear- ances, a familiar security policy could be enforced. This scheme, which was motivated largely by paper methods used to protect information in government, produced a logical separation of cer- tain assets from certain users, based on the existing policy. For example, fi les marked “secret” could only be read by users with suffi cient clearances. Similarly, users not cleared to the level of “top secret” would not be allowed to read fi les that were so labeled. The result was an enforced policy on requesting users and protected assets (see Figure 3.11 ).

Several models of computer system behavior with such MLS functionality were developed in the early years of computer

The increase in multimedia components within national infrastructure networks argues for increased reliance on CDN services.

The familiar notion of “top- secret clearance” comes from MLS systems.

Chapter 3 SEPARATION 71

security. The Bell-La Padula disclosure and Biba integrity models are prominent examples. Each of these models stipulated policy rules that, if followed, would help to ensure certain desirable security properties. Certainly, there were problems, especially as networking was added to isolated secure systems, but, unfortu- nately, most research and development in MLS dissolved myste- riously in the mid-1990s, perhaps as a result of the economic pull of the World Wide Web. This is unfortunate, because the function- ality inherent in such MLS separation models would be valuable in today’s national infrastructure landscape. A renewed interest in MLS systems is thus strongly encouraged to improve protec- tion of any nation’s assets.

Requesting

Users

Top Secret

Cleared

Secret

Cleared

MLS Policy

Enforcement

Read (allowed)

Read (blocked)

Read (allowed)

Protected

Assets

Top Secret

Classified

Secret

Classified

MLS Produces Logical

Separation of Assets

TS

TS

TS S

S

S

TS

TS

S

S

Figure 3.11 Using MLS logical separation to protect assets.

Implementing a National Separation Program Implementation of a national separation program would involve verifi cation and validation of certain design goals in government agencies and companies with responsibility for national infrastructure. These goals, related to policy enforcement between requesting users and the protected national assets, would include the following: ● Internet separation —Certain critical national assets simply should not be accessible from the Internet. One would

imagine that the control systems for a nuclear power plant, for example, would be good candidates for separation from the Internet. Formal national programs validating such separation would be a good idea. If this requires changes in business practice, then assistance and guidance would be required to transition from open, Internet connectivity to something more private.

● Network-based fi rewalls —National infrastructure systems should be encouraged to utilize network-based fi rewalls, preferably ones managed by a centralized group. The likelihood is higher in such settings that signatures will be

MLS systems seem to have gone by the wayside but should be revived as another weapon in the national infrastructure protection arsenal.

72 Chapter 3 SEPARATION

Obviously, once a national program is in place, consideration of how one might separate assets between different cooperat- ing nations would seem a logical extension. Certainly, this would seem a more distant goal given the complexity and diffi culty of creating validated policy enforcement in one nation.

kept up to date and that security systems will be operated properly on a 24/7 basis. Procurement programs in government, in particular, must begin to routinely include the use of network-based security in any contract with an Internet service provider.

● DDOS protection —All networks associated with national assets should have a form of DDOS protection arranged before an attack occurs. This protection should be provided on a high-capacity backbone that will raise the bar for attackers contemplating a capacity-based cyber attack. If some organization, such as a government agency, does not have a suitable DDOS protection scheme, this should be likened to having no disaster recovery program.

● Internal separation —Critical national infrastructure settings must have some sort of incentive to implement an internal separation policy to prevent sabotage. The Sarbanes-Oxley requirements in the United States attempted to enforce such separation for fi nancial systems. While the debate continues about whether this was a successful initiative, some sort of program for national infrastructure seems worth considering. Validation would be required that internal fi rewalls exist to create protection domains around critical assets.

● Tailoring requirements —Incentives must be put in place for vendors to consider building tailored systems such as fi rewalls for specialized SCADA environments. This would greatly reduce the need for security administrators in such settings to confi gure their networks in an open position.

73 Cyber Attacks. DOI: © Elsevier Inc. All rights reserved.

10.1016/B978-0-12-384917-5.00004-4 2011

DIVERSITY

We are looking at computers the way a physician would look at genetically related patients, each susceptible to the same disorder .

Mike Reiter, professor of electrical and computer engineering and computer science at Carnegie-Mellon University 1

Making national infrastructure more diverse in order to create greater resilience against cyber attack seems to be a pretty sen- sible approach. For example, natural scientists have known for years that a diverse ecosystem is always more resilient to disease than a monoculture. When a forest includes only one tree, the possibility arises that a single disease could wipe out the entire ecosystem. This type of situation arises even in business. Certain airlines, for example, have decided to use only one model of air- craft. This reduces the cost of maintenance and training but does create a serious risk if that particular aircraft were grounded for some reason. The airline would be out of business—a risk that is avoided by a diversity approach.

So it would stand to reason that the process of securing any set of national assets should always include some sort of diver- sity strategy. This diversity should extend to all applications, soft- ware, computers, networks, and systems. Unfortunately, with the exception of familiar geographic requirements on network routes and data centers, diversity is not generally included in infra- structure protection. In fact, the topic of deliberately introduc- ing diversity into national infrastructure to increase its security has not been well explored by computer scientists. Only recently have some researchers begun to investigate the benefi ts of diver- sity in software deployment.

Diversity in national infrastructure involves the introduc- tion of intentional differences into systems. Relevant differences include the vendor source, deployment approach, network con- nectivity, targeted standards, programming language, operating

4

1 Quoted in “Taking Cues from Mother Nature to Foil Cyber Attacks” (press release), Offi ce of Legislative and Public Affairs, National Science Foundation, Washington, D.C., 2003 ( http://www.nsf.gov/od/lpa/news/03/pr03130.htm ).

Introducing diversity at all levels of functionality has not been properly explored as a protection strategy.

74 Chapter 4 DIVERSITY

system, application base, software version, and so on. Two sys- tems are considered diverse if their key attributes differ, and non- diverse otherwise (see Figure 4.1 ).

The general idea is that an adversary will make assumptions about each of the relevant attributes in a target system. In the absence of diversity, a worst-case scenario results if the adversary makes the right assumptions about each attribute. If, for exam- ple, the adversary creates an attack on a set of computers that assumes an underlying Microsoft ® operating system environ- ment, and the national asset at risk employs only these types of systems, then the effect could be signifi cant. In the presence of diversity, however, it becomes much more diffi cult for an adver- sary to create an attack with maximal reach. This is especially rel- evant for attacks that are designed to automatically propagate. Eventually, the attack will reach a point where it can no longer copy itself or remotely execute, and the process will cease.

Why, then, is diversity so underrepresented in national infra- structure protection? To understand this, one must fi rst recognize the near-obsessive goal of enforcing sets of common standards that the information technology and security communities have attempted to achieve. In nearly every facet of computing, sets of standard, auditable practices have been defi ned and backed by powerful organizations. In the United States, the Sarbanes- Oxley standard has had a profound infl uence on the operation of every major corporation in the country, leading to more common approaches to fi nancial systems operation. Commonality, as we discuss in the next chapter, is somewhat at odds with diversity.

This focus on maintaining common, standard operating envi- ronments should not come as a surprise. The rise of the Internet, for example, was driven largely by the common acceptance of a single protocol suite. Even the provision of Internet-based ser- vices such as websites and mail servers requires agreement among system administrators to follow common port assign- ments. Chaos would ensue if every administrator decided to

System

A

B

C

Company X

Company Y

Company Z

Off-the-shelf

Custom

Custom

IP

TDM

TDM

IP sec

None

None

C++

Java

Java

Windows

Unix

Unix

Vendor

Source

Deployment

Approach

Network

Connectivity

Targeted

Standards

Programming

Language

Operating

System Attributes

A and B:

Diverse

B and C:

Non diverse

Figure 4.1 Diverse and nondiverse components through attribute differences.

Diversity increases the number of assumptions an adversary has to make about the system and creates more potential for an adversary’s plan to fail.

Standardized operations are important for compliance but are at odds with diversity.

Chapter 4 DIVERSITY 75

assign random ports to their Internet services; end users would not be able to easily locate what they need, and the Internet would be a mess (although this would certainly complicate broad types of attacks). So, the result is general agreement on common computing confi gurations.

Another key motivation to avoid diversity for most system managers is the costs involved. Typical computing and net- working management teams have created programs focused on removing differences in enterprise systems in order to reduce operating expenses. Clearly, nondiverse information technology systems simplify platform deployment, end-user training, system administrative practices, and system documentation. For these cost-related reasons, diversity is generally not a prominent goal in most current national infrastructure settings. The result is less secure infrastructure.

Diversity and Worm Propagation The self-propagation of a computer worm is a good example of an attack that relies on a nondiverse target environment to function properly. The box shows how relatively simple an attack can be.

Diversity currently competes with commonality and cost savings.

Worm Functionality in Three Easy Steps The functionality of a typical, generic computer worm is quite straightforward (only three steps) and can be described in simple pseudo-code terms as follows:

Program: Worm Start

Step 1. Find a target system on the network for propagation of Program Worm . Step 2. Copy Program Worm to that target system. Step 3. Remotely execute Program Worm on that target system.

Repeat Steps 1 through 3.

As you can see, a worm program relies on the ability to fi nd common, reachable, interoperable systems on the network that will accept and execute a copy of the worm program. In the early days of the Internet, this would be accomplished by checking a local fi le that would include a list of systems that were reach- able. Today, it’s done by creating batches of Internet Protocol

76 Chapter 4 DIVERSITY

addresses. Also, in those early days, it was quite easy to copy and execute programs from one system to another, because no one had yet invented the fi rewall.

One would have hoped that the global deployment of fi re- walls would have stopped the ability of adversaries to create worms, but sadly it has not. Instead, vulnerabilities or services open through the fi rewalls are used as the basis for worms. Nondiversity in such setups is also the norm. This is unfortunate, because if a worm operates in a diverse environment, and thus cannot fi nd systems that consistently meet one or more of these criteria, then its propagation will cease more rapidly. This can be depicted in a simple reachability diagram showing the point of initiation for the worm through its propagation to the fi nal point at which the activity ceases as a result of diversity. As the worm tries to propagate, diversity attributes that reduce its ability to locate reachable systems, make copies, and remotely execute are the most effective (see Figure 4.2 ).

Obviously, all worms will eventually cease to propagate, regardless of the degree of diversity in a given network. The secu- rity advantage one gains with diversity is that the worm is likely to cease more quickly and perhaps without human intervention. Empirical experience in the global security community deal- ing with worms such as the SQL/Slammer and Blaster worms of 2003 and the Sasser worm of 2004 suggest that signifi cant human intervention is required to halt malicious operation. During the early hours of the SQL/Slammer worm, most of the security inci- dent response calls involved people trying to fi gure out what to

Unreachable

Worm

Initiated

Worm

Ceased

Unable to Accept

Copy of Worm

Unable to

Remotely

Execute

Unreachable

Unable to Accept

Copy of Worm

Unable to

Remotely

Execute

Figure 4.2 Mitigating worm activity through diversity.

A worm propagates by fi nding interoperable systems to target.

Chapter 4 DIVERSITY 77

do. Eventually, the most effective solution involved putting local area network blocks in place to shut down the offending traf- fi c. By the time the event died down, many millions of hours of global labor had been expended working on the problem. By increasing diversity, one should expect to reduce response costs around the world associated with fi ghting worms.

The real challenge here is that both the Internet and the networks and systems being run by companies and agencies charged with national infrastructure are simply not diverse— and there is little discussion in place to alter this situation. As we suggested earlier, this is driven largely by the goal to maximize interoperability. There are some exceptions in the broader com- puting community, such as digital rights management (DRM)- based systems that have tended to limit the execution of certain content applications to very specifi c devices such as the iPod ® and iPhone ® . The general trend, however, is toward more open, interoperable computing. What this means is that, for national infrastructure components that must be resilient against auto- mated attacks such as worms, the threat will remain as long as the networking environment is a monoculture.

Desktop Computer System Diversity Typical individual computer users in the home or offi ce, regard- less of their location in the world, are most likely to be using a commercial operating system running on a standard processor platform and utilizing one of a couple of popular browsers to perform searches on a popular search engine. This might seem an obvious statement, but in the early days of computing there were many users on home-grown or proprietary systems using all sorts of software that might only be known locally.

Today, however, the most likely confi guration would be a Windows ® -based operating system on an Intel ® platform with Internet Explorer ® being used for Google ® searches. We can say this confi dently, because almost all current estimates of market share list these products as dominant in their respective fi elds. Certainly, competing platforms and services from Apple ® and others have made inroads, but for the most part, especially in business and government environments, the desktop confi gura- tion is highly predictable (see Figure 4.3 ).

This dominant position for these few companies has admit- tedly led to a number of positive results. It has, for instance, pushed a deeper common understanding of computing among individuals around the world. Different people from different

Although introducing security can seem expensive, one should expect to save money on response costs with an effective diverse environment.

The average home PC user is working in a highly predictable computing environment.

78 Chapter 4 DIVERSITY

cultures around the world can share their experiences, recom- mendations, and suggestions about operating systems, search engines, CPUs, and browsers, and the likelihood of applicability is high. The dominant position of these respective products has also helped the software development industry by creating rich and attractive common target markets. Developers generally love to see a dominant platform confi guration, because it increases their potential profi ts through maximal usage. So, computing certainly has moved forward as a result of commonality; not much disagreement exists on this point.

The drawback from a national infrastructure perspective, how- ever, is that adversaries will have an easier time creating attacks with signifi cant reach and implication. Just as a game of dominoes works best when each domino is uniformly designed and positioned, so does common infrastructure become easier to topple with a single, uniform push. In some cases, the effect is signifi cant; the operat- ing system market on desktop PCs, for example, is dominated by Microsoft ® to the point where a well-designed Windows ® -based attack could be applicable to 90% of its desktop targets.

More likely, however, is the situation where the creation of a botnet becomes much easier given the nondiversity of PC con- fi gurations. When a botnet operator conceptualizes the design of a new botnet, the most important design consideration involves reach. That is, the botnet operator will seek to create malware that has the maximal likelihood of successfully infecting the larg- est number of target PCs. As such, the nondiversity of end-user confi gurations plays right into the hands of the botnet operator. Combine this with the typically poor system administrative prac- tices on most PCs, and the result is lethal. Worse, many security managers in business and government do not understand this risk. When trying to characterize the risk of attack, they rarely understand that the problem stems from a global set of nondiverse end-user PCs being mismanaged by home and offi ce workers.

Most Likely Configuration for

Home or Office PC User

Windows – 90%

Google – 81%

Intel – 79%

Internet Explorer – 67%

Operating System

Search Engine

CPU

Browser

Two-Thirds of All PCs

Nine-Tenths of All PCs

Figure 4.3 Typical PC confi guration showing nondiversity.

Targeting the most popular operating system software with a worm attack could bring the majority of PCs to a standstill.

Security managers are unlikely to consider the home PC user when assessing risk.

Chapter 4 DIVERSITY 79

In response to this threat, national infrastructure protection requires a deliberate and coordinated introduction of diver- sity into the global desktop computing environment. Enterprise attention is obviously different than that of individuals in homes, but the same principle applies. If the desktop computing assets that can reach a national asset must be maximally resilient, then desktop diversity is worth considering. The most obvious chal- lenge here is related to the consumer marketplace for PCs; that is, the reason why consumers use the same platform is because they prefer it and have chosen to purchase it. If Microsoft ® and Intel ® , for example, were not providing value in their products, then people would buy something else. The biggest hurdle, there- fore, involves enabling nondiversity without altering the ability of companies to provide products that people like to use. Perhaps this goal could be accomplished via diversity elements coming from within the existing vendor base.

Desktop Diversity Considerations Additional issues that arise immediately with respect to desktop diversity programs include the following: ● Platform costs —By introducing multiple, diverse platforms into a computing environment, the associated hardware

and software costs might increase. This is a common justifi cation by information technology (IT) managers for avoiding diversity initiatives. Certainly, the procurement of larger volumes of a given product will reduce the unit cost, but by introducing competition into the PC procurement arena increased costs might be somewhat mitigated.

● Application interoperability —Multiple, diverse platforms will complicate organizational goals to ensure common interoperability of key applications across all platforms. This can be managed by trying to match the desktop platform to local needs, but the process is not trivial. The good news is that most web-based applications behave similarly on diverse platforms.

● Support and training —Multiple, diverse platforms will complicate support and training processes by adding a new set of vendor concerns. In practical terms, this often means introducing a platform such as Mac OS ® to a more traditional Windows ® -based environment. Because many consumers are comfortable with both platforms, especially youngsters who tend to be more diverse in their selections, the problem is not as intense as it might be.

For national infrastructure protection, desktop diversity ini- tiatives that are focused on ensuring enterprise differences in companies and agencies have a good chance of success. Rewards and incentives can be put in place to mix up the desktop plat- forms in a given enterprise. The problem is that this will have only limited usefulness from the perspective of botnet design and recruitment. The real advantage would come from diversity in

80 Chapter 4 DIVERSITY

broadband-connected PCs run by consumers around the world. Unfortunately, this is not something that can be easily controlled via an initiative in any country, including the United States.

Interestingly, a related problem that emerges is the seem- ingly widespread software piracy one fi nds in certain areas of the globe. Software piracy on the desktop introduces the problem of security updates; that is, depending on the specifi cs of the theft, it is often diffi cult for pirated PCs to be properly protected with required patches. When many millions of PCs are in this state, the problem of nondiversity becomes all the more severe.

Diversity Paradox of Cloud Computing To better understand how diversity goals can be accomplished, it helps to introduce a simple model of desktop computing sys- tems. The model is represented as a linear spectrum of options related to the degree to which systems are either diverse or non- diverse. As such, the two ends of the model spectrum are easy to identify for a given environment. On one side of the spectrum would be the option of complete nondiversity, where every desk- top system in the organization, enterprise, or group is exactly the same. On the other side of the spectrum would be the option of complete diversity across the organization, where no two desk- top systems are the same. In the middle of the spectrum would be the usual types of settings, where some minor degree of diver- sity exists, but with a clearly dominant platform.

The model spectrum is useful because it allows illustration of our basic infrastructure security proposition around PCs— namely, as diversity increases, desktop attacks, including the use of worms to create a local denial of service condition, are more diffi cult to accomplish. One might also suggest that the creation and use of botnets would also be more diffi cult, but this benefi t might be more modest (see Figure 4.4 ).

Desktop Attack Difficulty (increases)

Typical Enterprise

(Mostly Same, Some Different)

Desktops

Different

Desktops

Same

Figure 4.4 Spectrum of desktop diversity options.

Global diversity in broadband-connected home PCs would stymie many botnet attacks.

Chapter 4 DIVERSITY 81

In fact, diverse desktops are tougher to uniformly compro- mise, because they are less conducive as a group to a scalable, self-propagating attack. For example, if a company has half of its PCs running Windows ® -based operating systems and half run- ning Mac OS ® -based operating systems, then this will clearly be more challenging for an automatically propagating attack. Hence, the level of diversity and the associated diffi culty of attack appear to correlate. A challenge with this view, however, is that it does not properly characterize the optimal choice in reducing desktop attack risk—namely, the removal of desktops from the target environment. After all, one cannot attack systems that are not even there. This suggests a new (and admittedly theoretical) diversity and attack diffi culty spectrum (see Figure 4.5 ).

This suggests that the ultimate (albeit impossible) option for making desktops more secure involves their removal. Obviously, this is not a practical goal, but computer security objectives are often made more tractable via clear statements of the ideal con- dition. So, while current enterprise or home computing architec- tures do not include the option of having no desktop computers, older readers will remember the days when desktops did not exist. Rather, people used computer terminals to access informa- tion on mainframes, and security benefi ts were certainly pres- ent in such a setup. This included no need for end-user software patching, as well as no end-user platform for targeted malware. One great irony in the present deployment of desktops to every man, woman, and child on the planet is that most people really do not need such computing power. It is likely that they would be just fi ne with a keyboard, screen, and mouse connected to network-resident applications that are ubiquitously available via the Internet.

In modern computing, the closest thing we have to this arrangement is virtualized, cloud-based computing. In such a setup, computing power and application intelligence move to a centralized complex of servers, accessible via light clients. In

Desktop Attack Difficulty

Desktops

Removed

Desktops

Different

Desktops

Same

Figure 4.5 Diversity and attack diffi culty with option of removal.

As the level of diversity increases, the level of diffi culty for an attack likewise increases.

The global proliferation of home PCs has increased the risk of malware attacks.

82 Chapter 4 DIVERSITY

fact, handheld mobile devices provide the equivalent of a desk- top computer in such a cloud environment. One should therefore presume, from the diagram in Figure 4.5 , that cloud computing would provide considerable security benefi ts by removing non- diverse desktops from the environment. This is most likely true, as long as the infrastructure supporting the cloud applications is properly secured, as per the various principles described in this book. If this is not the case, then one is simply moving nondiver- sity vulnerabilities from the desktops to the servers.

Network Technology Diversity Modern telecommunications network systems can be viewed as consisting of the following two basic types of technologies: ● Circuit-switched —This includes legacy, circuit-switched

systems that support traditional plain old telephone ser- vices (POTS) and related voice and data services. The public switched telephone network (PSTN) is the most signifi cant example of deployed circuit-switched technology.

● Packet-switched —This includes more modern, packet-switched systems that support Internet Protocol (IP) and related voice, data, and multimedia services. In addition to the Internet as the most obvious example of packet switching, the signal- ing network controlling the PSTN is itself a packet-switched system. For the most part, both logical and physical diversity naturally

exist between these two types of services, largely due to technol- ogy interoperability. That is, the vast majority of equipment, soft- ware, processes, and related infrastructure for these services are fundamentally different. Packets cannot accidentally or inten- tionally spill into circuits, and vice versa .

From a networking perspective, what this means is that a security event that occurs in one of these technologies will gen- erally not have any effect on the other. For example, if a network worm is unleashed across the Internet, as the global community experienced so severely in the 2003–2004 time frame, then the likelihood that this would affect traditional time-division multi- plexed (TDM) voice and data services is negligible. Such diversity is of signifi cant use in protecting national infrastructure, because it becomes so much more diffi cult for a given attack such as a worm to scale across logically separate technologies (see Figure 4.6 ).

Even with the logical diversity inherent in these different tech- nologies, one must be careful in drawing conclusions. A more

Cloud computing may offer home PC users the diverse, protected environment they cannot otherwise access.

Circuit-switched and packet-switched systems automatically provide diversity when compared to one another.

Chapter 4 DIVERSITY 83

accurate view of diverse telecommunications, for example, might expose the fact that, at lower levels, shared transport infrastruc- ture might be present. For example, many telecommunications companies use the same fi ber for their circuit-switched delivery as they do for IP-based services. Furthermore, different carriers often use the same right-of-way for their respective fi ber delivery. What this means is that in many locations such as bridges, tun- nels, and major highways, a physical disaster or targeted terror- ist attack could affect networks that were designed to be carrier diverse.

While sharing of fi ber and right-of-way routes makes sense from an operational implementation and cost perspective, one must be cognizant of the shared infrastructure, because it does change the diversity profi le. As suggested, it complicates any reli- ance on a multivendor strategy for diversity, but it also makes it theoretically possible for an IP-based attack, such as one pro- ducing a distributed denial of service (DDOS) effect, that would have negative implications on non-IP-based transport due to volume. This has not happened in practical settings to date, but because so much fi ber is shared it is certainly a possibility that must be considered (see Figure 4.7 ).

A more likely scenario is that a given national service tech- nology, such as modern 2G and 3G wireless services for citizens

End Users

(Phones,

Circuits)

Worm

Circulating

Network

Management

Electronic Switching

Switch

Signaling

IP Routing

Non-

Propagation

(Logical

Diversity)

Traditional

Circuit-Switched

Modern

Packet-Switched

End Users

(Computers,

Intranets)

Figure 4.6 Worm nonpropagation benefi t from diverse telecommunications.

Unfortunately, vulnerabilities will always be present in IP-based and circuit-switched systems.

84 Chapter 4 DIVERSITY

and business, could see security problems stemming from either circuit- or packet-switched-based attacks. Because a typical car- rier wireless infrastructure, for example, will include both a cir- cuit- and packet-switched core, attacks in either area could cause problems. Internet browsing and multimedia messaging could be hit by attacks at the serving and gateway systems for these types of services; similarly, voice services could be hit by attacks on the mobile switching centers supporting this functionality. So, while it might be a goal to ensure some degree of diversity in these technology dependencies, in practice this may not be possible.

What this means from a national infrastructure protection perspective is that maximizing diversity will help to throttle large-scale attacks, but one must be certain to look closely at the entire architecture. In many cases, deeper inspection will reveal that infrastructure advertised as diverse might actually have components that are not. This does not imply that suffi - cient mitigations are always missing in nondiverse infrastruc- ture, but rather that designers must take the time to check. When done properly, however, network technology diversity remains an excellent means for reducing risk. Many a security offi cer will report, for example, the comfort of knowing that circuit-switched voice services will generally survive worms, botnets, and viruses on the Internet.

End Users

(Phones,

Circuits)

Worm

Circulating

Network

Management

Electronic Switching

Switch

Signaling

IP

Routing

Possible Impact

(Physical Non-

Diversity)

End Users

(Computers,

Intranets)

Fiber

Figure 4.7 Potential for impact propagation over shared fi ber.

Diversity may not always be a feasible goal.

Chapter 4 DIVERSITY 85

Physical Diversity The requirement for physical diversity in the design of comput- ing infrastructure is perhaps the most familiar of all diversity- related issues. The idea is that any computing or networking asset that serves as an essential component of some critical func- tion must include physical distribution to increase its survivabil- ity. The approach originated in the disaster recovery community with primary emphasis on natural disasters such as hurricanes and fi res, but, as the security threat has matured, infrastructure managers have come to recognize the value of providing some degree of physical diversity. This reduces, for example, reliance on a single local power grid, which is a valued cyber attack target for adversaries. It also greatly reduces the chances of a physical or premise-based attack, simply because multiple facilities would be involved.

These issues are not controversial. In fact, for many years, procurement projects for national asset systems, in both govern- ment and industry, have routinely included the demand that the following physical diversity issues be considered: ● Backup center diversity— If any major center for system, net-

work, or application management is included in a given infrastructure component, then it is routinely required that a backup center be identifi ed in a physically diverse loca- tion. Few would argue with this approach; if properly applied, it would ensure that the two centers are in different weather patterns and power grid segments.

● Supplier/vendor diversity— Many organizations dictate that for critical infrastructure components, some degree of diversity must be present in the supplier and vendor mix. This reduces the likelihood that any given fi rm would have too much infl u- ence on the integrity of the infrastructure. It also reduces the likelihood of a cascading problem that might link back to some common element, such as a software routine or library, embedded in one vendor’s product portfolio.

● Network route diversity —When network infrastructure is put in place to support national infrastructure, it is not uncom- mon to demand a degree of network route diversity from the provider or providers. This helps reduce the likelihood of malicious (or nonmalicious) problems affecting connectiv- ity. As mentioned above, this is complicated by common use of bridges, tunnels, or highways for physical network media deployments from several different vendors.

Physical diversity adds another important layer of protection against cascading effects.

Physical diversity has been incorporated into the national asset system for many years.

86 Chapter 4 DIVERSITY

Achieving Physical Diversity via Satellite Data Services

A good example application that demonstrates physical diversity principles is the provision of certain types of SCADA systems using IP over satellite (IPoS). Satellite data services have traditionally had the great advantage of being able to operate robustly via the airwaves in regions around the globe where terrestrial network construction would be diffi cult. Generally, in such regions commercial wireless coverage is less ubiquitous or even completely unavailable. Some SCADA applications have thus taken advantage of this robust communication feature in satellite systems to connect remote end-user terminals to the SCADA host system, but the requirement remains that some degree of diversity be utilized. As suggested above, most of this diversity emphasis has been driven largely by concerns over natural and physical disasters, but a clear cyber security benefi t exists as well.

Generally, the setup for satellite-connected SCADA involves end users connecting to a collection of physically diverse hubs via IPoS. These diverse hubs are then connected in a distributed manner to the SCADA hosts. An adversary seeking to attack these hubs would have to use either logical or electronic means, and a great degree of logistic effort would be required, especially if the hubs are located in different parts of the world. The Hughes Corporation, as an example, has been aggressive in marketing these types of confi gurations for SCADA customers. Their recommended remote access confi guration for diverse SCADA system control is shown in Figure 4.8 .

Space

Terrestrial

Remote terminal

SCADA Hosts

Geographically Diverse Hubs

Infrastructure Component

Access

Network

Access

Network

Access

Network

Figure 4.8 Diverse hubs in satellite SCADA confi gurations.

Chapter 4 DIVERSITY 87

National Diversity Program The development of a national diversity program would

require coordination between companies and government agen- cies in the following areas: ● Critical path analysis —An analysis of national infrastructure

components must be made to determine certain critical paths that are required for essential services. For example, if a mili- tary group relies on a specifi c critical path to complete some logistic mission, then assurance should exist that this criti- cal path is supported by diverse vendors, suppliers, support teams, and technology.

● Cascade modeling —A similar analysis is required to identify any conditions in a national infrastructure component where a cascading effect is possible due to nondiversity. If, for exam- ple, 100% of the PCs in an organization are running in exactly the same confi guration, then this poses a risk. Admittedly, the organization might choose to accept the risk, but this should be done explicitly after a security investigation, rather than by default.

● Procurement discipline —The selection and procurement of technology by organizations charged with critical infrastructure should include a degree of diversity requirements. This generally occurs naturally in most large organizations, so the urgency here might not be as intense but the security benefi ts are obvious. The decision of whether to provide rewards and incentives

for diversity versus a stricter approach of requiring evidence of some targeted percentage of diversity must be driven by the local environment and culture. The threat environment in a mili- tary setting is considerably different than one might fi nd in tele- communications or transportation, so it would seem prudent to make such implementation decisions locally.

The advantage of diverse hubs is obvious; if any should be directly compromised, fl ooded, or attacked (physically or logically), then the SCADA hosts are still accessible to end users. In addition, attacks on local infrastructure components on which the SCADA operation depends, such as power, will not have a cascading effect. Such an approach only works, however, if all diverse components operate at a common service level. For example, if one service provider offers highly reliable, secure services with historical compliance to advertised service level agreements (SLAs), then introducing a diverse provider with poor SLA compliance might not be such a good idea. This is a key notion, because it is not considered reasonable to take a highly functioning system and make it diverse by introducing an inferior counterpart. In any event, this general concept of diverse relay between users and critical hosts should be embedded into all national infrastructure systems.

This page intentionally left blank

89 Cyber Attacks. DOI: © Elsevier Inc. All rights reserved.

10.1016/B978-0-12-384917-5.00005-6 2011

COMMONALITY

The only truly secure system is one that is powered off, cast in a block of concrete, and sealed in a lead-lined room with armed guards—and even then I have my doubts .

Eugene Spafford, Executive Director of the Purdue University Center for Education and Research in Information Assurance and Security (CERIAS) 1

Now that we have outlined our proposal in the previous chap- ter for national infrastructure systems to include diversity, we can discuss the seemingly paradoxical requirement that infrastruc- ture systems must also demonstrate a degree of commonality . In particular, certain desirable security attributes must be present in all aspects and areas of national infrastructure to ensure maxi- mal resilience against cyber attack. Anyone who has worked in the security fi eld understands this statement and is likely to agree with its basis. The collection of desirable security attributes is usu- ally referred to collectively as security best practices . Example best practices include routine scanning of systems, regular penetration testing of networks, programs for security awareness, and integrity management checking on servers.

When security best practices are easily identifi ed and measur- able, they can become the basis for what is known as a security standard . A security standard then becomes the basis for a pro- cess known as a security audit , in which an unbiased third-party observer determines based on evidence whether the requirements in the standard are met. The key issue for national infrastructure protection is that best practices, standards, and audits establish a low-water mark for all relevant organizations (see Figure 5.1 ).

Organizations that are below a minimally acceptable security best practices level will fi nd that security standards audits intro- duce new practices, in addition to revisiting existing practices. The desired effect is that the pre-audit state will transition to an improved post-audit state for all practices. This does not always happen, especially for organizations that have a poor environment

5

1 Quoted in A. K. Dewdney, “Computer recreations: of worms, viruses and Core War,” Sci. Am. , 260(3), 90–93, 1989.

90 Chapter 5 COMMONALITY

for introducing new security practices, but it is the goal. For organi- zations that are already above the minimally acceptable level, per- haps even with world-class features, the audit will rarely introduce new practices but will instead revisit existing ones. The desired effect here is that these practices would be strengthened, but, again, this does not always work perfectly, especially if the auditors are less familiar with the world-class security features already in place. Some common security-related best practices standards that one will fi nd in national infrastructure settings are listed in the box.

Organization B

Organization A

Pre-Audit Post-Audit Pre-Audit Post-Audit

Audit

Audit

Security

Practices

World

Class

Minimally

Acceptable

Revisit

Existing

New Practices

Revisit Existing

Figure 5.1 Illustrative security audits for two organizations.

The purpose of a security audit is to raise the level of security features currently in place.

Common Security-Related Best Practices Standards ● Federal Information Security Management Act (FISMA) —FISMA sets minimal standards for security best practices in

federal environments. It is enforced by congressional legislation and involves an annual letter grade being assigned to individual agencies. The following departmental agencies received an “F” for their FISMA rating in 2007: Defense, Commerce, Labor, Transportation, Interior, Treasury, Veterans Affairs, and Agriculture (so did the Nuclear Regulatory Commission).

● Health Insurance Portability and Accountability Act (HIPAA) —Title II of HIPAA includes recommended standards for security and privacy controls in the handling of health-related information for American citizens. It is also enforced by congressional legislation.

● Payment Card Industry Data Security Standard (PCI DSS) —This security standard was developed by the PCI Security Council, which includes major credit card companies such as Visa ® Card, Discover ® Card, American Express ® , and MasterCard ® . It includes requirements for encrypting sensitive customer data.

Chapter 5 COMMONALITY 91

With such redundancy in security standards and compli- ance, one would guess that the principle of commonality would be largely met in national infrastructure protection. For example, some organizations might be required to demonstrate compli- ance to dozens of different security standards. One would expect that such intense and focused attention on security would lead to a largely common approach to security around the globe. Sadly, the belief here is that in spite of the considerable audit and com- pliance activity around the world, most of it does not address the type of security commonality that will make a positive differ- ence in national infrastructure protection. The activity instead tends to focus on requirements that have some value but do not address the most critical issues. In fact, most of these practices exist in the category of state-of-the-art security, far beyond the minimally acceptable levels addressed in most audits.

The audit problem stems from the inherent differences between meaningful and measurable security best practices. There’s an old dumb joke about a man looking for his lost money on 42nd and Eighth. When a passerby asks whether the money was actually lost at that spot, the man looks up and says that the money was actually lost over on 41st and Tenth but the light is much better here. Security audit of best practices is often like this; the only practices that can be audited are ones where the light is good and measurable metrics can be established. This does not, however, imply that such metrics are always meaning- ful (see Figure 5.2 ).

The example requirements shown in Figure 5.2 provide a hint as to the types of requirements that are likely to be included in each category. One can easily levy a measurable requirement on password length, for example, even though this is generally a less useful constraint. This could be viewed as an example that

● ISO/IEC 27000 Standard (ISO27K) —The International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) evolved a British Security Standard known as BS-7799 into an internationally recognized set of auditable security best practices. Some security experts believe that the ISO27K family of security standards is the most global and generally agreed upon set of best practices. All of these standards, and the many additional ones that are not mentioned above, include a large subset of security

and functional requirements that are virtually the same. For example, each standard requires carefully documented policies and procedures, authentication and authorization controls, data collection systems, and embedded encryption. Each standard also requires management oversight, ongoing security monitoring, compliance scores issued by designated auditors, and some form of fi nes or punishment if the standard best practices are not met.

92 Chapter 5 COMMONALITY

is measurable but not meaningful. Conversely, one can levy the important requirement that a strong culture of security be pres- ent in an environment. This is a meaningful condition but almost impossible to measure. The example requirement that a security policy be present is both meaningful and measurable. It demon- strates that there are certainly some requirements that reside in both categories.

Meaningful Best Practices for Infrastructure Protection A provocative implication here is that the ability to audit a given best practice does not determine or infl uence whether it is useful for infrastructure protection. In fact, the primary motivation for proper infrastructure protection should not be one’s audit score; rather, the motivation should be success based and economic. The fact is that companies, agencies, and groups with responsi- bility for infrastructure protection will eventually fail if they do not follow the best available recommendations for security best practices. Unfortunately, the best recommendations come not from the security standards and audit community but from prac- tical experience.

If you do not agree, then please consider that security stan- dards backed by powerful and authoritative groups have existed

Meaningful

Requirements

Focus of Protection

Documented Security Policy

Focus of Auditor

Measurable

Requirements

Culture of

Security

Protection

Constraint

on Password

Length

Figure 5.2 Relationship between meaningful and measurable requirements.

Ideally, security practices are both meaningful and measurable.

A great audit score does not necessarily guarantee successful infrastructure protection.

Chapter 5 COMMONALITY 93

for many decades. In addition, security auditors have been in business for decades, performing diligent analysis and issuing embarrassing failure grades to security teams around the world. Our earlier reference to FISMA, for example, included failing grades for many prominent government agencies in the United States. In spite of all this activity and reporting, however, nothing truly material has changed during these past decades in the way computer and network systems are secured. In fact, one could easily make the claim that national infrastructure is more vul- nerable to attack today than it was 20 years ago. What makes one think that more stringent security standards and audit processes are going to change this now?

Based on this author’s experiences managing the security of major critical infrastructure components for many years, the answer lies in a two-step methodology: ● Step 1. Standard audit —The fi rst step is conventional, in that

it recommends that every organization submit to a standard audit to ensure that no group is operating below the mini- mally acceptable threshold. While most organizations would claim to already have this step ongoing, the goal here is to be given a desirable rating or score, rather than a failing one. So, even if a company or agency has ongoing audits, the goal here is to pass these audits. Any one of the major audit standards mentioned above is probably acceptable; they all roughly direct the same sort of minimal practices.

● Step 2. World-class focus —The second step involves a more intense focus on a set of truly meaningful national infrastruc- ture protection practices. These practices are derived largely from experience. They are consistent with the material pre- sented in this book, and they will only be present in pieces in most existing security audit standards. The greatest success will typically come from organizations self-administering this new focus, especially because these practices are not easy to measure and audit (see Figure 5.3 ). For the fi rst step, an important issue involves ensuring that

the audit does not cause more harm than good. For example, suppose that a competent and trustworthy system administra- tor has been charged with a bevy of responsibilities for an infra- structure component and that she has demonstrated excellent results over a long period of time, with no security problems. This is a common situation, especially in companies and agencies that take system administration seriously. Unfortunately, a security auditor would look at such a setup with horror and would deem it a clear violation of least privilege, separation of duties, and so on.

A successful protection strategy should start with at least a passing score on a standard security audit.

Sometimes security audit standards and best practices proven through experience are in confl ict.

94 Chapter 5 COMMONALITY

In the United States, if the component being administered was a fi nancial one in a public company, then this would be a violation of the Sarbanes-Oxley segregation of duties require- ments. The auditor would typically require that the single com- petent administrator be replaced by a bureaucratic process involving a team of potentially inferior personnel who would each only see a portion of the total task. It is not diffi cult to imag- ine the component being more poorly managed and, hence, less secure. This is the worst case in any audit and must be explicitly avoided for national infrastructure protection.

For the second step, the box lists specifi c meaningful secu- rity best practices, six in total, for national infrastructure protec- tion. These six best practices do not contradict current auditing processes and standards, but they are certainly not designed for easy audit application; for example, it is diffi cult to validate whether something is “appropriate” or “simplifi ed.” Nevertheless, our strong advice is that attentiveness to ensuring commonality across national infrastructure with these six practices will yield signifi cant benefi ts.

Existing Set of Practices

Minimally Acceptable Set of Practices

World-Class Infrastructure Protection

Standard Audit (FISMA, ISO, Etc.)

Self-Administer (Six Best Practices)

Figure 5.3 Methodology to achieve world-class infrastructure protection practices.

Six Best Practices for National Infrastructure Protection

● Practice 1. Locally relevant and appropriate security policy —Every organization charged with the design or operation of national infrastructure must have a security policy that is locally relevant to the environment and appropriate to the organizational mission. This implies that different organizations should expect to have different security policies. The good news is that this policy requirement is largely consistent with most standards and should be one of the more straightforward practices to understand.

● Practice 2. Organizational culture of security protection —Organizations charged with national infrastructure must develop and nurture a culture of security protection. The culture must pervade the organization and must include

Chapter 5 COMMONALITY 95

Readers familiar with standards and audits will recognize immediately the challenges with the subjective notions intro- duced in the box. For this reason, the only way they can be applied appropriately is for security managers to understand the purpose and intent of the requirements, and to then honestly self-administer a supporting program. This is not optimal for third-party assurance, but it is the only reasonable way to reach the level of world-class security best practices.

Locally Relevant and Appropriate Security Policy Any commercial or government organization that is currently developing or managing national infrastructure already has some sort of security policy. So the question of whether to develop a policy is not relevant; every organization has something . The real question instead for most organizations in national infra- structure roles is how to make the policy more relevant and

great incentives for positive behavior, as well as unfortunate consequences for negative. No security standard currently demands cultural attentiveness to security, simply because it cannot be measured.

● Practice 3. Commitment to infrastructure simplifi cation —Because complexity is arguably the primary cause of security problems in most large-scale environments, a commitment to simplifying infrastructure is critical to ensuring proper security. Determining what “simplifi cation” means is a subjective, local concept that is dependent on the specifi cs of the target environment. No current security standards demand infrastructure simplifi cation.

● Practice 4. Certifi cation and education program for decision-makers —A program of professional certifi cation and security education must be present for those who are making decisions about national infrastructure or who are directly charged with their implementation. Ideally, this should not have to include end users, because this greatly reduces the chances of proper coverage.

● Practice 5. Career path and reward structure for security teams —Those performing security in national infrastructure environments must have clearly defi ned career paths and desirable rewards as part of their professional journey. In the absence of these enticements, important security work is often handled by people who are untrained and poorly motivated. This requirement is generally more meaningful in larger organizations.

● Practice 6. Evidence of responsible past security practice —Just as most craftsmen go through a period of apprenticeship to learn and to demonstrate proper skills, so should an organization have to demonstrate a period of learning and attainment of proper skills before being charged with national infrastructure protection. It is amazing that existing security audits generally do not include a careful inspection of past security practices in dealing with live cyber attacks.

96 Chapter 5 COMMONALITY

appropriate to the local environment. Specifi cally, four basic security policy considerations are highly recommended for national infrastructure protection: ● Enforceable —Most security policies are easy to write down but

are not easy to enforce. Organizations must therefore spend a great deal of time on the issue of security policy enforce- ment. The local threat environment must be a consideration here, because the employees of some companies and agen- cies are more apt to follow security policy rules than others. Nevertheless, a policy is only as good as its degree of enforce- ability, so every organization should be able to explicitly describe their enforcement strategy.

● Small —Most security policies are too large and complex. If there is one exercise that would be the healthiest for national infrastructure teams, it would be to go through existing policy language to prune out old references, obsolete statements, and aged examples. Large, complex security policies with too much detail are to be avoided. A key issue is the direction in which one’s policy is headed; it is either staying the same (stagnant), getting more complex (unhealthy), or becoming smaller and more compact (healthy).

● Online —Policy language must be online and searchable for it to be truly useful in national infrastructure settings. Teams must be able to fi nd relevant requirements easily and should have the ability to cut and paste the relevant statements into their project or process documentation. The old days of printing and distributing a security policy with a fancy cover should be long gone.

● Inclusive —Policy must be inclusive of the proper computing and networking elements in the local national infrastructure environment. This can only be determined by an analysis. Unfortunately, this analysis can be somewhat time consuming and tedious, and without proper attention it could result in an overly complex policy. Considerable skill is required to write policy that is inclusive but not too complicated. These four requirements for security policies in groups

charged with national infrastructure can be subjected to a simple decision analysis that would help determine if the local policy is relevant and appropriate to the mission of the organization; this decision process is shown in Figure 5.4 .

It’s worth mentioning that, as will be seen in the next sec- tion, the culture of the local environment can really have an impact on the development of security policy. In an environment where technology change is not dramatic and operational skills are mature (e.g., traditional circuit-switched telephony), policy

The question is not whether to develop a security policy, but rather what that policy will entail.

Chapter 5 COMMONALITY 97

language can be less detailed and used to identify unexpected procedures that might be required for security. In an environ- ment where technology change is dramatic and operational skills might be constantly changing (e.g., wireless telephony), then pol- icy language might have to be much more specifi c. In either case, the issue is not whether the policy has certain required elements, but rather whether the policy is locally relevant and appropriate.

Culture of Security Protection Our second recommended common practice involves creation of an organizational culture of security protection. When an orga- nization has such a culture of security protection, the poten- tial for malicious exploitation of some vulnerability is greatly reduced for two reasons: First, the likelihood for the vulnerabil- ity itself to be present is reduced, as local diligence will weigh in favor of more secure decision-making. Second, real-time human vigilance in such a culture often helps avoid exploitation. Time after time, the alertness of human beings in a culture of security is effective in helping to avoid malicious attacks. (Readers will remember that the only effective security measures that took place on September 11, 2001, were the ones initiated by human beings.)

Here’s a simple test to determine if a given organization has a culture of security protection. Go to that organization’s local facility and observe how carefully the physical premises are policed for unauthorized entry. If an electronic door is used to authenticate entry, followed by a guard eyeballing every visitor, then chances are pretty good that the culture is one of protection.

Need to perform inventory analysis on locally relevant technologies, tools, systems, and processes

Need to spend significant time with local teams to fix this one – this is more a cultural than technical issue

Need to consider use of documentation tool to place requirements on line (good opportunity for pruning)

Need to go through policy to prune old references, simplify language, and remove obsolete statements

No

No

No

No

Is the policy tight and compact?

Does the policy address all relevent local issues?

Existing

Security

Policy

Much

Better

Policy

Is the policy on line?

Can the policy be enforced?

Figure 5.4 Decision process for security policy analysis.

98 Chapter 5 COMMONALITY

If, however, the person in front of you holds the door open for you to enter without bothering to check for your credentials or, worse, the door itself is propped open, then the culture is proba- bly more open. A culture of security certainly does not imply that things will be perfectly secure, but such a culture is essential in the protection of national assets.

Unfortunately, most of us tend to equate an organizational culture of security with a rigid, paranoid, authoritative, perhaps even military environment. Furthermore, a culture of security is generally associated with managers who avoid risks, stay away from the media, dislike remote access or telecommuting, and demonstrate little comfort with new technologies such as social networking. Similarly, one would equate a nonculture of secu- rity with a young, dynamic, creative, open, and egalitarian envi- ronment. In such a culture, managers are generally viewed to be comfortable with risk, open in speaking to outsiders about their work, in love with every new technology that comes along, and supportive of remote access and telecommuting.

The reality is that neither stereotype is accurate. Instead, the challenge in promoting a culture of security is to combine the best elements of each management approach, without the cor- responding weaknesses. The idea is to nurture any positive environmental attributes, but in a way that also allows for sen- sible protection of national assets; that is, each local environ- ment must have a way to adapt the various adjectives just cited to their own mission. For example, no group generally wants to be referred to as closed and paranoid, but a military intelligence group might have no choice. Similarly, no group wants to be referred to as being loose with security, but certain creative orga- nizations, such as some types of colleges and universities, make this decision explicitly.

As such, organizations must consider the spectrum of options in developing a suitable local culture. This spectrum acknowl- edges how straightforward it can be to assume an inverse rela- tionship between organizational rigidity and security. It’s easy to just make everything rigid and authoritative and hope that a culture of increased security will develop. The challenge, how- ever, lies in trying to break up this relationship by allowing open, creative activity in a way that does not compromise secu- rity. This might result in some aspects of the environment being more secure and others being less so. Such a combined cultural goal should be viewed as a common requirement for all groups involved with national assets (see Figure 5.5 ).

So an obvious question one might ask from the perspective of national infrastructure protection is why the highest level of

An organization with a culture of security is one in which standard operating procedures work to provide a secure environment.

An ideal security environment can marry creativity and interest in new technologies with caution and healthy risk aversion.

Chapter 5 COMMONALITY 99

security culture should not be required in all cases, regardless of any cultural goals of being open, creative, and willing to interact publicly. The U.S. military, for example, might exemplify such a level of rigid cultural commitment to security. One answer, as we’ve discussed above, is that it is diffi cult to require that a cul- ture be in place in an organization. Specifi c aspects of a culture might be required such as strong policy, tough enforcement, and so on, but to require the presence of a culture is easy to confi rm. Nevertheless, the premise is correct; that is, for national infra- structure, certain security standards are required that can only be met in an environment where a culture of security protection is met. This demands the uncomfortable situation in which local managers must honestly work to create the appropriate culture, which in some cases might require decades of attention.

An important element of security culture is the symbolism that management can create by its own behavior. This means that when senior executives are given passes that allow policy violations, this is a serious error as it detracts from the cultural objectives. Unfortunately, the most senior executives almost always outrank security staff, and this practice of senior exemp- tion is all too common. Perhaps major national infrastructure solicitations should include questions about this type of senior executive practice before contracts can be granted to an organi- zation. This might give the security team more concrete ammuni- tion to stop such exemptions.

Infrastructure Simplification Our third recommended common practice involves an explicit organizational commitment to infrastructure simplifi cation. Defi ning what we mean by simplifi cation in the context of

More secure

More rigid

Challenging

cultural option

Straightforward

cultural option

Less secure

More open

More inclusiveMore authoritative

Figure 5.5 Spectrum of organizational culture of security options.

Implementation of a true culture of security cannot happen overnight; it may take years to develop.

A true culture of security must be implemented at all levels of an organization—including the most senior executives.

100 Chapter 5 COMMONALITY

infrastructure requires that we use subjective language. Simpler infrastructure is easier to understand, less cumbersome, and more streamlined. As such, simplifi cation initiatives will be sub- jective and much more diffi cult to measure using some quan- titative metric. To illustrate this process of simplifi cation, let’s look at a typical sort of cluttered engineering schematic that one might use to describe network infrastructure. The chart shown in Figure 5.6 is derived from the design documentation embedded in an infrastructure project with which this author was recently involved. This diagram suffers from the typical sorts of issues that one fi nds in the design and operation of national infrastructure: ● Lack of generalization —Systems in the diagram are not viewed

in a generalized manner. The same thing is shown multiple times in different places in the diagram (e.g., servers), rather than just generalizing one component to depict both.

● Clouding the obvious —Interfaces in the diagram are not depicted obviously. Lines are cluttered across the drawing, and simple interfaces are clouded to avoid what is actually quite obvious connectivity.

● Stream-of-consciousness design —The diagram seems to be the product of fi rst-draft, stream-of-consciousness thinking rather than a carefully planned layout. Too often, infrastructure is put

Popular Public

Network (IP-Based)

System

Management Popular IP-Based

Public Network

. . . Multiple

Mgmt. Apps.

Server

Server

Figure 5.6 Sample cluttered engineering chart.

Chapter 5 COMMONALITY 101

in place in a fi rst draft without anyone taking the time to review and revise.

● Nonuniformity —Objects are not referred to uniformly; the ref- erences to an IP-based network are slightly different, and in fact should just reference the Internet anyway. If one applies some rational simplifi cation to the design in the

cluttered chart shown above, with attention to each of the ele- ments just mentioned, then the resultant functionally equivalent product is much easier to understand. The more improved dia- gram requires that you go back and confi rm that it really does describe the same function, but in fact it does (see Figure 5.7 ).

Analysis of how we simplifi ed the cluttered diagram into something more easily understood highlights some of the tech- niques that can be useful in simplifying a national infrastructure component environment (see box).

Internet

Multiple

Clients

Multiple

Servers

System

Management

Management

Applications

Figure 5.7 Simplifi ed engineering chart.

How to Simplify a National Infrastructure (or Otherwise Complex) Environment

● Reduction in size —The second diagram is smaller than the fi rst one. Relevance of such action to national infrastructure should be obvious. Simplifi cation should include reduction wherever possible. Less code, fewer interfaces, and reduced functionality are all healthy simplifi cation objectives that will almost certainly improve security. In fact, a requirement for national infrastructure should be demonstrable evidence of software removal or reduction initiatives. The only truly secure piece of code is the one that you have removed.

102 Chapter 5 COMMONALITY

The process of auditing these subjective goals will be chal- lenging, if not intractable, but this does not reduce the impor- tance of trying to attain each goal in national infrastructure. Infrastructure simplifi cation could, in fact, be argued to be the most important single goal in the protection of national assets. One bright spot here is that security managers will fi nd kindred spirits with most information technology managers, although it is the rare CIO who truly knows how to manage the simplifi cation and reduction of infrastructure. A good sign that the local orga- nization is trying would be some sort of initiative focused on the reduction or removal of software applications.

Certification and Education Our fourth recommended common practice involves certifi cation and education programs for key decision-makers. Most current computer security education initiatives tend to focus on teaching awareness to end users about proper selection of passwords, stor- age of data, handing of devices, and so on. These awareness ini- tiatives stem from the common belief that computer and network systems would be perfectly secure if end users would just take the time to learn and follow the security policy rules. The situation is reminiscent of doctors blaming their patients for their diseases.

Security auditors generally agree with this view of end-user responsibility, and they will often perform spot checks in target

Simplifi cation may be the fi rst and most tractable step toward creating a new, more secure infrastructure environment.

● Generalization of concepts —The second diagram generalizes concepts more effectively than the fi rst. This should be true in national infrastructure as well. Rather than managing dozens or hundreds or thousands of special cases, it is more effective to have a planned generalization strategy that allows for simpler management. Obviously, this requires some balancing with local diversity requirements.

● Cleaner interfaces —Perhaps the most obvious difference between the two diagrams is the much cleaner view of interfaces that the second one provides. Because national infrastructure will include complex interfaces between systems, initiatives to simplify these interfaces must be present to optimize security for national assets.

● Highlighting of patterns —The second diagram demonstrates functional and data fl ow patterns in an obvious manner. This simplifi es any changes that might have to be made to the architecture. Infrastructure should also be designed in a manner to highlight important patterns in data or processing.

● Reduction of clutter —The fi rst diagram is as cluttered as one can imagine, and this generally indicates a stream- of-consciousness design process. Too often, national infrastructure emerges in the same manner, with one system being put in place and then another, they are then connected to something else, and on and on. The result is usually not optimal from a security perspective.

Chapter 5 COMMONALITY 103

environments. This usually involves quizzing random individu- als about their knowledge and interpretation of the local secu- rity policy. When the inevitable bad grade occurs because high percentages of individuals do not know some of the policy rules, security teams are forced to increase the intensity of the aware- ness program with posters, videos, mandatory tests, and even punishments for end-user ignorance.

Based on decades of experience in performing these types of audits, supporting them, and also being subjected to them, the conclusion reached here is that the goal of reaching 100% end- user awareness of security is impractical. Certainly, security edu- cation for end users does not hurt, because everyone should be aware of the risks of any actions they might take that could dam- age security in the local environment. If end users are entrusted with proprietary information, for example, they need to under- stand the implications of allowing such information to be pro- vided to unauthorized sources.

For national infrastructure protection, however, a much more practical goal is to focus primarily on improving the security competence of decision-makers rather than on end users. The distinction here is subtle, but fundamental. Key decision-makers in national infrastructure settings include the following: ● Senior managers —These are the people who set fi nancial and

operational priorities affecting national infrastructure. They include the most senior managers in an organization or the highest ranking in the military.

● Designers and developers —These are the network, system, and application designers and developers who determine what security features and functionality are in the systems that peo- ple use. They often work in information technology groups.

● Administrators —These are the system and network adminis- trators who perform the day-to-day tasks of maintaining and running the systems that people use. Too often, these folks are underpaid and poorly trained.

● Security team members —These are the security staff charged with the organizational systems for protecting assets. An increasing number of organizations outsource aspects of this work. There is nothing wrong with this trend, as long as the arrangement is well managed and coordinated. These four types of key decision-makers are the people who

can make the most substantive difference in the security of an organization and for whom 100% coverage should be a trac- table goal. It doesn’t hurt that the size of the key decision-maker population in a company or agency will be much smaller than the total population. It also doesn’t hurt that they tend to be the

One hundred percent end- user awareness of security policies may remain an illusive goal.

104 Chapter 5 COMMONALITY

ones best trained to understand the importance of security. From an investment perspective, the returns on education invest- ment look quite different for end users and decision-makers (see Figure 5.8 ).

The message embedded in the ROI curves in Figure 5.8 is that a small initial investment in security certifi cation and edu- cation for end users produces a reasonable initial return. This return rapidly diminishes, however, because in a typical envi- ronment there is only so much an end user can do. In fact, in the best designed environments, the obligation for end users to make security decisions on their own is always minimized. For key decision-makers, the ROI is ongoing and steadily increas- ing throughout the investment lifecycle. Unlike end users, key decision-makers can consistently apply their increased secu- rity knowledge to infrastructure in a meaningful and scalable manner.

To summarize, our recommendation here is a twofold approach for security certifi cation and education in a national infrastructure environment: ● Key decision-makers —Focus on providing ongoing, lifecycle

programs for decision-makers in security certifi cation and

Cost/Size of Investment

Return on Investment (ROI)

End User Curve

High Initial ROI (End Users)

Increasing Ongoing ROI (Key Decision-Makers)

Key Decision-Makers

Curve

Recommended Investment Period for Key Decision-Makers

Recommended Investment Period for End Users

Figure 5.8 Return on investment (ROI) trends for security education.

Target the key decision- makers in your quest for organizational security policy awareness and competence.

Chapter 5 COMMONALITY 105

education. By focusing on key decision-makers, the returns will be consistent, increasing, and scalable.

● End users —Create low-cost, high-initial-return activities for certifying and educating end users. As a complement, systems must be designed that minimize the decisions end users make about security. The specifi c certifi cation and education programs for a given

environment should be locally determined and appropriately applied. They are not diffi cult to fi nd or create but can be mis- applied without some careful planning. Well-known security certifi cations, such as Certifi ed Information Systems Security Professional (CISSP), are excellent for system or network admin- istrators but totally unnecessary for end users. Similarly, aware- ness programs on selecting good passwords are fi ne for end users but will just annoy your system administrators.

Career Path and Reward Structure Our fi fth recommended common practice involves the creation and establishment of career paths and reward structures for security professionals. It should come as no surprise that organi- zations charged with national infrastructure should demonstrate some common form of career path and reward structure for security staff. This is particularly important, because to perform security tasks properly, some degree of longevity is desirable. Too often, important cyber security tasks are attempted by staff who are new to the security discipline and who are poorly compen- sated for their work.

Fixing this might seem obvious, but virtually no security stan- dards used for the purposes of audit include this in a meaning- ful way. Elements that should be commonly present in national infrastructure environments include the following: ● Attractive salaries —Infrastructure organizations should dem-

onstrate salary structure that takes into account the special- ized skills associated with cyber security. Salaries should be above industry averages, a metric that can be quantitatively audited. (Amazingly, I’ve never seen security staff salaries audited as part of any due diligence activity by an auditor.)

● Career paths —Opportunities for career advancement, promo- tion, and salary increase should be present in infrastructure organizations. Perhaps more than any other information tech- nology or network-related discipline, security engineering of national infrastructure requires years of experience in order to develop proper judgment. If these years do not include

Creating career paths and incentives is important in any fi eld, no less so in security management.

106 Chapter 5 COMMONALITY

attention to career issues, then the organization is unlikely to maintain the best staff.

● Senior managers —It is desirable for senior managers in infra- structure organizations to have some degree of heritage in the security community. This certainly will help with decision- making at the senior level, but more importantly it serves as a symbol for the security staff that senior level management is attainable from the security ranks. These career-related organizational attributes are rarely dis-

cussed in the context of determining whether proper security is in place in an organization. Auditors never discuss these issues. This is unfortunate, as good salaries and career paths for security staff are more relevant to the overall security posture of an orga- nization than checking for trivia such as password length, time- outs after bad login attempts, and other elements commonly found in security standards.

It is also worth noting that companies and agencies should not actively recruit and hire individuals who have a history of breaking laws on computers and networks. Hacking, in its origi- nal incarnation, was all about the desire to learn and share; when hackers demonstrate this type of perspective, they can easily blend into a company or agency and be productive. The associ- ated career and reward track for such individuals is rarely promo- tion or money but rather ongoing or increased access to the latest and greatest types of technologies.

Responsible Past Security Practice Our sixth recommended common practice involves two specifi c actions: The fi rst is that any company or agency being considered for national infrastructure work should be required to demon- strate past practice in live security incidents. The second is that companies and agencies must do a better job of managing their inventory of live incidents, including databases of key factors, root causes, and security learning from events. These two seem- ingly obvious actions are almost never performed explicitly, and most companies and agencies do not even maintain formal doc- umentation on past security incidents.

The good news is that most solicitations for national infra- structure project work do include some requirement for dem- onstrating past engineering practices, so there is certainly a base on which to improve matters for security. When federal agen- cies contract for engineering or technical work, for example, boilerplate language is usually embedded into the contract for

A strong indicator of a healthy security environment might be something that is often overlooked, such as heritage of the senior security managers in a company.

Companies and agencies should maintain a historical record showing clear incident response documentation.

Chapter 5 COMMONALITY 107

information on previous projects, similar work activities, and lists of reference clients. This practice is appropriate and valu- able, although it is usually treated too much as a generic type of information-gathering task.

For security, in particular, this practice currently involves requests for information on security policies, security architec- tural elements, and even specifi c techniques such as encryption. Such requests are important and should be highlighted for national infrastructure protection projects. The problem is that such inqui- ries simply do not go far enough. In particular, any organization being considered in a solicitation that involves national infrastruc- ture should provide evidence of at least the following past practices: ● Past damage —The organization should be able to provide

evidence of past security incidents that it dealt with that pro- duced real malicious damage to some valued asset. Although this might seem paradoxical, the reality is that no organization can claim true skill in securing large infrastructure if it has not dealt with a real incident in the past. Groups who are forth- coming in explaining these past incidents are also generally more mature in their current security processes.

● Past prevention —Similarly, the organization should be able to provide evidence of incidents prevented. This is tougher than one might think, because in many cases security protec- tions have a preventive effect that is not easily determined or measured. So only the truly skilled security organizations can provide this evidence of deliberate action that prevented an attack from succeeding. A good example might be the estab- lishment of real-time network fi ltering well in advance of any DDOS attack; if this fi ltering was actually used to stop an attack attempt, it demonstrates excellent judgment regarding the organizational priorities around security.

● Past response —This is the most commonly cited security experience component. Groups can generally point to their response functions as being invoked during worms, viruses, and other attacks. In any formal project solicitation, these requirements should

be highlighted and assigned high priority. Few requirements can properly highlight an organization’s ability to handle security situations in the future as their experiences dealing with similar matters in the past.

National Commonality Program The challenge in creating a new national program of ensur- ing commonality with state-of-the-art security practices in

A mature security organization will admit to successful attacks against them.

Providing evidence of successful preventive measures is a challenge for most organizations.

108 Chapter 5 COMMONALITY

infrastructure protection involves balancing several different concerns: ● Plethora of existing standards —Most organizations are already

frustrated with the number of standards and audits that must be covered. The implication is that the creation of a new national security standard commensurate with the six prac- tices described in this chapter would not be well received.

● Low-water mark versus world class —As we’ve discussed, the existing security standards and audits in place today are more focused on creating a common low-water mark, rather than pushing groups to reach for world-class status in security.

● Existing commissions and boards —The fi eld is already crowded with national commissions, working groups, and boards com- prised of business and government leaders who are working to create sets of recommendations for infrastructure security. They are unlikely to go away and must be factored into any implementation plan. While these may not be formal standards with associated

audit processes, affected organizations feel the pressure to review these works and to demonstrate some degree of acceptance, if not compliance. The solution to balancing these concerns lies in several implementation approaches and hints that are based on previous experiences with multiple standards and requirements, such as the Orange Book, Red Book, and associated “security rainbow series” in the 1980s. The fi rst is that government really should adopt a single standard for all commercial and govern- ment security audits. It really doesn’t even matter which audit standard is selected as long as it is only one . All subsequent gov- ernment solicitations and contracts should demand compliance with this standard. Commercial entities might gradually merge toward this standard.

Second, the world-class practices described here should be embedded into all government solicitations and contracts as func- tional requirements on companies and agencies. This would avoid the problems of audit compliance and would push the security components into the functional category along with performance, processing, storage, and networking. Government agencies could perhaps complement this by rewarding or providing incentives for the inclusion of these requirements in private deals between companies.

Do not try to work around the existing security commissions and boards; instead, factor them into your overall security plans and policies.

109 Cyber Attacks. DOI: © Elsevier Inc. All rights reserved.

10.1016/B978-0-12-384917-5.00006-8 2011

DEPTH

Sun myth: If a person is wearing a foundation makeup with SPFs of #4 or #8, then she won’t need additional sunscreen or sunblock .

www.ultimate-cosmetics.com

The general security strategy of defense in depth is based on the observation that any given layer of protection can fail at any time. As such, defense in depth involves the deliberate introduc- tion of multiple layers of defense in order to increase the likeli- hood that a given attack will be stopped or at least slowed down. This likelihood is dependent upon the quality and relative attri- butes of the various defensive layers. Cost and end-user experi- ence issues usually create constraints on just how strong the various layers can actually be in practice. Most security experts understand this strategy of defense in depth, but evidence of its use in national infrastructure settings is often lacking. This is too bad, because the protection of national infrastructure lends itself naturally to multiple layers of defense.

The general schema associated with layered defense is that a series of protective elements is located between an asset and the adversary. Obviously, it would be best if the series is actually that—a serial collection of protective elements that must each be traversed successfully to gain access to a protected resource. Most of the time, however, the layering is not so effi cient and may include different combinations of elements between an asset and an adversary. The strategic goals in such cases are to detect and remove any single-layer access paths and, obviously, to avoid sit- uations where the layers might be confl icting. For national infra- structure, the goal is to place multiple security layers in front of all essential services (see Figure 6.1 ).

The security intent for any series of layers is to enforce policy across all possible access paths to the target asset. Thus, if an asset is accessible through a single entry point, then the layers only need to enforce policy at that point. If an asset is broadly accessible from a collection of different entry points, then the layered defense needs to fan out across these points to enforce policy. Defense in depth methods are said to fail if all of the

6

110 Chapter 6 DEPTH

layers do not either block or suffi ciently degrade attack attempts at the protected asset, resulting in security policy violations by an adversary. It is relatively easy to determine that a failure has occurred when an attack is detected; however, when an attack goes unnoticed or when the forensic analysis after an attack can- not determine the point of exploitation, then holes in layered defenses might remain indefi nitely.

Defense in depth implementations are sometimes inappropri- ately or even maliciously bypassed by presumably trusted users, generally insiders to a company or agency, including its employ- ees, contractors, and partners. For example, an infrastructure organization might create diverse layers of security functional- ity to ensure that intruders cannot compromise assets from an external environment such as the Internet. Problems arise, how- ever, if malicious insiders can directly access and compromise assets. This implies that great rigor and discipline are required to ensure that defense in depth truly surrounds an asset, both inter- nally to an organization, as well as externally on the Internet. This generally requires additional functional controls on the local enterprise network to protect assets from insiders.

Depth strategies sometimes involve the familiar military notion of one protection layer slowing down an intruder. It turns out that throttling does not always extrapolate well to cyber security. In practice, cyber security methods tend to be binary in their functionality; that is, a protection will either work or it will not. Debates thus arise around how long an approach will hold off attackers, as in the selection of cryptographic key length.

Security Policy

Attack

Slowed

Attack

Blocked

Attack Gets Through

(Layered Defense Failure) Attack

Unblocked

Series of Defensive Layers

Asset

Layer 2 . . . Layer nLayer 1

X X

X

Figure 6.1 General defense in depth schema.

If layered defenses are penetrated, it is crucial to identify the entry point used by the attacker.

Do not overlook the need for protection against both internal and external adversaries.

Chapter 6 DEPTH 111

Similarly, network attacks are often dealt with by throttling or rate-limiting the traffi c allowable into a target asset environment. These approaches might work to a degree, but they are the excep- tions, and it is recommended that cyber security architectures for national infrastructure not rely on any element having only a partial effect on a given attack.

Effectiveness of Depth Academics formally model the effectiveness of a collection of defensive layers using mathematical probability. Such an approach requires that one quantitatively measure the relative dependencies between the layers, as well as the probability of effectiveness for any given layer. Unfortunately, in any nontrivial environment, both of these estimates are unlikely to be more than just an educated guess. We know, for example, that the success of access controls for enterprise applications is dependent on the success of strong authentication for remote access. Trying to accurately quantify this dependency for probabilistic analysis is a waste of time and will not result in any estimate better than an expert guess.

Thus, from a practical perspective, and in the context of real national infrastructure protection, determining the effectiveness of a defense in depth scheme must be done via educated guesses. We can make this sound better by referring to it as informal sub- jective reasoning based on relevant security factors , but it is still just a guess. The relevant factors for estimating effectiveness of a layer include the following: ● Practical experience —One can certainly analyze practi-

cal experience and past results for a given security method. This is dangerous if taken too literally, because many attacks are missed, and seemingly correct, but actually vulnerable, defenses might be dormant for a period of time before an attack.

● Engineering analysis —Experienced security engineers will use their knowledge and expertise to provide excellent judgment on whether a given layer will be effective. Vendors and sales- people are to be avoided in this process, because they will invariably distort their product and service capability.

● Use-case studies —Providing some rigor to the engineering analysis is a good idea, and the familiar use-case methodology is especially appropriate for security layers. It is really a form of testing.

● Testing and simulation —Actual testing of a layer in a controlled setting will provide good information on its effectiveness.

Ideal defensive strategies will stop—not slow down—an adversary.

How can effectiveness of a security layer be measured or quantifi ed?

112 Chapter 6 DEPTH

Simulation is also a good idea in cases where a defensive layer protects against something not easily tested, such as a massive denial of service attack. To illustrate this approach, let’s start with a simple setup,

as shown in Figure 6.2 . Specifi cally, a single layer of protection depth is depicted and is estimated to have “moderate” effective- ness. We can assume that some subset of the factors described above was used to make this determination. Maybe some team of experts analyzed the protection, looked at its effectiveness in similar settings, and performed a series of tests and simulations. In any event, let’s assume that they decided that a given protec- tion would be moderately effective against the types of attacks to be expected in the local threat environment.

The determination that this single layer is “moderately” effec- tive is nothing more than a subjective guess in most cases. It is, however, an important piece of information for national infra- structure protection because it implies that the protection will not work in all cases; that is, the experts have determined that some types of attacks will bypass or break the protection and will thus expose the asset to malicious intruders. As a result, when a given protection layer does not address all known attacks, then we can conclude the following: ● Flaws —The protection might be fl awed. This could be some

minor issue such as an obscure bug that would allow certain types of attacks or it could be potentially front-page news with major implications. In either case, fl aws in protections require either that they be fi xed or that they be mitigated by a comple- mentary layer of protection.

● Suitability —The protection might be unsuited to the target environment; for example, it might be intended to prevent

Single Defensive Layer

(Moderate Effectiveness)

Moderately Effective

Layer Allows Access

Layer 1

X

X

X

Asset

Figure 6.2 Moderately effective single layer of protection.

A moderately effective defense strategy will stop most, but not all, attacks.

Chapter 6 DEPTH 113

events A and B in an environment where the real threat is event C. Such scenarios are commonly found during incident response, when some event has occurred and the presumed protections are discovered to have had little effect, simply because of a mismatch. This is fi xed by either changing the layer or complementing it with another. Whether the layer is fl awed or mismatched, the situation

is made worse if the adversary has knowledge of the situation. Regardless of the common argument by hackers that exposing problems in a protection method should always be reported, the reality is that such information generally does more harm than good. Certainly, if an organization is lax in fi xing a problem with broad implications, this is unacceptable, but the technique of extorting that group into taking immediate action is not always in everyone’s best interests. The hacker who exposes vulnerabili- ties in a moderately effective mobile telephony control, for exam- ple, without fi rst alerting the service provider, might be guilty of degrading essential communication services that might affect human lives.

Assuming an organization is diligent and chooses to improve or fi x a moderately effective protection, the result will be that the new estimate or guess might be “highly” effective. For example, suppose that some home-grown intrusion detection system is becoming diffi cult to maintain. The local team might thus deter- mine that it is only moderately effective and might replace it with a vendor-supported product. In most cases, the new system would now be viewed as highly effective (with the caveat that no intrusion detection systems ever seem to work as well as they should). The end result is that the layer has now been improved from moderately to highly effective. It should be obvious that even in a highly effective protection environment, there will always be exceptional conditions where the protection may fail (see Figure 6.3 ).

Improving one layer is not, however, the only option available. An alternative would be for the moderately effective control to be left in place and complemented with another layer of protection. This has certain advantages, including reducing the cost and risk of forklifting out a security protection layer and replacing it with a new one. The result of complementing one moderately effec- tive protection layer with another is that the end result should mitigate a larger set of attacks. This does introduce an odd sort of calculus to the security manager, where decisions are required around whether some number of moderately effective protec- tions is better or worse than a smaller number of stronger protec- tions (see Figure 6.4 ).

Multiple layers of protection will mitigate the effects of fl aws or protections that are unsuited to the target environment.

A protection layer can be improved to become “highly” effective, but no layer is 100% effective all of the time.

114 Chapter 6 DEPTH

The answer to whether multiple moderately effective layers outperform fewer highly effective ones will depend on aggrega- tion considerations. That is, if two moderate protections comple- ment each other by balancing each respective weakness, then the composite protection will be quite good. If, on the other hand, multiple moderate protections suffer from similar weak- nesses, then the weakness will remain in the aggregate protec- tion. In practice, security managers generally should look for a diverse set of protections that are as strong as possible and that balance weaknesses in some demonstrable manner. For national infrastructure protection, this will typically involve layers of pro- tection in authentication, malware protection, access controls, encryption, and intrusion detection.

Single Defensive Layer

(High Effectiveness)

Highly Effective Layer

Disallows Virtually

All Access

(always exceptions)

Layer 1

X

X X

X

Asset

Figure 6.3 Highly effective single layer of protection.

Layer 2

Two Defensive Layers

(Both Moderate Effectiveness)

Less Secure

Than One Highly

Effective Layer?

Layer 1

X

X

X

Asset

Figure 6.4 Multiple moderately effective layers of protection.

Diversity of protection layers—including diversity of weaknesses—is critical in maintaining successful protection against attacks.

Chapter 6 DEPTH 115

Layered Authentication Most information technology (IT) and security teams in govern- ment and industry are committed to reducing the number of passwords, passphrases, handheld tokens, certifi cates, biomet- rics, and other validation tokens that exist in their environment. These initiatives are generally met with great enthusiasm among end users, because they result in simpler, cleaner infrastructure and much less for end users to have to remember, protect, or write down. One cannot deny that such simplifi cation has a ben- efi cial impact on overall security. For these reasons, various pro- posals have been made for national authentication systems run by government and that would include every citizen.

Single sign-on (SSO) initiatives are generally used to accom- plish this authentication simplifi cation objective. SSO is accom- plished by the use of a single, common identifi cation and authentication system for all relevant applications. This com- mon system is then embedded into one identity management process so reported identities can be administered and protected uniformly. The simplifi cation inherent in SSO is desirable from a security perspective, because it reduces the likelihood of errors that result when multiple complex login systems are present. Common identity management is thus generally desirable from a security perspective, especially in enterprise settings.

Problems can arise, however, in national infrastructure pro- tection environments if the process of streamlining authenti- cation goes too far. Even the staunchest advocate of SSO must agree that, for certain applications, a properly managed, properly designed, and diverse series of authentication challenges that are reliant on separate proof factors will be more secure than a com- parable SSO system. The diverse series of authentication steps will certainly be less convenient for end users but, if run cor- rectly, will be more secure. This is because such a scheme avoids the nightmarish scenario where a single login provides an adver- sary with common access across multiple national infrastructure systems. This attack scenario is so unacceptable at the national level that it dictates special consideration.

Specifi cally, for national infrastructure management, organi- zations can acceptably maintain the goal of balancing the risks and rewards of SSO for all enterprise-grade applications such as business e-mail, routine applications, and remote access. As long as no national assets can be directly compromised with SSO access, this is fi ne. Companies and agencies charged with national infrastructure can and should move to an SSO scheme with corresponding identity management. For critical national

End users will embrace authentication simplifi cation initiatives, and these are certainly easier to monitor from a security management standpoint.

Single sign-on initiatives may be embraced by end users but may not provide the ideal level of security protection.

116 Chapter 6 DEPTH

services and applications, however, a more complex, defense in depth scheme is highly recommended for end-user authentica- tion (see box).

Single sign-in access can be part of a multilayered defense in depth strategy.

Factors of a Successful National Infrastructure SSO Access System

Critical national infrastructure services need a defense in depth scheme that is developed with the following considerations: ● Diversity with single sign-on —Authentication systems for national asset protection must be different from the SSO

scheme used for enterprise access. This implies that a separate technology, vendor, and management process should be considered between enterprise SSO and national infrastructure authentication. The goal is to ensure that fl aws in one authentication system are not present in the other.

● Diversity of proof factors —Similarly, the familiar proof factors: ● “Something you know” ● “Something you have” ● “Something you embody (biometrics)” ● “Somewhere you are” should be diverse for national assets from any SSO proof factors. This implies that employees should not be handed a single handheld authenticator that can be used to gain access to e-mail and also to some critical infrastructure operational component.

● Emphasis on security —While it is acceptable to emphasize usability in enterprise SSO initiatives, the emphasis of national infrastructure protection should shift squarely toward security. The only relevant end-user issues are ones that simplify usage to reduce errors. Convenience should not necessarily be a major goal, as long as the authentication scheme does not drive bad behavior such as sharing tokens or writing down passwords.

A resultant typical defense in depth scheme for national infra- structure organizations would include SSO for enterprise-grade applications and access and a subsequent, diverse authentica- tion process for all national assets. The result is that end users would need to be authenticated twice before gaining access to a critical asset. Correspondingly, intruders would have to break through two authentication systems to gain malicious access to the target asset. End users probably would not like this and the costs are higher, but the increased security is worth the trouble (see Figure 6.5 ).

For multiple critical national assets in an infrastructure envi- ronment, the depth strategy should include maximal diversity for each asset. That is, the general computing characteristics

Chapter 6 DEPTH 117

and source of the authentication functionality should be diverse. Furthermore, the factors used in establishing proof of identity for critical assets should be stronger than simple passwords; handheld authentication or biometrics would be recommended. An implica- tion here is that the underlying infrastructure be operated with the greatest precision and correctness. Administrative procedures for obtaining an authentication token, restoring access when a token or password is lost, and providing assistance to confused end users must be carefully designed to avoid social engineering attacks. At the national level, this would require frequent testing.

A key modern consideration for enterprise authentication is the degree to which mobile access to infrastructure poten- tially changes security posture. As an example, consider that most organizations go to great lengths to ensure that several lay- ers of authentication reside between remote workers and sensi- tive applications such as enterprise e-mail. In fact, see the box to follow the experience most people have when trying to get their enterprise e-mail from a remote location using a laptop.

The example in the box also highlights the importance of rec- ognizing trends in technology as national infrastructure protec- tion initiatives are considered. For the enterprise, the old notion of protected perimeter thus disappears with the advent of mobile access across wireless carrier infrastructure. One still fi nds archi- tectures where users must “hairpin” their mobile access to the enterprise and then through a fi rewall to the target application, but this practice is likely to wane (see Figure 6.6 ).

Diverse

Authentication

Two Diverse Authentication Layers

SSO

X

X

Critical

Asset

Enterprise

Assets

Enterprise

Figure 6.5 Schema showing two layers of end-user authentication.

Unfortunately, mobile devices eliminate the multi- layered protection most companies build into their remote network access.

118 Chapter 6 DEPTH

For applications such as enterprise e-mail, this type of conve- nient bypass might be perfectly fi ne. In fact, for enterprise e-mail specifi cally, it would be unreasonable to expect that workers in national infrastructure settings should not be allowed mobile access. For more sensitive national infrastructure applications, however, such as those that provision or control critical systems, a threat analysis would be required before any alternative paths with mobile devices are allowed. Classifi ed information would be another example asset that requires multiple layers with- out mobile access bypass. These types of requirements should fi nd their way into any type of national infrastructure support contracts.

Exposing critical national assets to mobile access (even by trusted personnel) opens a gateway for an adversarial attack.

Multi-Layered Protection: Five Steps to Remote E-Mail Access

A typical remote worker will need to follow these steps to access their enterprise e-mail account: ● Authentication layer 1 . The user must fi rst login to the computer. Presumably, this is done using a password that is

set by the enterprise information technology or security group. ● Authentication layer 2. The user must then login to the local WiFi or broadband access network.

Sometimes this is free; other times it requires a credit card, which can be viewed as an added identifi cation step.

● Authentication layer 3. The user must then login to the remote access server, probably over a virtual private network (VPN). Most of the time, companies and agencies require a personal identifi cation number (PIN), password, or handheld token to authenticate VPN access.

● Authentication layer 4. The user must then login to the enterprise network, probably with some sort of domain password. This is also controlled by the local information technology or security group.

● Authentication layer 5. The user must fi nally login to the specifi c e-mail application being used by the enterprise. Sometimes this requires another password, but often it just requires access. On the surface, this would seem like the ultimate in layered authentication with no less than fi ve layers! The

problem is that many organizations provide their employees with means to remotely access applications such as e-mail with a handheld device. Consider, in this case, the experience most people have when trying to retrieve their enterprise e-mail using a mobile device: ● Authentication layer 1. The user must simply login to the mobile device, click on the e-mail icon, and then read or

create mail. This is obviously only one layer of authentication for mobile devices, and it demonstrates the importance of

recognizing that users might fi nd more convenient paths around presumed layers of authentication.

Chapter 6 DEPTH 119

Layered E-Mail Virus and Spam Protection Commercial environments are increasingly turning to virtual- ized, in-the-cloud solutions for their gateway fi ltering of e-mail viruses and spam. This decision allows the organization to remove the gateway fi lters or to simply offl oad the work those fi lters must perform. This is a healthy decision, because a gen- eral security principle is that attacks should be stopped as close as possible to their source. The network is certainly closer than the attack target’s ingress point, so virtual fi ltering is desirable. It is also helpful to the carrier, because it reduces the junk fl oat- ing around network infrastructure, which helps carriers perform their tasks more effi ciently in support of national services.

Managers of commercial environments have also come to recognize that their computing end points cannot rely solely on gateway or in-the-cloud processing. As such, the state of the practice in e-mail virus and spam protection involves a defense in depth deployment of fi lters to each laptop, netbook, personal computer, and server in the enterprise. The approach is even beginning to fi nd its way to the mobile handheld device, where the threat of viruses and spam is increasing. As such, a given virus or spam e-mail sent from a malicious source will have to fi nd its way through at least two layers of fi ltering in order to reach its intended source (see Figure 6.7 ).

This cloud fi ltering arrangement found in most compa- nies is acceptable for organizations charged with national

Layer 1

(Computer

or Device)

Layer 2

(WiFi)

Layer 3

(VPN)

Layer 4

(Enterprise)

Layer 5

(E-mail)

Direct Mobile Access

Figure 6.6 Authentication options including direct mobile access.

Mobile devices are susceptible to viruses and spam, yet spam is more of a nuisance than an actual threat to national infrastructure.

120 Chapter 6 DEPTH

infrastructure. For the most critical applications, it is recom- mended that a depth approach involving both in-the-cloud and perimeter processing be employed. In addition, for key execu- tives in these companies and agencies who might be directly targeted by adversaries, additional desktop and application fi l- tering might be prudent. Practical experience suggests that spam is more a nuisance than signifi cant threat to national asset man- agement, so the likelihood of attackers using spam to interrupt national services is only moderate. In addition, antivirus soft- ware has become less relevant in recent years, simply because so many software threats such as well-coded bots are not easily detected by antivirus software. Research into better techniques for detecting the presence of malware should become an imme- diate national priority.

Layered Access Controls Access controls determine who can access what resources under which conditions. They are one of the most common and most mature security protection methods, dating back to the earliest electronic computers. If some asset is protected by a single set of access controls, then this is similar to using a single combina- tion lock to protect a physical asset. That is, if an individual has the correct combination, then access is allowed. Common access controls include access control lists (ACLs) on Windows ® -based operating systems and permissions vectors in UNIX ® -based operating systems. These are implemented as software data structures that determine access based on some defi ned policy.

One approach to using defense in depth to protect a software application involves embedding one type of access control into the application environment and then hosting the application

Layer 1 Layer 2

Security

Software

E-mail

Source Cloud

Security

Provider

Internet Enterprise

Figure 6.7 Typical architecture with layered e-mail fi ltering.

Antivirus software, while still necessary, is not likely to detect such threats as a botnet attack.

Chapter 6 DEPTH 121

on an operating system that utilizes a different type of access control. In such a setup, access to the application can only be obtained by successfully negotiating the following layers: ● Access control layer 1 . The user must be permitted entry to the

operating system via the operating system access controls. This might be UNIX ® permissions, Windows ® ACLs, or some- thing similar.

● Access control layer 2 . The user must be permitted entry to the application via the application access controls. This is likely to be a password embedded in the application environment and controlled by the application owner. In cases where an operating system and application cannot

be remotely reached, these two layers can be augmented with additional diverse controls such as guarded access to the physi- cal premise or to a locked data center. This implies that access to an application would require fi rst obtaining physical access to a console before access to the operating system and application can even be attempted. These two layers of authentication are important and should be tested in every national infrastructure environment, especially ones employing supervisory control and data acquisition (SCADA), where computer security techniques have a more short-lived legacy. A caution, however, is that insid- ers are likely to possess both types of access, so the layers will not be helpful in stopping most forms of sabotage.

In cases where remote access is allowed, then the use of a fi re- wall is the most common method to ensure policy compliance for those permitted access. Such policy is almost always based on the source Internet protocol (IP) address of the requesting party. This is not the strongest of access control methods, sim- ply because IP addresses are so easily spoofed. Also, to maintain such a scheme, a complex and potentially error-prone or socially engineered bureaucracy must be put in place that accepts and maintains access requests. When used in conjunction with additional access control layers such as operating system and application controls, the result might be acceptable in some environments (see Figure 6.8 ).

For national infrastructure protection, critical assets should be covered by as many layers of access control as deemed fea- sible. As with authentication, the issue of end-user convenience must be viewed as lower priority if critical national services are at stake. Some general heuristics for protecting national infrastruc- ture with layered access controls include the following: ● Network-based fi rewalls —Using cloud fi rewalls offers an addi-

tional blanket layer of control. This technique is useful as a complement to existing enterprise controls, especially because

Some form of access control is present in any network connection (e.g., your personal password to access your e-mail account).

Restricting physical access to assets always adds another layer of protection from outsiders, but not from internal saboteurs.

The implementation of layered access controls places greater emphasis on protection than on end- user convenience.

122 Chapter 6 DEPTH

carrier-based systems will generally differ from whatever fi re- walls and related systems might be deployed in the enterprise.

● Internal fi rewalls —This provides yet another layer of protec- tion within the enterprise to ensure that individuals with access to resource X only gain access to that resource and no other. Routers can often provide a simple packet-fi ltering capability as part of their native processing suite, which sim- plifi es architecture and minimizes cost.

● Physical security —Excellent facility and premise-access secu- rity provides an additional tangible layer of protection and is essential for any national infrastructure protection initiatives. This must be complemented by selecting suitable applica- tions and systems that can never be accessed remotely or even across a local area network. When multiple access control systems are in place, the benefi t

of layering is reduced when the underlying administration function is performed by one team using a common set of tools. When this involves a protected and carefully managed security operations center the situation is acceptable, but when the management is ad hoc and poorly controlled the layering might be undermined by an attacker who successfully infi ltrates the administration systems.

Layered Encryption Encryption is an effective and well-known security control for protecting information. While mathematicians and computer scientists have created hundreds of different taxonomies for categorizing symmetric and public key systems, the box shows specifi c methods that are useful for the protection of national infrastructure.

Layer 1

(Firewall Based on

Source IP Address)

Layer 2, 3

(Application and OS

Access Controls)

Enterprise Remote Access

Application

Figure 6.8 Three layers of protection using fi rewall and access controls.

Multiple access control systems must be well managed so as not to allow an internal attacker successful infi ltration to the systems.

Chapter 6 DEPTH 123

The good news is that, for the most part, these fi ve encryption methods will not collide in practice. They can be used in combi- nation and in cooperation, with no great functional or admin- istrative problems expected. It is also perfectly fi ne to encrypt information multiple times, as long as the supporting adminis- trative tools are working properly. As such, one can easily imag- ine scenarios where all fi ve systems are in place and provide fi ve different layers of information protection. Not all will typically reside in a perfect series, but all can be in place in one infrastruc- ture setting providing layered security (see Figure 6.9 ).

The bad news, however, is that each will typically require its own user administration and key management systems. The result is a disparate view of cryptography across the enterprise that can be seen in the somewhat scattered arrangement in

Five Encryption Methods for National Infrastructure Protection

1. Mobile device storage —Mobile smart phones and laptops should have native encryption to protect against loss or theft and the resulting information compromise. The encryption will never be perfect but should provide useful protection in the fi eld. Several vendors offer this type of encryption as an add-on service, but this should eventually become a native function in all mobile devices and laptops.

2. Network transmission —Any sensitive data being transmitted within an enterprise or between knowing partners should be encrypted. The traditional means for such encryption has been symmetric and embedded in hardware devices. More recently, the associated cryptography is often software based and involves public keys supported by public key infrastructure (PKI) tools. When network transmission occurs in an ad hoc manner, the practical consideration is that shared cryptography simply does not exist between organizations due to complexity. This makes it diffi cult to encrypt network traffi c without coordinating things in advance.

3. Secure commerce —If an organization offers electronic commerce services over the Internet, the use of common encryption techniques such as Secure Sockets Layer (SSL) is presumed. The associated cryptography here will be public key based.

4. Application strengthening —E-mail is the most obvious application that can introduce secrecy and authentication properties via the use of encryption. As noted above, federating this cryptography, almost always public key based, between organizations has not been done on a wide scale to date.

5. Server and mainframe data storage —Encryption on servers and mainframes has received considerable attention in recent years but should be viewed with suspicion. Data at rest is poorly protected by cryptography because the associated key management systems, which require a long life, can have obvious holes. In the worst case, sloppy key management can make data less secure. Note that smart phones and laptops are different from servers because they are moving .

Information can be encrypted multiple times to achieve layered protection.

124 Chapter 6 DEPTH

Figure 6.9 . This is unfortunate, because it increases complexity, which increases the chances of error or compromise, especially to underlying infrastructure. Regardless, the use of cryptography in national infrastructure protection should be encouraged, even if the layers are not optimally coordinated.

Layered Intrusion Detection Intrusion detection was once viewed as the most promising of large-scale security techniques. Even the provocative and hopeful name “intrusion detection” suggests a powerful technology that can be inserted into an environment to alert security teams when an intrusion is imminent. While this goal has not been fully met in practice, intrusion detection does provide a useful means for detecting indicators of potentially harmful behavior. These indi- cators are sometimes used for early warning, but more often are used to correlate with other types of available information during an incident.

Access Access

AccessAccess

Trans Trans

Crypt

E-mail E-mail Ecom Ecom

EcomEcom

Layer

Enterprise Perimeter

Layer

Layer

LayerLayer

Layer

Layer

External User

External User

Mainframe

Commerce

Server

Partner

Gateway

Partner

Gateway

Laptop

Internal User

Internal UserExternal User

Figure 6.9 Multiple layers of encryption.

Chapter 6 DEPTH 125

Because intrusion detection is typically performed offl ine, it lends itself to multiple layers of monitoring. Obviously, if the intrusion detection includes an active response—which is referred to collectively as intrusion prevention —the layered arrangement could be more complex, but for now let’s analyze strategies for passive, offl ine monitoring of attack. Most organiza- tions accomplish this task using commercial systems that include three components: monitors that are placed in strategic locations to collect data, transmission systems that move alarm informa- tion to a central location, and a master monitoring function that processes incoming data and provides some sort of correlated summary, usually in the form of an alarm to a console. When this type of intrusion detection system is in place in an enterprise, it can be viewed as an explicit layer of protection. In fact, many auditors will accept intrusion detection as a complementary con- trol when some other protection displays weaknesses.

One can conceptualize an alternate layer of intrusion detec- tion being put in place at a broader level, perhaps coordinated by some government or industry group. The components of the system would be the same, but differences from the enterprise would include diverse monitor placement, different signatures of attack, and a broader base on which to perform correlation of data. An issue with this alternative layer is that the protection would likely involve network paths that are largely separate from those in specifi c enterprise settings. For example, an intrusion aimed at some government agency would not be detected by the intrusion detection system located within a separate enterprise. There are, however, three specifi c opportunities for different intrusion detection systems to provide layered protection: ● In-band detection —If two intrusion detection systems both

have monitoring access to the same attack stream, or a related one, then they might both have the opportunity to detect the condition. Thus, if one system fails, it is possible that another might not. This is the essence of defense in depth, but it only works if the response processes for each detection system are coordinated.

● Out-of-band correlation —During an incident, the operators of an intrusion detection system might benefi t from information that might become available from other operators. This can be intelligence about sources, methods, or techniques being used by attackers. It is usually best used if made available in real time.

● Signature sharing —A special case of the above correlation involves sharing of specifi c attack signatures by one opera- tor that can be keyed into the systems being run by other

Intrusion detection with data security is similar to physical security intrusion detection: monitoring, an alarm system, and a central console.

126 Chapter 6 DEPTH

operators. Military organizations, for example, sometimes develop signatures that could be shared with industrial groups to improve their security. In each of these cases, diverse intrusion detection systems can

be viewed as providing a defense in depth for target assets. The result is a potentially coordinated series of intrusion detection layers that will help protect national infrastructure. This coor- dination usually requires sharing between different monitoring and analysis centers; that is, if one intrusion detection system notices an attack such as a botnet, then it might share this infor- mation with another system that might not have detected the condition (see Figure 6.10 ).

This idea of coordinated intrusion detection systems is cer- tainly not new; for example, government cyber security commis- sions and groups have advocated the notion of signature sharing between government and industry for years. For whatever rea- son, however, such coordination has rarely occurred, but for national infrastructure protection to reach its full potential such cooperation must be encouraged and rewarded.

National Program of Depth Creating a coordinated program of defense in depth using mul- tiple layers of security for national infrastructure can only be

Asset A

Monitoring Probe

Detects Botnet

Not Detect Botnet

Monitoring Probe

Alarm Feed

Intrusion

Detection

System B

Intrusion

Detection

System A

Botnet

Asset B

Internet

Private Network

Private

Network

A Shares

Detection

Info with B

Figure 6.10 Sharing intrusion detection information between systems.

A certain amount of information sharing between government agencies may serve to increase intrusion detection effectiveness.

Chapter 6 DEPTH 127

ensured via careful architectural analysis of all assets and pro- tection systems. The architectural analysis should result in a mapping, perhaps represented as a matrix, where each critical national asset is shown to be protected by certain multiple lay- ers of security. For each layer, subjective determination of its effectiveness is also required. Once this is done, simple calcula- tions can be performed to determine the diffi culty of penetra- tion through the various layers. This task is easier than it sounds; some of the more practical considerations that arise in such an exercise include the following: ● Identifying assets —This is a required step for several of our

recommended national infrastructure protection principles, including, for example, deception. It is particularly important for defense in depth, because the analysis of depth effective- ness can only be measured from the specifi cally identifi ed assets.

● Subjective estimations —The challenges inherent in this step were explained in detail above; certainly, in practice, cer- tain conventions could arise that would help security experts arrive at common estimations of effectiveness. In the 1980s, the U.S. Department of Defense created a set of criteria (infor- mally called the Orange Book) for measuring the effectiveness of security in systems. Perhaps some elements of this criteria approach could be introduced to provide assistance in subjec- tive estimations of the effectiveness of a layer.

● Obtaining proprietary information —If a company or agency has some defense in place (or, more importantly, per- haps some defense that may be missing) for some essential national service, then obtaining this information for broad analysis may be diffi cult. The goal would be to demonstrate value for organizations sharing detailed information, even if it is bad news.

● Identifying all possible access paths —Perhaps the toughest part of any cyber security exercise involves trying to deter- mine means for accessing some target. If this is not done properly, then the defense in depth strategy will fall apart, so this important step requires special consideration. These considerations can introduce signifi cant challenges in

practice. It does not help that most existing security teams, even in large-scale settings, rarely go through a local exercise of iden- tifying defense in depth conditions. As a result, most national infrastructure protection teams would be working this exercise for the fi rst time in the context of a national program.

Reviewing systems and strategies to identify existing layers of protection will create a “map” of the current depth of defensive protection.

This page intentionally left blank

129 Cyber Attacks. DOI: © Elsevier Inc. All rights reserved.

10.1016/B978-0-12-384917-5.00007-X 2011

DISCRETION The British spook said it on the way to the pub—a seemingly random confession that stood out in contrast to the polite evasions that were Ellis’s standard form of reply. Public key cryptography? “You did a lot more with it than we did,” he said .

Steven Levy 1

A belief found occasionally in the hacking community is that all information should be free and that anyone trying to suppress information fl ow is evil. The problem with this view is that it sug- gests that sensitive personal data should be exposed to the world. As such, this extreme view is commonly modifi ed by hackers as follows: All information associated with organizations , especially government, should be free, but private data about individuals should never be disclosed. From a logical perspective, this is a curious distinction, because large organizations are comprised of individuals, but in practice the view makes perfect sense. Hackers are almost universally concerned with protecting the rights of the individual; this view of information establishes a charter for the hacking community to make public anything that might degrade individual rights.

The result is a hacking culture where it is considered accept- able to expose proprietary information from government and industry in hacking magazines, on websites, at conferences, and across the Internet. Hackers often claim that reporting commer- cial and national vulnerabilities is a useful public service that prompts a more rapid security fi x. This certainly does not jus- tify leaking proprietary information that has nothing to do with vulnerabilities, but it does offer some value—albeit in an overly forceful manner. Regardless of the motivation, the fact is that proprietary information in companies and agencies will most defi nitely be widely exposed if discovered by hackers. Perhaps worse, terrorists and information warriors are also interested in

7

1 S. Levy, The open secret: public key cryptography—the breakthrough that revolutionized email and ecommerce—was fi rst discovered by American geeks. Right? Wrong, Wired , 7(4), 1999.

130 Chapter 7 DISCRETION

this information, but for more malicious purposes—and they will rarely make their intentions public in advance.

The result is that national infrastructure protection initia- tives must include means for protecting sensitive information from being leaked. The best approach is to avoid vulnerabilities in the fi rst place, as this information is the most urgently sought and valuable for public disclosure. More practically, however, national infrastructure includes a wide spectrum of information ranging from innocuous tidbits and gossip to critically sensitive data about infrastructure. This spectrum requires a customized protection program focused primarily on the most critical infor- mation. Any practical implementation should therefore com- bine mandatory, functional security controls with programs that dictate the use of discretion by individuals possessing important information. Mandatory controls can be implemented centrally, but discretion must be embedded in the local culture and fol- lowed in a distributed and individualized manner.

Trusted Computing Base The nearest the computer security community has come to rec- ognizing the importance of human discretion lies in an archi- tectural construct introduced in the 1980s called a trusted computing base (TCB). The defi nition of TCB is the totality of hardware, software, processes, and individuals whose correct operation and decision-making are considered essential to the overall security of the system. In an operating system, this would include the system fi les and processes in the underlying kernel. In an organization, this would include the system and security administrators who operate the critical protection systems. For an organization, it would also include all constructs for manag- ing and storing personally identifi able information (PII) about employees and customers. Candidates for exclusion from a TCB include anything whose malfunction or public disclosure would not create a signifi cant or cascading problem. In modern infra- structure, the TCB generally extends to the systems and networks of partner and supplier groups. This greatly complicates the pro- tection of TCB assets because it extends the TCB perimeter to an environment that is more diffi cult to control.

The primary goal of any program of discretion in national infrastructure protection should be to ensure that informa- tion about TCB functionality, operations, and processes is not exposed inappropriately to anyone not properly authorized and to avoid disclosure to anyone who does not possess a clear

Exposure of vulnerabilities can force a quick response, but that same exposure might lead adversaries directly to private data.

A modern TCB extends beyond a single organization, making protection all the more diffi cult.

Chapter 7 DISCRETION 131

business need for that information. Such a program will combine two distinct components: ● Mandatory controls —These are the functional and procedural

mechanisms that are put in place to ensure that information is protected from unauthorized access. Other than key adminis- trators within the TCB, no individual in any organization should be able to bypass mandatory controls, which will typically include fi rewalls, intrusion detection systems, and honey pots.

● Discretionary policy —These are the rules, recommenda- tions, and guidelines that are put in place by an organization to protect its information, especially with respect to the TCB. The discretion here is generally driven by practical concerns; for example, no functional mechanism can control what peo- ple mention informally to colleagues or customers. The only way to ensure protection here is the discretionary guidance afforded by the local culture. This can certainly be comple- mented with severe punishments if someone clearly violates the spirit of protection for TCB-related information. As one might expect, the TCB is easiest to protect if its size

and complexity are minimized. Having fewer people that must be trusted to support security, for example, is better than having to trust many different people and groups. Similarly, the fewer the systems one must trust in some base, and the less complex these systems are, the better off an organization will be from a security perspective. So, the minimization of a TCB is an excellent goal, albeit one that is often ignored in practice. Security practice has all too often involved the introduction of some new security system that is large and complex and requires full trust (see Figure 7.1 ).

Trusted

Computing

Base

Trusted

Computing

Base

Small Base of

Less Critical

Functions

(Less Desirable)

Large Base Requiring

Protection and Trust

(Less Desirable)

Smaller Base Requiring

Protection and Trust

(More Desirable)

Large Base of

Less Critical

Functions

(More Desirable)

Figure 7.1 Size comparison issues in a trusted computing base.

A smaller, less complex TCB is much easier to protect.

132 Chapter 7 DISCRETION

A major consideration in the protection of national infra- structure thus becomes how to manage, promote, and ensure proper human discretion around critical information related to TCB assets. This requires that policies, procedures, and even functional controls be put in place to assist in exercising such discretion. The idea is that, before any TCB-related informa- tion is disclosed that could have an impact on the security of some national asset, the following types of questions must be considered: ● Assistance —Could this information assist an adversary in

attacking some aspect of national infrastructure? For example, if terrorists or country-sponsored information warriors had this information, could they mount a malicious campaign against services such as emergency 911?

● Fixes —Does disclosure of this information assist in identifying a timelier or more effective security fi x? For example, will this disclosure provide someone with information that can reduce the time required to fi x the problem?

● Limits —Can the information disclosure be limited to those in a position to design a security fi x? More specifi cally, can the disclosure be done quietly and in private to a targeted group such as the vendor or service provider that can directly solve the problem?

● Legality —Is disclosure of this information a legal or contrac- tual requirement in the local environment? Or, is this disclo- sure being done for some other reason—perhaps personal gain or pent-up anger with some organization for moving too slowly?

● Damage —Is any individual or group harmed or damaged by protection and nondisclosure of this information?

● Need —Do others need this information to protect their own systems or infrastructure? As suggested, proper human discretion in the interpretation

of these questions, along with subsequent decision-making, is critical to protecting national assets. In many cases, government organizations will demand information related to some national infrastructure component or service, especially if the information relates to some trusted computing base. This is fi ne, as long as the purpose of sharing is reasonable and focused on improving the situation. When such information is demanded by a govern- ment group for unspecifi ed purposes (or, at worst, for the pur- pose of power or gossip), then such sharing is not recommended.

In any event, regardless of the security process, architectures, and systems put in place to protect assets, humans will remain a critical link in the chain. In fact, in many environments, they

Asking the right questions can help determine the impact of TCB security- related disclosures.

Before sharing critical information, consider who is requesting it and what the purpose is behind their request.

Chapter 7 DISCRETION 133

may be the weakest link. This is why the exercising of discretion in sharing information is such an important principle.

Security Through Obscurity A barrier to proper discretion is the much maligned and poorly understood notion of security through obscurity . Ask any security expert what they think of this concept, and you will receive a reli- gious argument, especially from cryptographers, that deliberately hiding information to ensure security will not work. Their claim is that anyone trying to hide design, implementation, or opera- tional detail is probably just trying to conceal fl aws. Furthermore, all information presumably fi nds its way public, they will argue, and any dependencies on suppression will eventually topple. The most objectionable applications of security through obscurity can be described in the following two scenarios: ● Long-term hiding of vulnerabilities —This involves the opera-

tors of a system concealing the existence of some exploitable fl aw as their primary, long-term means for securing the sys- tem, as opposed to the more desirable approach in which the vulnerability would be removed.

● Long-term suppression of information —This involves the operators of a target system deliberately suppressing general information about a system to make things more diffi cult for adversaries, hackers, and third parties to discover potential fl aws in a system. In each of these scenarios, the primary control involves hid-

ing information. Most would agree that this is not a reliable long- term method, because suppressed information has a tendency to eventually become public. The situation can be depicted as a knowledge time line, where zero information is initially made public about some system. With time, a gradual increase will occur in available public knowledge. If this increase reaches the point where suffi cient information is available to mount an exploit, then the security through obscurity scheme has failed. Obviously, disruptive events such as hacker announcements can create abrupt increases in knowledge (see Figure 7.2 ).

Although security through obscurity is not recommended for long-term protection as a primary control, it remains an excel- lent complementary control in many cases, as well as being an essential requirement in the short term for many types of security problems in infrastructure. For example, there are no compelling reasons for information about some organization’s security architecture to be made public. As long as the security

There are many opponents of security through obscurity as a meaningful protection strategy.

134 Chapter 7 DISCRETION

design receives expert local treatment, it is best left not publi- cized. Certainly, no one should recommend this as a primary control, and it should not be used to hide fl aws, but such discre- tion raises the bar against adversaries and might be the differ- ence between an attack that succeeds and one that fails.

Correspondingly, when some exploitable fl aw is discovered locally that requires immediate attention, the worst thing that can happen is for that information to be shared broadly. When this occurs, perhaps as a result of a posting to the Internet, the local response becomes distorted by concerns related to public relations, imminent threat, and legal concerns. Engineering solu- tions would be much improved if the fl aw can be analyzed care- fully and embedded into proper development and operations lifecycles. In addition, suppose that the steady state for some sys- tem is that suffi cient security exists to ensure proper operation, and any vulnerability that might exist is suffi ciently obscure as to make the technology reasonably dependable. If a severe vulner- ability is then found, the result is that the new steady state could jump to an unacceptably high risk state, and the integrity and dependability of the operation could be in jeopardy. This is sim- ply not acceptable, even for short periods of time, for essential national services.

The familiar argument that hackers often make here is that by exposing the vulnerability, a fi x is rushed into place. In addition, when the fi x is embedded into the original system, the integrity of that system has, by defi nition, been increased, simply because an existing fl aw has been removed. This is a powerful argument and is in fact a correct one. The problem is that for essential ser- vices, the vulnerability period—during which risk grows higher than some tolerable threshold—must be avoided. Cold logic generally goes out the window when a service must be in place

Security through obscurity should not be a primary protective strategy but can certainly be part of a defense package.

Essential national services cannot afford to be in a high risk state, even for a short period of time.

Attack Threshold

System Inception

Gradual

Increase

Security Through

Obscurity Fails Here

Sufficient Knowledge

Available to Mount Attacks

System is

VulnerableAvailable

Public

Knowledge

High

Low Time

Figure 7.2 Knowledge lifecycle for security through obscurity.

Chapter 7 DISCRETION 135

to ensure that a heart attack victim receives aid, or that tenants in an inner city receive electricity and heat, or that operators of a nuclear power plant can avoid dangerous emergency situations that could create serious health disasters (see Figure 7.3 ).

Regardless of the specifi c steady-state attack intensities and acceptable thresholds, the requirement is that the individuals charged with protecting vulnerability information must exercise proper discretion to ensure a level of obscurity for their systems. Without such discretion and obscurity, the chances are great that attack intensities can exceed desired levels, thus leading to seri- ous problems. In general, the practice should be to avoid public disclosure of vulnerabilities until a responsible fi x has been put in place. This suggests that disclosure of vulnerability information must be minimized and confi ned to those in a position to design and embed a proper solution.

Information Sharing Sensitive information can be exposed in different ways, includ- ing deliberate leaks, stray comments, document theft, and hacker disclosure. Each of these occurrences can be jolting for a security team, and their potential creates a general feeling of unease, espe- cially in national infrastructure settings. An additional path for the exposure of sensitive information involves willful information sharing with some controlled, authoritative group. While this is a predictable event, and the recipients are usually delighted with the information, the group doing the sharing is rarely pleased with the overall process.

Fixes Put

in Place

Increase in

Attack Intensity

Time

Threshold 1

Attack

Intensity

Threshold 2

Steady State

Vulnerability Information

Disclosed New Steady State

Security

Progress

Figure 7.3 Vulnerability disclosure lifecycle.

Information sharing may be inadvertent (stray comments), secretive (document theft), or willful (federal regulations or audits).

136 Chapter 7 DISCRETION

Government agencies are the most aggressive in promoting information sharing. Obviously, where legal requirements dictate reporting of data, there is no reason for debate. Law enforcement groups and federal regulators, for example, regularly demand information, but this is done under extremely controlled condi- tions and rarely, if ever, results in vulnerability-related data being disclosed to an adversary. For cyber security, however, govern- ment agencies request that industry share sensitive information for the following reasons: ● Government assistance to industry —In theory, attack signa-

tures and related security data could be provided by govern- ment to industry, as long as government is fully aware of the vulnerabilities that might reside in commercial infrastruc- ture. This requires information sharing from companies to government.

● Government situational awareness —For government to prop- erly assess cyber security risk at the national level, informa- tion sharing from industry is required, as such a large portion of national infrastructure resides in industry.

● Politics —Government groups are political by nature, and sensitive information provided by industry serves as a type of “power currency” that is used to push political objectives within government. This is rarely stated, but no government offi cial would deny its validity. In practice, information sharing between industry and gov-

ernment tends to provide spotty results for both parties. The idea of government providing direct cyber security assistance to industry, for example, is mostly theoretical. Valid scenarios can easily be imagined, especially for attack signatures that might be known by a military or intelligence group, but the practical real- ization of this is rarely seen. Similarly, the idea of government using shared information to form an aggregate view of national cyber security risk sounds great, but has never been done—at least in any public way. In contrast, the political objective has been the primary driver for most information sharing initiatives, which helps explain the enthusiasm that remains in government for this activity. This is a shame, because of all the motivations this one is the least important to the operator sharing data. In fact, an inverse relationship seems to exist between the respec- tive measures of value to the sharing and receiving parties (see Figure 7.4 ).

The relationship illustrated in Figure 7.4 shows that whereas government primarily seeks political power with informa- tion, industry cares the least about this; correspondingly, where industry would benefi t most from government assistance, this

Government and industry are not mutually invested in information sharing for the same reason.

Chapter 7 DISCRETION 137

is an area where government is in the weakest position to help. Both government and industry would agree that it is moderately important that government maintain situation awareness of vul- nerabilities, but neither would list this as their primary objec- tive. It is this inverse relationship that helps one understand why information sharing initiatives have rarely worked. It also goes without saying that any cases where information has been shared with government and is then sloppily handled, perhaps even leaked to the press, just makes matters worse.

The recommendation here is that any energy available for expenditure in this area should focus on fl attening the two curves somewhat. Government should be less focused on politics, and industry should be less concerned with getting something in return for sharing. The end result is that sharing objectives will nat- urally converge to an agreed-upon situational awareness objective, which is important but certainly not so important as to warrant all the attention this issue brings to the cyber security discussion.

Information Reconnaissance Reconnaissance activity performed by an adversary is another means by which sensitive information can be exposed. This is

High

Medium

Low

Most Important

Least Important

Industry

Industry

Government

Industry

Value to

Respective

Party

Government

Government

Government

Assistance

to Industry

Government

Situational

Awareness

Government

Politics

Figure 7.4 Inverse value of information sharing for government and industry.

Certainly, poor handling of sensitive or private information lessens industry’s trust in government when sharing information on vulnerabilities.

138 Chapter 7 DISCRETION

important to recognize because attacks on national infrastruc- ture will always include some form of reconnaissance. It can be done at arm’s length using remote access over the Internet; it can be done using compromised or planted insiders with access to critical local data; it can be done using social engineering tech- niques; it can be done via deliberate theft, remote hacking, or quiet sabotage, and so on. Regardless of the technique or vantage point, reconnaissance is used to plan and prepare for attacks on infrastructure.

Adversarial attacks are rarely spontaneous; some amount of planning goes into each attack.

This three-stage model suggests that at each layer of informa- tion collection by an adversary the opportunity exists for security engineers to introduce information obscurity. The purpose of the

v

Reconnaissance Planning Levels Three levels of reconnaissance are followed in most instances of cyber attack planning: 1. The fi rst level involves broad, wide-reaching collection from a variety of possible sources. This can include web

searches, personal contact, and business interaction. 2. The second level of reconnaissance involves targeted collection, often involving automation to provide assistance.

Network scanning is the most common functional support for this second level of reconnaissance. 3. The third level involves direct access to the target. A successful hacking break-in to some system, followed by the

collection of targeted data, is an example. One possible scenario that strings the three phases together might involve broad reconnaissance, where something

found on the Internet would prompt more targeted reconnaissance, which would involve the scanning activity to fi nd something that could then be used in the third phase for direct access to a target (see Figure 7.5 ).

Access

Stage 1:

Broad

Stage 2:

Targeted

Stage 3:

Direct

Adversary

Target

Personal

Internet

Business

Media

All-Source

Tools

Scanning

Monitoring

Figure 7.5 Three stages of reconnaissance for cyber security.

Chapter 7 DISCRETION 139

obscurity would be to try to prevent a given type of information from being disclosed through the reconnaissance activity. The specifi c types of security-related national infrastructure informa- tion that should be obscured are as follows: ● Attributes —This is information about seemingly nonsecurity-

related features, functions, and characteristics of the com- puting, networking, applications, and software associated with national infrastructure. It could include equipment type, vendor name, size and capacity, and supported functional- ity. Adversaries often covet this type of information because it helps provide context for a given attack.

● Protections —This is information related to the security pro- tection of a national asset. It can range from technical confi g- uration or setup data about systems to nontechnical contact information for key security administrative staff. The value of this information should be obvious; when obtained, it pro- vides a roadmap for the type of countermeasures an adversary must consider in planning a successful attack.

● Vulnerabilities —This is information related to exploitable holes in national infrastructure. It can range from well-known bugs in commercial operating systems to severe vulnerabili- ties in some national asset. Adversaries will seek this type of information from any possible source. This can include the national infrastructure management team, relevant technology or service vendors, or even the general public. The hacking community is also a rich source of vulnerability information, especially as it relates to national assets. Of these three attributes, vulnerability information tends to

dominate most discussions about the types of information an adversary might desire. Go to the technical section of any book- store, for example, and you can fi nd thick tomes chronicling the exploitable holes in virtually any technology you can imagine. This gives you some idea of how diffi cult it really is to obscure vulnerability information. This should not discourage the opera- tors of national infrastructure; when serious problems are dis- covered that can degrade essential services, the only responsible action is to work toward some sort of fi x with the responsible parties before the information is shared to the rest of the world, which obviously includes the adversary.

Obscurity Layers One conceptual approach to managing discretion in protect- ing national infrastructure information involves obscurity layers .

Although truly obscuring vulnerability information is likely an impossibility, security managers should strive for discretion and privacy on this point whenever possible.

140 Chapter 7 DISCRETION

These layers are intended to reduce the likelihood that critical information is disclosed to unauthorized individuals. Techniques for introducing layers of obscurity range from common-sense human discretion to more structured processes for controlling information fl ow. If designed properly, obscurity layers should make unauthorized disclosure possible only if multiple, diverse obscurity techniques are somehow bypassed. In this sense, obscurity layers can be viewed as an instance of defense in depth.

In the best case, obscurity layers provide diverse, complemen- tary, and effi cient coverage around national asset information. That is, an asset might fi rst be protected by an obscurity layer that includes data markings to remind individuals of their obli- gation to use discretion. A second obscurity layer might involve some mandate that no technical information about local net- works, software, or computing platforms be shared beyond the team of trusted administrators. A third layer of obscurity might then involve the mandate that, if information does somehow leak out about critical infrastructure, the organization will never com- ment publicly on any aspect of the leak.

These three example layers are complementary and provide guidance to individuals on how to exercise discretion in what information to share and what information to suppress. As such, they can be viewed as an effective discretionary tool for protect- ing assets (see Figure 7.6 ).

Layering the methods of obscurity and discretion adds depth to a defensive security program.

Asset

Data Markings

Sharing Policy

Leakage Policy

Information Leaks

Through Only

a Single Layer

Information Leak

Not Countered

by Any Layer

First Obscurity Layer

Second Obscurity Layer

Third Obscurity Layer

Figure 7.6 Obscurity layers to protect asset information.

Chapter 7 DISCRETION 141

Leaks through obscurity layers might make their way through each layer or might be countered by one or more layers. For example, in Figure 7.6 , an information leak that would not be countered by any layer might involve someone exercising poor discretion by ignoring data markings (through the fi rst layer), violating information sharing policies (through the second layer), and being ignorant of policies for disclosure after an incident (through the third layer). This demonstrates the human element in the use of discretion to protect critical infrastructure informa- tion. Additional examples of obscurity layers in national infra- structure protection include the following: ● Public speaking —A policy might be in place that would delib-

erately prevent anyone with responsibility for national infra- structure from speaking publicly without explicit public relations preparation and planning.

● Approved external site —A ubiquitous mechanism, such as a website, might be in place to constantly and consistently pro- vide organizationally approved information about infrastruc- ture that might be desired by external entities.

● Search for leakage —Search engines might be used via ethi- cal hacking techniques to determine the degree and scope of inappropriate information that might already be located on websites or in a cache. This can be complemented by modern data leakage protection (DLP) tools. As suggested above, the purpose of these discretionary con-

trols is not to suppress information for the purposes of hid- ing incompetence or inappropriate behavior. The purpose is to responsibly control the type of information made available to a malicious adversary.

Organizational Compartments An information protection technique used successfully by the U.S. federal government, especially in the military and intelli- gence communities, involves the compartmentalization of indi- viduals and information. These compartments can be thought of as groups for which some set of policy rules uniformly apply. Typically, individuals are put through a background check to determine their level of trustworthiness. They are then given a designated security clearance . Information is similarly put through an analysis to determine its level of criticality; it is then given a designated security classifi cation .

The specifi cs of how clearances and classifi cations work are beyond the scope of this book, but a key notion is that each

Even with layered obscurity, asset information may leak through to an adversary.

Government clearance levels and information classifi cation are techniques used to protect data by limiting accessibility.

142 Chapter 7 DISCRETION

combines some notion of hierarchical level (e.g., Top Secret, Secret, Confi dential, Unclassifi ed) with a corresponding notion of “need to know” categories (e.g., Navy, Air Force). The cross-prod- uct of some set of classifi ed information with the corresponding individuals cleared to access that information is called a compart- ment . Policy rules for accessing data, such as classifi ed documents, from a compartment can then be implemented (see Figure 7.7 ).

The examples in Figure 7.7 show an individual cleared to Top Secret in categories Navy and Air Force being successful in read- ing a document that is classifi ed to the same level and categories. In addition, an individual cleared to Top Secret in category Navy is successful reading a document cleared to the same level and categories. On the other hand, an individual cleared to Top Secret in category Air Force is denied access to a document whose cat- egory is only Navy. This type of approach is especially powerful in an actual government setting, because information leaks can be interpreted as violations of federal law. In the most intense case, such violations could be interpreted as espionage, with all the associated punishment that comes with such action. The result is a mature environment in most government settings for reduc- ing the chances that national security-related information will be leaked.

Clearly, the protection of national services is not just the responsibility of government. Thus, industry needs a correspond- ing approach to policy-based access control. The good news is that translation of government compartments to a corporate setting is relatively straightforward. Clearance and classifi cation levels can be mapped to company-defi ned organizational levels such as “supervisor” and “senior manager.” Categories can be mapped to specifi c projects in a company. Thus, a compartment in some company might correspond to the senior manager level, within some project A and project B (see Figure 7.8 ).

Certain secure government data can only be accessed by a few top-level offi cials.

(Top Secret (Navy, Air Force))

(Top Secret (Navy))

(Top Secret (Air Force))

(Top Secret (Navy, Air Force))

(Top Secret (Navy))

Read

Individual (Clearance) Document (Classification)

Read

Deny

Read

"Need to Know"

Category X

Figure 7.7 Using clearances and classifi cations to control information disclosure.

Chapter 7 DISCRETION 143

The bottom line with compartmentalization is that it should be used to help defi ne boundaries around which information can or cannot be accessed. This helps guide decisions that require human discretion. Too often, in computer security settings today, the underlying goal of many projects and in the management of many critical systems is to avoid the use of information boundar- ies, often in the interest of openness and sharing. These concepts are valuable for many types of standards, information, data, soft- ware, and services, but unfortunately openness and sharing are not always consistent with protecting security-related informa- tion about national infrastructure.

National Discretion Program To implement a national program of information obscurity and discretion, several management and security engineering tasks will be required: ● TCB defi nition —Although it could be diffi cult to do so, effort

should be directed by suitable national authorities toward try- ing to defi ne a nationwide trusted computing base. This will require coordination between government and industry, but the resulting construct will help direct security management decisions.

● Reduced emphasis on information sharing —Government must immediately reduce its emphasis on demanding that information be shared by industry. Any information sharing initiatives that do maintain such an emphasis should focus only on providing government with situation status.

● Coexistence with hacking community —The national infra- structure community in government and industry would benefi t by creating an improved spirit of cooperation with

Private companies can mirror government clearance levels by classifying data and limiting access.

(Senior Manager (Projects A, B))

(Manager (Project B))

(Manager (Project A))

(Senior Manager (Projects A, B))

(Manager (Project B))

Read

Individual (Level/Authority) Document Marking

Read

Deny

Read

"Need to Know"

Category

X

Figure 7.8 Example commercial mapping of clearances and classifi cations.

144 Chapter 7 DISCRETION

the hacking industry. This could come in the form of fi nan- cial support from government for hacking groups and forums, or it could be more explicit in terms of actual tasking on real programs.

● Obscurity layered model —A national obscurity layer should also be put in place to guide decisions about human discre- tion in protecting sensitive national infrastructure-related information.

● Commercial information protection models —Industry should be provided with incentives and rewards for demonstrating some degree of embedded policy-based access control similar to the military model. Certainly, to increase the chances that these tasks are success-

ful, a culture of human discretion around sensitive information must be created. Senior managers must reinforce this culture by not exercising their right to bypass discretionary controls; for example, all documents, even those created by senior managers, should be marked appropriately. Similarly, if violations of basic information discretion do occur, the consequences should be similarly applied, regardless of organizational position or level.

145 Cyber Attacks. DOI: © Elsevier Inc. All rights reserved.

10.1016/B978-0-12-384917-5.00008-1 2011

COLLECTION It is important to have a fairly clear understanding of what you are looking for and what events you are interested in, because you cannot collect or detect everything .

Stephen Northcutt 1

A basic tenet of computer security is that diligent and ongoing observation of computing and networking behavior can high- light malicious activity. This works best when the observer has a good frame of reference for what constitutes normal behavior. Algorithms and human judgment can then be used to compare profi les with observations to identify activity that might be sus- picious. Follow-up analysis can then be used to partition sus- picious activity into benign and malicious categories. All this processing and analysis can only be done in the context of an existing program of data collection .

At the national level, security-relevant data must fi rst be col- lected at the local or regional level by individual asset manag- ers and a subset then selected for broader aggregation into a national collection system. In some cases, local and regional col- lection can be directly connected to national programs. Larger- scale collection points on wide-area networks, perhaps run by carriers or government agencies, can also be embedded into the collection scheme and combined with local, regional, and aggre- gated data (see Figure 8.1 ).

Such a national collection process does not exist today in any organized manner. To build one will require considerable resolve. From a technical perspective, each collection point requires that decisions be made about which data is gathered, what methods will be used for collection, how it will be used, and how it will be protected. It is not reasonable for any organization to collect any sort of data without having specifi c answers to these simple questions. Improper collection of data, where no clear justifi ca- tion exists for its aggregation, could lead to serious legal, policy,

8

1 S. Northcutt, Network Intrusion Detection: An Analyst’s Handbook , New Riders Publishing, Berkeley, CA, 1999, p. 34.

Data collection should not be attempted until an organized plan is in place to analyze and protect the data.

146 Chapter 8 COLLECTION

or even operational problems for organizations charged with protecting some national asset.

As an illustration, many government groups have done a ter- rible job in the past protecting data once it has been aggregated. Several years ago, for example, sensitive information collected from chemical companies in the New York area was published by a government agency on its website. This information was then collected by reporters and reproduced as an article in a New York City newspaper, replete with a map showing which types of dan- gerous chemicals were present and their exact location, as well as noting the health and safety implications of these chemicals. This type of information is of great interest, obviously, to terror- ists. Dissemination of this information could also have a nega- tive impact on business operations and the reputations of these companies.

At both local and national levels, data collection decisions for national infrastructure should be based on the following three security goals: ● Preventing an attack —Will the data collected help stop a pres-

ent or future attack? This implies that the recipient of col- lected data must justify its role in stopping the attack. If the recipient manages some critical infrastructure component, such as a backbone network, that can be used to throttle or stop the attack, then the justifi cation is obvious. If, however, the recipient is a government agency, then the justifi cation might be more diffi cult.

National Level Data Collection Program

Wide-Area Collection

(Backbone, Shared Services)

Regional Collection

(Geographic Coverage)

Regional

Aggregation

Enterprise

Aggregation

Wide-Area

Aggregation

Local Collection

(Enterprise, Agency)

Figure 8.1 Local, regional, and national data collection with aggregation.

Chapter 8 COLLECTION 147

● Mitigating an attack —Will the data collected assist in the response to an ongoing attack? The implication here is that the recipient of data should be able to help interpret what is happening or should be able to direct resources toward a solu- tion. One of the most relevant questions to be answered about an ongoing attack, for example, is how widespread the attack might be. Collecting information from a broad distribution will help to answer this question.

● Analyzing an attack —Will the data collected assist in the forensic analysis of an attack after it has occurred? This goal is important but can be easily abused, because it could jus- tify collection of any sort of data available. Forensic analysts generally maintain that their task is made easier in the pres- ence of large volumes of data. Care must therefore be taken to ensure that inappropriate data collection does not occur simply because a forensic analyst might claim to need the information. These three requirements should direct the scope, coverage,

and degree of detail associated with a data collection program for every national infrastructure component. In fact, they provide a suitable template for determining exactly what sort of data should be collected and aggregated. At the local, regional, wide area, and national levels, data collection should only proceed if affi rmative answers to these questions can be made (see Figure 8.2 ).

The decision to not collect data might be among the most dif- fi cult for any organization, especially a government agency. One of the great axioms of government computer security has been that more data is always better, especially if a path exists to per- form such collection. The reality, however, is that improper data collection not only is unnecessary but could also actually weaken national infrastructure.

Initiate Data Collection

Mitigate

Present

Attack?

Analyze

Past

Attack?

Prevent

Future

Attack?

No

Yes Yes Yes

No No No Data

Collection

Required

Figure 8.2 Justifi cation-based decision analysis template for data collection.

Data collection must be justifi ed as to who is collecting the data and why.

Beware the “more is better” axiom regarding data collection; focus on quality, not quantity.

148 Chapter 8 COLLECTION

Collecting Network Data Perhaps the most useful type of data for collection in national infrastructure is network metadata . Also referred to as netfl ow , metadata provides many security-relevant details about net- work activity. In a Transmission Control Protocol (TCP)/Internet Protocol (IP) environment, metadata allows the security analyst to identify source address, destination address, source port, des- tination port, protocol, and various header fl ags in a given ses- sion. This information is security relevant because it provides a basis for analyzing activity. A nontechnical analogy would be that metadata is akin to the information that postal workers can see in the mail they process. The size, weight, color, texture, and addressing information on the envelopes and wrappers are apparent, whereas the contents are not.

The collection of metadata involves the placement of equip- ment or software into the target network for the purpose of pro- ducing metadata records. These records are collected and stored for analysis. Obviously, to make this collection feasible, certain functional considerations must be made. There must be legal jus- tifi cation for collecting the data, there must be suffi cient storage capacity for maintaining collecting data, and there must be ana- lysts with proper capability to make effective interpretations about the data. Perhaps the most important consideration, however, is whether the collection functionality is suffi ciently powerful to keep up with the target network bandwidth capacity (see Figure 8.3 ).

One issue with large-scale versions of this collection approach is that many metadata collection systems were deployed in car- rier backbones during the early part of the century, with the intention of pulling security data from 10-Gbps backbones.

Local Storage

and Reduction

Collection Equipment

(Hardware and Software)

Transport from other

Collection Points

Processing

and Analysis

Storage

Transport Target

Network

Figure 8.3 Generic data collection schematic.

Metadata is information about the data, not what the data is about.

Chapter 8 COLLECTION 149

The challenge is that carrier backbones have begun to grow to 40- and even 100-Gbps capacities. If the collection systems are not increased at a commensurate rate, then the ability to collect metadata could decrease by as much as a factor of ten.

One solution many security analysts use to deal with increas- ing network capacity is to sample the data. This technique involves grabbing some of the data at predetermined intervals so the inbound fl ow matches the ability to process. Sampled data is generally acceptable for broad analysis of network activity, but it is not as effective for detailed forensics as unsampled metadata. In an unsampled environment, analysts can often detect tiny anomalies in massive amounts of data. This design consideration affects the overall collection process.

As an example, several years ago unsampled metadata on an IP backbone allowed analysts in a global carrier environment to detect that a small number of packets of an unusual proto- col type were beginning to show up. Packets of this type had not been seen on the backbone for years, so this was clearly an anomaly to be investigated. Suspicious packets from this unusual event were collected and observed for four days, until a key equipment vendor contacted the carrier to report a serious secu- rity fl aw in their operating system software. Interestingly, exploits of this vulnerability involved traffi c being sent over precisely the protocol type being observed. The collection point thus detected network activity evidence of a security issue that had not even been publicly reported (see Figure 8.4 ).

Thousands of

Packets Detected

Vendor Notification of

Vulnerability on this Protocol

Zero Packets

Detected

# of Packets

of Unusual

Protocol Type

Day

1,000

2,000

3,000

4,000

5,000

n n+4 n+5n+3n+2n+1 n+6 n+7

Figure 8.4 Collection detects evidence of vulnerability in advance of notifi cation.

Data collection systems need to keep pace with growth of carrier backbones.

Sampling data is less time consuming, yet unsampled data may reveal more vulnerabilities in the system.

150 Chapter 8 COLLECTION

The key observation here is that, under normal conditions, no instances of this type of protocol packet were observed on the carrier backbone. When suddenly the unusual protocol type essentially came alive, there was no easy way to determine why this was the case other than that some sort of anomaly was tak- ing place. When the vendor reported the problem on this proto- col, analysts were able to put together this information to solve the riddle of why this anomaly had occurred. This illustrates the importance of integrating all-source information into any data collection environment. National infrastructure protection must include this type of collection and associated analysis to be fully effective in protecting essential services.

Collecting System Data National infrastructure protection initiatives have not tradition- ally included provision for collecting data from mainframes, serv- ers, and PCs. The justifi cation for such omission is usually based on the scaling and sizing issues inherent in the massive amount of data that would have to be processed from these computers, along with the common view that such systems probably do not provide much security-relevant data. An additional consideration is the potential for privacy abuses, an issue that the citizens of most nations have come to recognize as being important to their lives. As a result, no serious national infrastructure protection initiative to date has included a proposal or plan for this type of functionality.

Regarding scaling and sizing issues, the computing infrastruc- ture required for collection of data from every mainframe, server, and PC deemed part of national infrastructure services would certainly be complex. That said, computing historians know that it is not unprecedented for the complex requirements of one gen- eration to become routine features in another. Furthermore, the tactical approach of identifying a workable subset of the relevant computers in a nation is possible. For example, the mainframes, servers, and PCs running in companies and agencies charged with national infrastructure could be targeted for collection, and this is a tractably sized challenge.

On the issue of whether mainframes, servers, and PCs provide suitable security-relevant information for national infrastructure protection, many critical incidents are best identifi ed through collection of data at this level. Operating system logs, mainframe event summaries, and PC history records provide excellent evi- dence that malicious activity might be ongoing. Engineering metrics such as memory utilization or processor load can also

Analysis of unsampled metadata can reveal concerning data traffi c patterns that would otherwise go unnoticed.

We may not currently have the capacity to collect data from all relevant computers, but it is an important goal to try to reach.

Chapter 8 COLLECTION 151

provide valuable signals about security issues. For example, when a server shows increases in processor usage as a result of an attack, this condition is often easiest to identify using monitoring tools embedded in the operating system of the computer.

System monitoring is important to national infrastructure protection because it is often the only indicator that some secu- rity event is under way—even in the presence of fi rewalls, intru- sion detection systems, and other security tools. As a result, national infrastructure protection initiatives will have to include provision for the gathering and processing of data from main- frames, servers, and PCs. This data will have to be selected, collected, transmitted with suitable protection, stored in an envi- ronment properly sized for large amounts of data, and processed in real time. Four specifi c types of information that should be collected include those listed in the box below.

System monitoring provides an overview of activity that may reveal troubling patterns.

Top Four Data Collection Areas 1. Utilization —One of the most important metrics in determining whether an attack is ongoing is the utilization profi le

of servers in the local environment. National asset managers must identify which servers are relevant for monitoring and should instrument an associated program of data collection. This will require cooperation between government and industry, as well as the inclusion of appropriate functional requirements in infrastructure support contracts.

2. Usage —Patterns of usage on the mainframes, servers, and PCs in a given nation are important to establish for protection of infrastructure. If certain mainframes are never touched after hours, for example, then this will help to identify smaller attacks during unusual times. Detecting small, active usage events is often easier in a quiet environment than in a noisy environment; however, detecting usage drops is often easier in a noisy environment than in a quieter one.

3. Applications —Collecting data about the applications resident on system infrastructure provides useful hints about possible cyber attacks. A common metric is a “top ten” list of most commonly used applications. If the mix changes in some meaningful way, then this could signal an attack. Network gateway systems including proxies are excellent candidates for collecting this type of data for an enterprise. Carriers could provide this type of data in a wide area network or across a given region.

4. Outages —Information about outages is important for security, because events that are presumed to have been benign might actually be part of a cyber attack. It is not uncommon for system managers to ignore this possibility; hence, data collection around outages is important. As an example, root-cause analyses after serious outages should be viewed as important information for gathering and analysis.

Two techniques are useful at embedding system management data into cyber security infrastructure. First, an inventory process is required to identify the systems that are considered critical in

152 Chapter 8 COLLECTION

a given environment. This process might require engineering analysis across relevant government and industrial infrastructure to determine if a given system resides in the critical path of some national service. Alternatively, the decision might be made to try to collect information from every system that is available for col- lection. Second, for those systems deemed worthy of data collec- tion, a process of either instrumenting or reusing data collection facilities must be identifi ed. This could involve the use of operat- ing system audit trails or it could involve the installation of some sort of application-level logging program.

Regardless of the approach, data would fl ow from the tar- get computers of interest across some network medium to vari- ous aggregation points. Regional and enterprise networks would probably have to introduce an aggregation function for their organization before the data is shared externally. One would expect that network carriers could easily step into this role of pro- viding different types of aggregations; that is, customers of DSL and cable services could agree, under suitable incentives, to allow for collection of data related to the presence of malware, viruses, and other compromising software. Encryption could be used to help protect the confi dentiality of the data in transit and storage.

There would also have to be some sort of fi ltering or data reduction to focus the collection on specifi c systems of inter- est and to limit data to only that which is likely to be useful. For example, if a nation tried to collect security-related data from hundreds of thousands or millions of PCs every day, the resultant daily datafl ow would be measured in the multiple terabyte range. Commercial databases would probably be insuffi cient for stor- ing this volume, so customized databases would be required. The volume of collected data would ultimately be made available to a security processing and interpretive system that could be used for national infrastructure purposes.

Although more creative overall architectures could be imag- ined, such as peer-to-peer, the centralized collection approach would be more likely to be implemented in practice. It also lends itself quite well to the establishment and operation of a national security operations center (see Figure 8.5 ).

Readers might cringe at the idea of collecting data in this manner, especially from end-user PCs scattered across a nation, but this practice is more common than one might think. Every large enterprise and government agency, for example, routinely embeds integrity management software, such as tripwire func- tionality, into their mainframes and servers. Furthermore, almost every enterprise and agency uses software agents on PCs to col- lect relevant security and management data. Perhaps ironically,

Aggregation points would allow for regional collection of data.

Chapter 8 COLLECTION 153

botnet operators have also perfected the idea of collecting data from massive numbers of end-user computers for the pur- pose of attack. The idea that this general schema would be extended to benevolent national infrastructure protection seems straightforward.

The challenge is that this sort of scheme can be abused. Computer scientists lament software running with high privilege on their systems, and citizens resist the notion of an unknown monitor pulling data from their system to some unknown col- lection facility, possibly violating privacy principles. Both con- cerns are valid and need to be debated publicly. If an acceptable compromise is reached between government and its busi- nesses and citizenry, then the result can be incorporated into the design of an appropriate national system. At minimum, such a compromise would have to include demonstrable evidence that mainframes, servers, and PCs provide only harmless com- puter security-related information such as scan data, security state, and signature-based malware detection. Anything more penetrating that might allow, for example, remote access and execution from a centralized control station would probably be unacceptable, even though organizations do this routinely with their employee base.

Another possibility might be some sort of citizen-sponsored, citizen-run, grassroots data collection effort for PCs and servers,

National Level Collection Infrastructure

Aggregation Layer

Data Transport Layer

Enterprise

Mainframes

and ServersEnterprise PCsCommunity PCs

Carriers

Figure 8.5 Collecting data from mainframes, servers, and PCs.

A national data collection center may not differ much from current enterprise and agency data collection.

A national data collection program would have to be sensitive to citizens’ concerns for privacy.

154 Chapter 8 COLLECTION

where participants agree to provide security information to a massive distributed system of peers. Such a system would not perfectly match the geographic or political perimeter of a nation, and many citizens would refuse to participate based on prin- ciple. Few members, however, of massive peer-to-peer networks for music or video complain about the privacy implications of running such software, often questionable or illegal, on their local machine. They just enjoy getting free content. The idea that a similar construct could be used to help secure national infra- structure would require demonstrating some sort of benefi t to participants. This may not be possible, but the effort is worth- while from a security perspective because data collected from a massive deployment of computers across a given nation would provide a valuable and unmatched window into the security pos- ture of national infrastructure.

Security Information and Event Management The process of aggregating system data from multiple sources for the purposes of protection is referred to in the computer secu- rity community as security information and event management (SIEM). Today, SIEM tools can be purchased that allow collec- tion of a diverse set of technologies from different vendors. This typically includes fi rewalls, intrusion detection systems (IDS), servers, routers, and applications. Just about every commercial enterprise and government agency today includes some sort of SIEM deployment. One could easily imagine this functional- ity being extended to include collection feeds from mainframes, servers, and PCs (see Figure 8.6 ).

The SIEM system will include translation functions to take proprietary outputs, logs, and alarm streams from the differ- ent vendors into a common format. From this common collec- tion format, a set of common functions can thus be performed, including data storage, display, sharing, and analysis. National infrastructure protection must include rational means for inter- preting SIEM data from components, if only because many orga- nizations will already have a SIEM system in place for processing their locally collected data. This interpretation of SIEM data from multiple feeds will be complicated by the fact that most existing SIEM deployments in different companies, sectors, and govern- ment agencies are mutually compatible. A more critical prob- lem, however, is the reluctance among most security managers to instrument a real-time connection from their SIEM system to a national collection system. A comparable problem is that service

Citizens who see the benefi t of a national data collection system would likely be willing to participate voluntarily.

Security managers will be reluctant to link their SIEM system to a national collection system.

Chapter 8 COLLECTION 155

providers do not currently feed the output of their consumer cus- tomers’ data into a regional SIEM system.

In any event, the architecture for a national system of data collection using SIEM functionality is not hard to imagine. Functionally, each SIEM system could be set up to collect, fi lter, and process locally collected data for what would be considered nationally relevant data for sharing. This fi ltered data could then be sent encrypted over a network to an aggregation point, which would have its own SIEM functionality. Ultimately, SIEM func- tions would reside at the national level for processing data from regional and enterprise aggregation points. In this type of archi- tecture, local SIEM systems can be viewed as data sources, much as the fi rewalls, intrusion detection systems, and the like are viewed in a local SIEM environment (see Figure 8.7 ).

Unfortunately, most local infrastructure managers have not been comfortable with the architecture shown in Figure 8.7 for several reasons. First, there are obviously costs involved in setting up this sort of architecture, and generally these funds have not been made available by government groups. Second, it is possible that embedded SIEM functionality could introduce functional problems in the local environment. It can increase processor uti- lization on systems with embedded SIEM hooks, and it can clog up network environments, especially gateway choke points, with data that might emanate from the collection probes.

A much more critical problem with the idea of national SIEM deployment is that most enterprise and government agency

Storage Display Sharing Analysis

Firewall IDS Server Router Apps . . .

. . .

Common

Functions

Translation Foods

Data Collection

Figure 8.6 Generic SIEM architecture.

Local and regional SIEM systems would work as fi lters to feed only relevant data to a national collection point.

Will a national data collection system put an increased fi nancial burden on private agencies and enterprises?

156 Chapter 8 COLLECTION

security managers will never be comfortable with their sensitive security data leaving local enterprise premises. Certainly, a man- aged security service provider might be already accepting and processing security data in a remote location, but this is a virtual private arrangement between a business and its supplier. The data is not intended for analysis other than to directly benefi t the originating environment. Furthermore, a service level agreement generally dictates the terms of the engagement and can be termi- nated by the enterprise or agency at any time. No good solutions exist for national SIEM implementation, other than the gener- ally agreed-upon view that national collection leads to better national security, which in turn benefi ts everyone.

Large-Scale Trending The most fundamental processing technique used for data that is collected across national infrastructure involves the identifi ca- tion of trends . In many cases, trends in collected data are obvi- ous, as in simple aggregate volume increases, such as packets delivered on a network. In other cases, however, trends might not be so obvious. For instance, when the collection process or monitored systems are experiencing change, the trend identifi ca- tion might not be easy. Suppose, for example, that a monitored network is growing, but the collection system is not. The result is that critical data might be missed, which could be misleading.

There are still too many unanswered questions about the security of sensitive data leaving private enterprises.

Storage Display Sharing Analysis

SIEM 1 SIEM 2 SIEM 3 SIEM 4 SIEM n . . .

. . .

Common National

Functions

Local SIEM

Translation

SIEM

Foods

National Data Collection (National SIEM)

Figure 8.7 Generic national SIEM architecture.

Chapter 8 COLLECTION 157

Similarly, if a change is made to the underlying collection system, perhaps involving a new technology or vendor, then this could infl uence the trends presumably being observed.

At the simplest level, a trend involves some quantitative attri- bute going up (growth), going down (reduction), staying the same (leveling), or doing none of the above (unpredictability). When data jumps around, for example, it might not be easy to draw a conclusion; however, the fact that it is jumping around might itself be an important and useful conclusion. Perhaps the most common question infrastructure managers ask with respect to security is whether attacks are increasing, decreasing, or stay- ing the same with respect to some component in question. This question about attack trends is a favorite among CEOs and national legislators. It can only be answered accurately in the context of collected data.

As a concrete example, over a nine-month period from June 2006 to March 2007, a stable collection system embedded in a global service provider’s backbone detected an increase in behav- ior consistent with malicious bots. As was outlined in the fi rst chapter, a bot is a piece of software inserted into a target system, usually a broadband-connected PC, for malicious or question- able purposes. The bot might be used to attack some target, it might be used to send spam, or it might be used to steal personal information. The detection of bot behavior comes from collect- ing traffi c information for the purpose of identifying communi- cation between a number of end-user PCs and a smaller number of servers on the Internet.

By collecting evidence of bot behavior and rendering the results in a simple histogram, the growth of bots can be seen clearly, and local management decisions can be made accord- ingly (see Figure 8.8 ).

Most managers shown the growth trend in Figure 8.8 would conclude that bots represented an increasing threat during this time period; however, proper national infrastructure protection requires a more thorough analysis before any real conclusions are drawn. The following are some basic practical considerations that must be made by security analysts before the trend in any data collection chart can be trusted: ● Underlying collection —Amazingly, trend data such as that

shown in Figure 8.8 is often provided in the context of a collec- tion architecture that might be changing. For example, if a collec- tion system for bots is getting more accurate through algorithmic improvements or better coverage, then the observed growth in bots might simply refl ect a more effective use of detection tools.

Tracking trends may tell us whether adversarial attacks are increasing, decreasing, or staying the same.

Collected data must be analyzed to determine what it can accurately tell us about trends.

158 Chapter 8 COLLECTION

● Volunteered data —It is common for government organiza- tions to use data volunteered from commercial entities as the basis for drawing conclusions about trends. This can be dan- gerous, because weak or nonexistent controls are in place regarding how the information is collected and managed. It is also possible that data might be volunteered that is incorrect or tampered with for some malicious or mischievous purpose.

● Relevant coverage —The amount of coverage across the envi- ronment in which the data is collected will affect the validity of an observed trend. Suppose, for example, that a small orga- nization with an Internet connection uses that connection to draw conclusions about traffi c trends. This certainly would be a less attractive vantage point than a global Internet carrier making the same determination. These issues highlight the importance of national infrastruc-

ture managers taking a mature approach to the interpretation of collected data. This is especially important because trend infor- mation so often drives the allocation of critical resources and funding. At the national level, for example, experienced security experts can point to dozens of cases where some sort of trend is used to advance the case for the funding of an initiative. This often involves hype about the rise of some virus or worm.

The Confi cker worm, for example, reportedly included some sort of embedded attack that would occur on April 1, 2009. Confi cker

0.5M

1.0M

1.5M

2.0M

2.5M

3.0M

# Bots

07/06 08/06 09/06 10/06 11/06 12/06 01/07 02/07 03/07

Figure 8.8 Growth trend in botnet behavior over 9-month period (2006–2007).

Trends must be interpreted carefully before they are used to justify changes in funding levels.

Chapter 8 COLLECTION 159

was especially relevant—and still is—because its operation involved several million bots. This makes it one of the more potentially pow- erful botnets known to the security community. Most security experts understood that there was nothing in the Confi cker code to suggest such an event on that particular date, but predicted attack dates are convenient for attracting attention and are thus common. National infrastructure protection begs a more mature approach to the public interpretation of collected data.

Tracking a Worm Data collection provides an excellent means for tracking a worm. Recall that a worm is a program that does three things: (1) it fi nds network-visible computers that can accept a copy of the worm program, (2) it sends a copy of itself to one of the identifi ed network-visible machines, and (3) it initiates remote execution of the new remote instance of the program on the network-visible target. This starts a chain reaction in which the identifying, copy- ing, and remote execution continue indefi nitely. By collecting network metadata while this is all happening, security analysts can generally determine what the worm is doing and how seri- ous the event might be. In the best possible cases, the collection might even provide hints that can be used to stop a worm from developing, which is obviously attractive for national infrastruc- ture security.

In 2003 and 2004, the Internet experienced an unusually large number of worm events. This was due primarily to the poor pro- cesses that were in place at the time for operating system and application-level software patching. This patching problem was true for both enterprise systems and home broadband users. During this time period, one worm after another seemed to rage across the Internet, and most observers viewed these events as largely spontaneous; that is, the general consensus was that worms would spread in just a few minutes, and that data col- lection was useless. If a worm was going to get you, the thinking went, it would get you fast, and there was nothing you could do in advance to stop the event.

The reality of the situation was actually more subtle. The SQL/Slammer worm of January 2003, for example, was one that appeared to have a spontaneous impact on traffi c. In the minutes during which the worm appeared to have spread signifi cantly, packets of User Datagram Protocol (UDP) traffi c went from small, predictable volumes with few anomalies to an immedi- ately spiked upward volume. On fi rst glance, this happened in a

Collecting network metadata allows security analysts to track a worm’s progress and predict its course.

160 Chapter 8 COLLECTION

manner that suggested no warnings, no time for preparation, and no time for incident response (see Figure 8.9 ).

The spike in packet volume due to the SQL/Slammer worm certainly appeared to be immediate and without warning. Upon much closer examination, however, one fi nds that the UDP data leading up to this event might have carried some indications and warning value from a security perspective. In particular, starting in early January 2003, UDP volumes on the specifi c SQL port used by the worm were displaying anomalous behavior. On January 2, 2003, the fi rst spike occurred, and this was followed by three weeks of similarly odd behavior. While it might be a stretch to absolutely conclude that these odd spikes were early attempts at producing a worm, no one can argue that they suggested a serious change in UDP behavior on the Internet (see Figure 8.10 ).

The suggestion here is that a more detailed inspection of UDP behavior on the SQL port before the SQL/Slammer worm achieved its aim could have given valuable data to security engineers. In particular, the vulnerability exploited by the SQL/ Slammer worm was known at the time, although most secu- rity managers were lax to install the patch. If the information in Figure 8.10 had been widely disseminated at the time, then any- one wise enough to heed the warning and install the patch would have been immune from the SQL/Slammer worm. The implica- tions of this situation should be obvious from the perspective of national infrastructure protection.

Collecting and analyzing data are important steps; the next is acting on the data in a timely manner.

SQL/Slammer Worm Released

(01/25/03)

Small Baseline

Normal UDP

Traffic Volume

Dramatic Spike

in UDP Activity

Across Internet

UDP Packets

(Internet

Backbone)

"Coarse View"

Figure 8.9 Coarse view of UDP traffi c spike from SQL/Slammer worm. (Figure courtesy of Dave Gross and Brian Rexroad.)

Chapter 8 COLLECTION 161

National Collection Program Implementing a program of national data collection for infra- structure security will require a combination of public outreach initiatives before any large-scale structures can be put in place. The citizenry and business community must fully understand the purpose, usage, and controls associated with a collection sys- tem. Mechanisms for preventing privacy abuses must be para- mount in the discussion and embedded into any architecture that might be proposed. The specifi cs of how this debate might be infl uenced are beyond the scope of this book, but it goes with- out saying that no national collection program can be successful without this requisite step.

Once general acceptance has been obtained for the creation of a national data collection program, the following technical and architectural issues must be addressed: ● Data sources —National attention is required to defi ne which

data sources are deemed valuable for providing security infor- mation to the broad collection function. Important main- frames and servers in organizations and agencies charged with infrastructure protection would seem the most obvious to include. End-user PCs owned and operated by private citi- zens would probably be the most diffi cult to include.

SQL/Slammer Worm Released

(01/25/03)

Various Spikes in

Traffic Volume Before

Worm is Successful Dramatic Spike

in UDP Activity

on SQL Port

Across Internet

UDP Packets on

SQL Port

(Internet

Backbone)

"Fine View"

Figure 8.10 Fine view of UDP traffi c spike due to SQL/Slammer worm. (Figure courtesy of Dave Gross and Brian Rexroad.)

A successful national data collection program must address the concerns of citizens and the business community regarding protection of private data.

162 Chapter 8 COLLECTION

● Protected transit —Security-relevant data collected from iden- tifi ed sources would need to be transmitted via suitable net- works with suffi cient encryption. Sizing consideration could dictate limits on the amount of information that could be pulled from a particular source.

● Storage considerations —The amount of information collected is obviously controllable, but the appetite for data from secu- rity analysts is usually unlimited. As such, pressure would exist to maximize the amount of information stored, as well as the length of time the data is available for analysis.

● Data reduction emphasis —Across the entire national initiative for data collection, time and energy should be directed toward reducing the amount of data being handled. Obviously, this is critical if a given collection method should inadvertently grab more information than is needed or might include informa- tion that has no relevance to the security challenge. While each of these issues represents a technical challenge,

particularly in terms of sizing and scaling, they can be com- bined into a reasonable system if engineered properly. The over- all approach will benefi t from stepwise refi nement methods that start with a tractable subset of data sources initially which gradu- ally increases with time.

A planned, stepwise approach to national data collection could create a system that would be of immense value in the quest to protect our national infrastructure.

163 Cyber Attacks. DOI: © Elsevier Inc. All rights reserved.

10.1016/B978-0-12-384917-5.00009-3 2011

CORRELATION A benefit of anomaly detection is that it can potentially recognize unforeseen attacks. A limitation is that it can be hard to distinguish normal from abnormal behavior .

Dorothy Denning 1

Computer and network security experts understand that cor- relation is one of the most powerful analytic methods available for threat investigation. Intrusion detection systems, for exam- ple, are only useful when the alarm streams that result from sig- nature or profi le-based processing can be correlated with data from other areas. When alarms are viewed in isolation, they are of only limited use. This limitation in processing alarms is directly related to the complexity of the target environment; that is, deci- sion makers in more complex environments will be more reliant on correlating collected data than in more limited environments. Proper national infrastructure protection is therefore highly dependent upon a coordinated program of information correla- tion from all available sources.

From a foundational perspective, four distinct analytic meth- ods are available for correlating cyber security information: profi le- based , signature-based , domain-based , and time-based correlation . Profi le-based correlation involves comparison of a normal profi le of target activity with observed patterns of activity. Presumably, if a substantive difference exists between normal and observed, this could signal a possible intrusion. Obviously, many situations exist where observed activity is not normal but does not signal an intru- sion. Websites running specials or supporting some limited-time engagement, for example, will see traffi c spikes during these peri- ods that do not match normal patterns. Nevertheless, anomalies with activity profi les are worthy of attention from a security per- spective (see Figure 9.1 ).

Signature-based correlation involves comparing a signature pattern of some known malicious condition to observed activity. If the two match, then high confi dence exists that an intrusion

9

1 D. Denning, Information Warfare and Security , Addison-Wesley, New York, 1999, p. 362.

Data in a vacuum is irrelevant; it must be compared with other data to determine its relevance and importance.

Comparing data determines what is normal and what is an anomaly.

164 Chapter 9 CORRELATION

is under way. The challenge is when observed activity shares characteristics with a signature but does not exactly match. This requires diligence from the security team to stay focused. Most signature-based correlation patterns involve some sequence of events, such as commands, which are defi ned as a discrete sig- nature, and comparison against logs of observed activity. For example, antivirus software, antispam algorithms, and intrusion detection systems all operate in this manner (see Figure 9.2 ).

Domain-based correlation involves comparing data from one domain with data collected in an entirely different con- text. Relevant differences in the data collection environments include computing environment, software architecture, network- ing technology, application profi les, and type of business being supported. For example, data collected by a power company about an attack could easily differ from data collected by a fed- eral civilian agency on the same incident. Similarly, two targets of a botnet attack could report different isolated views that could

Activity

Measure

Day 1 Day 2 Day 3 Day 4

Normal Profile

Observed Activity

Profile

Anomaly

(Starting Day 3)

Figure 9.1 Profi le-based activity anomaly.

Command

Activity Log

Day 4Day 3Day 2Day 1

Command V

Command B

Command A

Command X

Command Z

Command D

Command M

Command E

Command A

Command X

Command Y

Command Y

Command S

Command R

Command H

Command A

Command X

Command Y

Command Y

Attack Signature:

Command K

Command F

Command X

Command F

Command S

Command S

Command R

Command F

Command X

Command S

Command D

Command A

Command Q

Attack Signature Matches

Figure 9.2 Signature-based activity match.

Data comparison, especially from different domains, creates a clearer picture of adversary activity.

Chapter 9 CORRELATION 165

be correlated into a single common view. This requires a prear- ranged transport, collection, and analysis approach leading to a common correlated output (see Figure 9.3 ).

Time-based correlation compares data collected during one time period with data collected at a different time. This can involve the same or different data source but is obviously more effective if the data source is the same, because this removes one variable from the correlative analysis. Many types of attacks will not be time sensitive and are thus not well suited to this type of correlation; for example, a single break-in, during which malware is embedded in a target system, might not be a good candidate for time-based correlation. Attacks that are multistage, however, such as many “low and slow” approaches, are quite well suited to the approach. Botnet attacks are increasingly being designed by adversaries in this manner, with the distributed program attack- ing its target in a slower and more deliberate manner than via a single bombardment. Detection of such an event is well suited to time-based correlation, because potentially signifi cant time periods could exist between successive steps in an attack. Time- based correlation would be required to connect relevant steps and to fi lter out noisy, irrelevant activity (see Figure 9.4 ).

The essence of correlation in cyber security involves com- parison of various pieces of data to determine whether an intru- sion is under way. In the most desirable set of circumstances, this involves comparing two pieces of data for which every associ- ated, relevant attribute is the same except for one . Such a scenario allows the analyst to focus in on that one attribute. Time-based

Target A

Target B

CarriersBots Correlated

View

Domain-Specific Views from

A and B

Network

Manager B

Correlation of

Event Views from

A and B

Internet

Botnet Attack Aimed at Targets A and B

Network

Manager A

Figure 9.3 Domain-based correlation of a botnet attack at two targets.

Changes that appear over time may indicate a slowly building, deliberate attack.

166 Chapter 9 CORRELATION

correlation works nicely when the collection environment is exactly the same but the data is collected at different times. The analyst does not have to worry about whether changes in other factors are affecting the data, as only the time changes. In the most complex case, however, multiple pieces of data are col- lected from environments where the associated, relevant attri- butes differ. The analyst thus must juggle concerns about which attributes in which environments might be affecting the data. This greatly complicates the correlation task (see Figure 9.5 ).

Target A

CarriersBots Time-Correlated

View

Time

Domain-Specific Views from A

(Different Times)

Correlation of

Event Views from

A at Different Times

Internet

Botnet Attack Aimed at Target A

Network

Manager A

T0 T1 T2

Figure 9.4 Time-based correlation of a botnet attack.

Magnitude of Difference in Data

Collection Environment Attributes

Number of

"Pieces of Data"

to Be

Compared

2

4

6

Easiest to Correlate

Two Pieces of Data, Similar Attributes

Similar Diverse

Many Pieces of Data, Diverse Attributes

Hardest to Correlate

Figure 9.5 Taxonomy of correlation scenarios.

Chapter 9 CORRELATION 167

This data collection attribute taxonomy is important to national infrastructure, because most practical cases tend to be very complex cases that are diffi cult to correlate. Information that becomes available during an incident usually originates from wildly different sources with diverse collection methods, processing tools, network views, and so on. Worm events on the Internet, for example, are often observed with consider- able scrutiny by some organizations (perhaps with bad conse- quences), whereas other groups might not even notice that a security event is ongoing. Only the most mature correlation ana- lysts will have the ability to factor these differences in viewpoint into an accurate broad conclusion about security. To date, this has required experienced human beings with considerable train- ing. Additional research is required before dependable tools will be available to perform accurate correlation on multiple, diverse inputs.

Conventional Security Correlation Methods The current state of the practice in day-to-day network security correlation in existing national infrastructure settings is based on a technique known as threat management . In this approach, data aggregated from multiple sources is correlated to identify patterns, trends, and relationships. The overall approach relies on a security information and event management (SIEM) system for the underlying collection and aggregation of relevant data. A SIEM system does the best it can in terms of identifying correla- tion instances, using the best available algorithms for profi le, sig- nature, domain, and time-based analysis, subject to the practical limitations mentioned above. Four of the primary feeds into a typical commercially available SIEM tool for threat management are listed in the box.

We currently rely on human analysis of data across different domains and during different time periods; no software or program can factor in all relevant elements.

Information Feeds for SIEM Threat Management ● Firewall audit trails —Firewalls generate audit records when certain types of security-relevant events occur such as

denied connection requests. These records are of limited use in isolation but are often useful for correlation with other data. Other static information about a fi rewall, such as its inbound and outbound policy, is also important for correlation.

● Intrusion detection and prevention system alarms —Intrusion detection and prevention systems are designed specifi cally to generate alarm data when suspicious activity is observed. The problem is that it is not always easy to determine if something suspicious is truly malicious. Generally, correlation with other data is required to make this determination.

168 Chapter 9 CORRELATION

The interplay between the various security devices in a local threat management system is sometimes straightforward. If an intrusion detection system generates an alarm signaling some sort of problem involving a given Internet protocol (IP) source address and corresponding destination port, and if the local envi- ronment also allows inbound traffi c to this destination port, then the correlation process could generate a recommendation that the local fi rewall block either this source address or this port. Many commercial fi rewalls and intrusion detection systems pro- vide this capability today, although the reality is that many net- work managers do not make use of this type of protection. This is usually due to a lack of familiarity with the process, as well as a common lack of local knowledge about the egress and ingress traffi c through an enterprise gateway or perimeter. This is a shame, because when it is done properly the protection achieved can be quite powerful (see Figure 9.6 ).

The example shown above demonstrates the natural feedback loop that can occur when data is correlated—that is, as interpre- tation resulting from the correlation task is fed back to the fi re- wall as a new data input. This in turn affects processing and will eventually change the correlation function output. This feedback loop will cease when the resultant interpretations are no longer new and have no changes to report back to the fi rewall. Security managers often confi gure their intrusion detection systems to suppress output when this steady-state condition occurs. This reduces operator burden but great care must be taken to ensure that valid indicators are not being missed.

The correlation function can extend to different parts of the same organization with different networks, servers, applications, and management groups. Surprisingly, many correlation activities

Many security managers underutilize the commercial fi rewalls at their disposal.

Exercise caution in suppressing output once a steady-state condition has been achieved; otherwise, valid indicators may be missed.

● Operating system or application logs —Output log fi les generated by activity on an operating system or software application can provide useful indications and warnings for security. The fi rst step in forensics, for example, involves examination of log fi les for evidence. (Good hackers know not to leave such obvious tracks, of course.) In addition to logs, the specifi c attributes of the operating system and application are also important for correlation. This can include version, vendor, and confi guration data.

● Network device metadata —Information about network behavior is quickly becoming recognized by cyber security experts as possibly being the most powerful tool available for threat management. Metadata showing source and destination information about addresses and ports, as well as information about protocol, direction of fl ow, and status of protocol fl ags and settings, gives security analysts a view into network activity unavailable through any other means.

Chapter 9 CORRELATION 169

are complicated by such decentralization. To illustrate, suppose that two groups in a company experience similar security problems. The root-cause data from each group should be correlated toward the optimal interpretation. If, for example, each group found simi- lar malware in their systems, then this observation could signal the source of the attack, such as a common software vendor. This fact might not be easy to determine by either group in isolation.

Quality and Reliability Issues in Data Correlation To create a proper security correlation process for national infrastructure protection in an environment of large, cross- organizational size, scope, and scale, several technical and opera- tional factors must be considered. The most important such con- siderations involve the quality and reliability of the data sources. This calls into question any national-level initiative for which these attributes cannot be controlled.

Regarding the quality of data, the best situation involves a service level agreement between the data source and correla- tion function. Managed security services are useful, because the provider will ensure that data quality exists within well-defi ned parameters. When data originates from a mix of organizations with no service level agreements, the potential exists for inaccu- rate, misleading, or invalid data to be made available. This can only be dealt with by automated or human fi ltering in which the data source and attributes are factored into the analysis. This is troublesome when correlation relies on information volunteered across the Internet. Grass roots efforts to collect volunteered data will always have an issue with guaranteed data quality.

A similar concern exists with the reliability of a data source, especially for volunteered feeds. When data is important for

Alarm

Stream

Intrusion

DetectionFirewall

Correlation

Function

Adjust Policy Based on Alarms

Perimeter Network

Internet Firewall

Policy

Figure 9.6 Correlating intrusion detection alarms with fi rewall policy rules.

Service level agreements help guarantee quality of data.

170 Chapter 9 CORRELATION

regular analysis, perhaps based on a profi le, its continued reli- ability is essential; for example, if a data stream experiences gaps or changes, perhaps at the whim of the feed source owner, this could easily confuse the correlation process. Gaps, in particu- lar, make it tough to match observed activity against the desired patterns. This issue is especially diffi cult to manage when data is being volunteered by varied sources. Thus, in addition to qual- ity issues, correlation based on any imperfect collection process, including the use of volunteered data, will also face inherent challenges related to reliability (see Figure 9.7 ).

Many national initiatives today rely on data sources agree- ing to provide data on a best effort basis. These initiatives must be viewed with great suspicion, because the conclusions being drawn will be based on a subset of relevant data. This includes initiatives where participants send intrusion detection alarms, highly sampled netfl ow summaries, and log fi les. If the delivery is not consistent, predictable, and guaranteed, then the correla- tion result is suspect; for example, attack signature patterns can be missed, profi les can be incorrectly matched or missed, and so on. National infrastructure managers should thus only collect data that is associated with a consistent service level agreement.

Correlating Data to Detect a Worm Network service providers have a particularly good vantage point for correlating data across multiple companies, agencies, groups, individuals, and regions. All government, business, and con- sumer traffi c must traverse a provider backbone at some point,

Due to limited oversight of volunteered data, its quality and reliability cannot be guaranteed.

Without consistent, predictable, and guaranteed data delivery, correlations are likely to be incorrect and data is likely missing.

AttackAttack

Real Activity:

Reported Activity:

Result: No Attack Pattern ( ) Detected

X0 X1 X0 X3 X1 X0 X1 X0 X2 X1

X0 X0

X0 X1 X0

X0 X1 X0

X3 X0 X1 X2 X1

Imperfect Data Collection Process

Data Correlation Process (Signature-Based)

Attack Signature:

Figure 9.7 Incorrect correlation result due to imperfect collection.

Chapter 9 CORRELATION 171

so this becomes an excellent source of correlation information. Obviously, if this is done, great care must be taken to ensure full compliance with applicable laws with a deep respect for privacy considerations. The effort is worth the time, because service pro- viders collecting netfl ow information on a broad scale can gen- erally correlate observed activity with known patterns to detect large-scale events such as worms. This is typically done with greater accuracy than existing computer and network security techniques using fi rewalls and intrusion detection systems.

As an illustration, consider that security devices such as intru- sion detection systems are put in place to detect worms and viruses. Unfortunately, many worms and viruses are not so easy for an intrusion detection system to detect. The Nachi worm is such an example; it raged across the Internet during the summer of 2003, using the Internet Control Messaging Protocol (ICMP) as one of its mechanisms for operation. Some speculate that the worm was actually intended to fi nd infected systems on the Internet and go fi x them. What happened instead was that the ICMP packet fl ows got out of hand, which is the main reason why this worm caused more damage than perhaps had been intended by its designer.

Most intrusion detection systems were not set up well to detect this problem, because an intrusion detection system is typically not interested in changes to some service port. In con- trast, any network system that was monitoring ICMP fl ows would see that something was amiss. On one service provider’s back- bone this increase was evident as the Nachi worm began to oper- ate. By simply counting ICMP packets crossing gateways on its backbone, the provider could quickly see the spike in traffi c fl ows due to the worm across several key network gateways. The resul- tant time-based correlation of collected ICMP data over several hours revealed the impending worm event (see Figure 9.8 ).

One might conclude from the above example that by monitoring broad network traffi c collected across organizations a much more accurate security picture can be drawn. A complementary conclu- sion that can be drawn from this example is that the network ser- vice provider clearly plays a key role in the detection of large-scale attacks. Over the past decade, so much security responsibility has been distributed to end users and organizational managers that no common strategy exists for infrastructure protection. Instead, when a problem occurs, all vulnerable endpoints must scramble to determine a suitable means of addressing it, and this can involve confl icting approaches. One group might choose to ignore and drop all packets associated with an attack, whereas another group might choose to collect, process, and send responses to the sources

Network service providers are in a unique position to collect information across multiple venues.

Network service providers have unique views of network activity that allow them to see when something is amiss.

172 Chapter 9 CORRELATION

of attack packets. This distribution of security implies that national infrastructure protection should include some degree of centralized operations. For large-scale network service, this can only be reason- ably managed by the service provider.

Correlating Data to Detect a Botnet The most insidious type of attack one fi nds today in any large- scale, distributed, Internet-connected network environment is the botnet. The way a botnet works is that an attacker rounds up a collection of Internet-connected computers to be used as bots; these computers are generally PCs attached to some home broadband service and are generally poorly administered by the home user. Such improper system administration allows for easy insertion of malware, perhaps through fi shing or other social engineering means.

Once the bots have been confi gured with suitable malware, they are commanded by a series of bot controllers located around the Internet. These controllers generally utilize some familiar pro- tocol such as Internet Relay Chat (IRC) simply for convenience, although they could certainly use any sort of communication protocol to interact with their bots. The idea is that the controller commands the bots to perform an attack task aimed at a target predetermined by the botnet operator. This works to the advan- tage of the attacker, because the bots are generally distributed across a broad geographic spectrum, and their bandwidth capac- ity might be substantive when viewed as a collective capability.

A botnet uses home-based PCs to distribute an attack.

Several Hour Period for Initiation of Nachi Worm of 2003

Key Service

Provider Gateways

Relatively Insignificant

Change

Obviously Dramatic

Change in ICMP Count

ICMP

Packet

Count

0Snapshot at Time T 1Snapshot at Time T 2Snapshot at Time T

Figure 9.8 Time-based correlation to detect worm.

Chapter 9 CORRELATION 173

If two bots can generate 1 Mbps of attack traffi c, then a target with a 1-Gbps inbound connection can be fi lled up by 2000 bots, which turns out to be a modestly sized botnet. Following this logic, a much larger botnet, perhaps with hundreds of thou- sands or even millions of bots, can be viewed as a particularly substantive problem for national infrastructure that requires attention. The correlation issue in this case is that no single end- point will have a suitable vantage point to determine the size, scope, or intensity of a given botnet. One might suggest that the only reasonable chance one has of actually performing the proper correlation relative to a botnet is in the context of carrier infrastructure.

Steps for Botnet Detection The steps involved in the detection of a botnet via correlative analysis by a network carrier are roughly as follows:

1. Broad data collection —The detection of a botnet requires a broad enough vantage point for collecting data from both broadband-connected PCs as well as enterprise servers visible to the Internet. The type of information needed is essentially netfl ow-type metadata, including source, destination, and traffi c types.

2. One-to-many communication correlation —From the collected data, the correlative analysis must focus on identifying the typical one-to-many fan-out pattern found in a distributed botnet. This pattern can include several botnet controllers, so multiple one-to-many relations typically overlap in a botnet.

3. Geographic location correlation —It is helpful to match up the bots and controllers to a geographic location using the associated IP address. This does not provide pinpoint accuracy, but it offers a general sense of where the bots and controllers are located.

4. Vigilant activity watch —The security analysis should include close, vigilant watch of activity from the bots and servers. The most important activity to be identifi ed would be a distributed attack from the bots to some target.

The steps in the box above allow for the construction of a logical map of a botnet, showing the geographic locations of the bots, their associated service provider (usually a local broadband carrier), the set of servers used as botnet controllers, and a gen- eral depiction of any relevant activity. Typical activity found in a botnet includes recruitment of new bots, as well as attacks from the bots toward some designated target (see Figure 9.9 ).

The botnet diagram demonstrates some of the conclusions that can be drawn immediately from such an analysis. The typi- cal pattern of bot clumping that one fi nds in a botnet might give hints as to the type of social engineering or lure used to drop malware onto the target PCs. Useful hints might also be gathered from regions where the botnet seems to have gathered no bots.

Botnets can have a far- reaching geographic distribution.

174 Chapter 9 CORRELATION

One area where correlative analysis is often not useful is trying to determine correlations between the geographic locations of bot- net controllers. This generally results in no useful information, as botnet controllers tend to be scattered across the globe, driven by opportunistic hacking.

It goes without saying that national infrastructure protection requires the real-time capability to monitor botnet confi gura- tion and activity. The risk of botnets has grown so much in recent years partly because they have been able to exist under the radar of most government and commercial organizations. The fi rst step in reducing this risk involves the creation of a national capabil- ity to collect information about botnets and to advise the par- ticipants on how best to avoid being either duped into hacking someone else or directly targeted for an attack.

Large-Scale Correlation Process For national infrastructure protection, large-scale correlation of all-source data by organizations with a broad vantage point is complicated by several technical, operational, and business fac- tors, including the following: ● Data formats —Individual national asset environments will

most likely collect data in incompatible formats due to a lack of standards in security data collection tools. As a result,

Disseminating information about botnet tactics may help consumers avoid future lures.

Bot

Controller

No Geographic

Correlation

Between

Controllers

Regional Bot Clumping No Bots in Region

Figure 9.9 Correlative depiction of a typical botnet.

Chapter 9 CORRELATION 175

almost all security-relevant data is collected in a proprietary or locally defi ned format. This represents a signifi cant chal- lenge for any large-scale collection from multiple sources.

● Collection targets —Individual asset environments will likely collect data from different types of events and triggers. Some, for example, might collect detailed information about net- works and only limited information from systems, whereas others might do the opposite. This obviously complicates the comparison of aggregated data from multiple sources.

● Competition —Various commercial groups collecting relevant data might be in direct business competition. (Most govern- ment groups will admit to their share of mutual competition as well.) This competitive profi le implies that any aggregated information and any interpretation that would result from correlative analysis must be carefully protected and associ- ated with suitable anonymity. To deal with these challenges on a large scale, a deliberate

correlation process must be employed. The process must break down each component of the correlation task into discrete enti- ties with well-defi ned inputs and outputs. This process is best viewed in aggregate as consisting of fi ve different passes leading from collected data to actionable information (see Figure 9.10 ).

Collected Data

For Security Action

Feedback Loop

Pass 1 Pass 2 Pass 3 Pass 4 Pass 5

Source 1

Source 2

Source 3

Source n

Correlation Engine Components

Resolve Data

Formats

Level Data

Types

Compare Data

Attributes

Store and Protect Output

Interpret and

Filter

Correlation Back End

Figure 9.10 Large-scale, multipass correlation process with feedback.

Large-scale data correlation initiatives must overcome challenges posed by competition, incompatible data formats, and differing collection targets.

176 Chapter 9 CORRELATION

National Correlation Program Implementation of a national correlation program is likely to follow two specifi c directions. First, steps might be taken to encourage individual organizations with national infrastructure responsibility to create and follow a local program of data corre- lation. This can be done by embedding correlation requirements into standard audit and certifi cation standards, as well as within any program solicitations for government-related infrastructure

Data collection can be encouraged by making it a requirement of contracted government- related projects.

Five Passes Leading to Actionable Information 1. The fi rst pass in this process schema involves resolution of all incompatible data formats from the different sources.

In addition to the data generated by familiar security devices, these inputs can also include human-generated data that could be obtained through telephony or even social processes. The resolution must be automated via fi lters that produce a common output. Amazingly, very little work has been done in the computer security community to standardize relevant formats.

2. The second pass in the schema involves a leveling of the various types of data collected. The most common task in this pass is to categorize similar data into the appropriate set of categories. This must be done because different organizations routinely refer to the same security-relevant events by different names. Commercial tools also tend to refer to the same attacks by different names and alarm types. Large-scale correlation thus requires a common understanding of the semantics associated with activity of interest. Small-scale analysis methodologies using a common threat management tool from one vendor can skip this step; large-scale analysis from multiple, diverse sources cannot.

3. The third pass involves the actual comparison of collected data to relevant attributes. Computer security experts often refer to this pass itself as correlation. This pass is where security algorithms for profi le, signature, domain, and time-based correlation are incorporated into the analysis. It typically involves a combination of automated processing using tools, with the interpretation of human experts. In the best case, this pass in the process occurs rapidly, almost in real time, but the reality is that the analysis step can take considerable time in the most complex scenarios. This pass, along with the fi rst two passes, can be viewed collectively as the correlation engine .

4. The fourth pass involves storage and protection of the output. This is likely to include interpretation of the data once it has been aggregated and compared. Insights are often evident at this stage of the process, and these can be represented as either deliberately stored information in a database or simply as information known to security analysts involved in the overall process. In either case, the information must be protected. For large-scale applications, the size of the information collected can be massive, which implies that special database technology with the ability to scale might be required.

5. The fi fth and last pass in the process involves fi ltering and dissemination of the information. This might result in a feedback loop where output recommendations become input to a new series of fi ve correlation passes. Alternatively, it can be used by appropriate parties for immediate action such as real-time incident response. This pass, along with the storage pass, can be viewed collectively as the correlation back end .

Chapter 9 CORRELATION 177

work. The likelihood of success of this approach is high and is thus recommended for immediate adoption at the national pol- icy level.

Second, national-level programs might be created to try to correlate collected data at the highest level from all available sources. This approach is much more challenging and requires addressing the following technical and operational issues: ● Transparent operations —The analysis approach used for

correlation should be fully known to all participants. Thus, whether profi les, signatures, or the like are used, the process should be clearly explained and demonstrated. This will allow participants to help improve such aspects of the process as data feed provision, data reduction algorithms, and back-end interpretation.

● Guaranteed data feeds —Any participant providing data to the correlation process must be held to a guaranteed service level. Obviously, this level can change but only under controlled conditions that can be factored into the analysis. Without such guarantees, correlation algorithms will not work.

● Clearly defi ned value proposition —Participants should rec- ognize a clearly defi ned value proposition for their provision of data. The worst situation involves a “black hole” collection process where the output recommendations from the correla- tion activity are not generally shared.

● Focus on situational awareness —The output of the process should certainly be action oriented but should also recognize the limitations inherent in broad correlation. It is unlikely that any national-level correlation function will be able to give a real-time silver bullet to any participant. More likely, the out- put will provide situational awareness that will help in the interpretation or response to an event. By addressing these issues, the technical and operational feasi-

bility of a successful, national-level correlation function increases dramatically. Unfortunately, many legal, social, and political issues—considered outside the general scope of this book—will complicate the creation of such a function.

This page intentionally left blank

179 Cyber Attacks. DOI: © Elsevier Inc. All rights reserved.

10.1016/B978-0-12-384917-5.00010-X 2011

AWARENESS Intelligence, the information and knowledge about an adversary obtained through observation, investigation, analysis, or under- standing, is the product that provides battlespace awareness .

Edward Waltz 1

Situational awareness refers to the collective real-time under- standing within an organization of its security risk posture. Security risk measures the likelihood that an attack might pro- duce signifi cant consequences to some set of locally valued assets. A major challenge is that the factors affecting security risk are often not locally controlled and are often deliberately obscured by an adversary. To optimize situation awareness, con- siderable time, effort, and even creativity must be expended. Sadly, most existing companies and agencies with responsibility for national infrastructure have little or no discipline in this area. This is surprising, as a common question asked by senior leader- ship is whether the organization is experiencing a security risk or is “under attack” at a given time.

Awareness of security posture requires consideration of sev- eral technical, operational, business, and external or global fac- tors. These include the following: ● Known vulnerabilities —Detailed knowledge of relevant vul-

nerabilities from vendors, service providers, government, academia, and the hacking community is essential to effec- tive situational awareness. Specifi c events such as prominent hacking conferences are often a rich source of new vulnerabil- ity data.

● Security infrastructure —Understanding the state of all active security components in the local environment is required for proper situational awareness. This includes knowledge of security software versions for integrity management and anti-malware processing, signature deployments for security devices such as intrusion detection systems, and monitoring

10

1 E. Waltz, Information Warfare: Principles and Operations , Artech House, Norwood, MA, 1998.

Consider attending a hacking conference to learn more about potential vulnerabilities.

180 Chapter 10 AWARENESS

status for any types of security collection and processing systems.

● Network and computing architecture —Knowledge of network and computing architecture is also important to understand- ing an organization’s situational security posture. An accurate catalog of all inbound and outbound services through exter- nal gateways is particularly important during an incident that might be exploiting specifi c ports or protocols.

● Business environment —Security posture is directly related to business activities such as new product launches, new proj- ect initiation, public relations press releases, executive action involving anything even mildly controversial, and especially any business failures. Any types of contract negotiations between management and employee bases have a direct impact on the local situational security status.

● Global threats —Any political or global threats that might be present at a given time will certainly have an impact on an organization’s situational security posture. This must be mon- itored carefully in regions where an organization might have created a partnership or outsourcing arrangement. Because outsourcing tends to occur in regions that are remote to the organization, a global threat posture has become more signifi cant.

● Hardware and software profi les —An accurate view of all hardware and software currently in place in the organization is also essential to situational awareness. A common prob- lem involves running some product version that is too old to properly secure through a program of patching or security enhancement. A corresponding problem involves systems that are too new to properly characterize their robustness against attack. In practice, an optimal period of product oper- ation emerges between the earliest installation period, when a product or system is brand new, and the latter stages of deployment, when formal support from a vendor might have lapsed (see Figure 10.1 ). Each of these factors presents a set of unique challenges for

security teams. An emerging global confl ict, for example, will probably have nothing to do with the vulnerability profi le of soft- ware running locally in an enterprise. There are, however, clear dependencies that arise between factors in practice and will improve situational awareness. For example, when vulnerabili- ties are reported by a hacking group, the organization’s security posture will depend on its local hardware, software, and security infrastructure profi le. As a result, it is generally reasonable for an organization to combine the value of all situational status factors

The increase in global outsourcing requires awareness of how international political events may impact your vendors.

Chapter 10 AWARENESS 181

into one generic measure of its security posture. This measure should be able to provide a rough estimate of the broad, orga- nizational security risk at a given time. It should then weigh the likelihood and potential consequences of serious attack against the normal, everyday level of risk that an organization lives with every day. Presumably, risk on a day-to-day basis should be lower than during a serious incident, so it stands to reason that a rough metric could capture this status, perhaps as a high, medium, and low risk characterization (see Figure 10.2 ).

Unfortunately, the public perception of categorizing high, medium, and low security risks is that it does not provide use- ful information. This is certainly true for such measures as the public threat metric, which was used previously by the U.S. Department of Homeland Security to characterize risk. The prob- lem with this metric was that it dictated no concrete actions to be taken by citizens. If risk was characterized as low, citizens were

System Component Lifecycle Phase

Period of Optimal Usage

Brand

New

Freshly

Used

Familiar,

Mature

Slightly

Outdated

Not

Supported

High

Medium

Level of

Optimal

Use

Low

Figure 10.1 Optimal period of system usage for cyber security.

Active Attack to an

Essential Service

Ordinary Risk to all

Essential Services

Each Value Dictates a

Specific Response Action

Real-Time

High Medium Low

Figure 10.2 Rough dashboard estimate of cyber security posture.

Factoring in all elements of situational awareness and any related challenges should create an overview of an organization’s current security risk.

182 Chapter 10 AWARENESS

warned to remain vigilant and on guard; if risk was characterized as medium or even high, the advice was essentially the same. Citizens were told to go on with their normal lives, but to be somehow more careful. Obviously, this type of advice causes con- fusion and is to be avoided in national infrastructure protection.

The only way a posture metric can be useful is if it is driven by real-time events and is connected directly to an explicit inci- dent response program. When this is done, an ongoing rhythm develops where the situational status helps direct security man- agement activity. This could involve some serious fl aw being detected in an organization (which would drive the threat level upward), followed by detection of a real exploit in the wild (which would drive the threat level further upward), followed by a patch activity that fi xes the problem (which would drive the threat level back down) (see Figure 10.3 ).

Regardless of public perception with respect to previous gov- ernment threat metrics, any program of situational awareness for cyber security must include a broad characterization of real-time risk. The attributes of this broad characterization will be based on a much more detailed understanding of the real-time posture. Collectively, this posture is referred to as situational awareness and is based on an understanding of whether or not the infra- structure is under attack, which vulnerabilities are relevant to the local infrastructure, what sort of intelligence is available, the out- put of a risk management process, and information being gener- ated by a real-time security operations center. These elements are described in the sections that follow.

Most Vulnerable Period

(Threat at High)

Analysis Period

(Threat at Medium) Patch Deployed Over Time Period

(Threat to Low)

Evidence of

Product Exploit in Wild

(Threat to High) Flaw Found in Product

Used by Organization

(Threat to Medium)

Medium Threat

High Threat

Low Threat

Figure 10.3 Security posture changes based on activity and response.

Descriptors such as high, medium, and low to describe security risk are too vague to be helpful.

Security risk levels should be set to correlate with actionable items.

Chapter 10 AWARENESS 183

Detecting Infrastructure Attacks The process of determining whether an attack on national infra- structure is under way is much more diffi cult than it sounds. On the surface, one would expect that, by observing key indicators, making the determination that an attack has begun or is ongoing would seem straightforward. Correlating observed activity with profi les, signatures, and the like can provide a strong algorithmic basis, and products such as intrusion detection systems offer a means for implementation. These factors are misleading, how- ever, and the truth is that no security task is more diffi cult and complex than the detection of an ongoing attack, especially if the adversary is skilled.

To illustrate this challenge, suppose you notice that an impor- tant server is running in a somewhat sluggish manner, but you cannot diagnose the problem or explain why it is occurring. Obviously, this is suspicious and could be an indicator that your server has been attacked, but you cannot state this with any certainty. There could be a million reasons why a server is run- ning slowly, and the vast majority of them have nothing to do with security. Suppose, however, that you discover a recently installed directory on the server that is fi lled with unfamiliar, strange-looking fi les. This will clearly raise your suspicion higher, but there are still numerous explanations that do not signal an attack. Perhaps, fi nally, someone in the enterprise steps forward and admits to running some sort of benign test on the server, thus explaining all of the errant conditions. The point is that con- fi dence that a target is under attack will rise and fall, depending on the specifi cs of what is being observed. Obviously, there is a threshold at which the confi dence level is suffi ciently high in either direction to make a sound determination. In many prac- tical cases, analysis never leads to such a confi dence threshold, especially in complex national infrastructure environments (see Figure 10.4 ).

In our example, you eventually became confi dent that no attack was under way, but many scenarios are not terminated so cleanly. Instead, events expose a continuing stream of ongoing information that can have a positive, negative, or neutral effect on determining what is actually going on. In many cases, infor- mation that is incorrect or improperly interpreted has the effect of confusing the process. Relatively new technologies, such as mobile wireless services, tend to exhibit this property, especially in cases where a particular incident has never been seen before. The primary disadvantage of never determining the root cause of an attack is that the security posture cannot be accurately

There are many tools for detecting attacks, yet no single tool is comprehensive or foolproof.

184 Chapter 10 AWARENESS

measured. This is especially troublesome when the attack is severe and targets essential national infrastructure services.

Managing Vulnerability Information A common cynical view of computer security is that its experts are engaged in nothing more than a game of trivial pursuit around attack and vulnerability information. Support for this view is evident in the security books published to date, most of which contain page after page of esoteric attack specifi cs that are often long-since irrelevant. It is also evident in social circles at security and hacking conferences, where the discussion rarely addresses foundational topics of software engineering or system design but instead focuses on such trivia as which systems have which bugs in which versions on which hardware. Some security experts and hackers have become walking encyclopedias of such knowledge, even viewing information as the driver of power and skill. Anyone not possessing suffi ciently detailed knowledge is thus tagged a newbie, lamer, or perhaps worse—a manager .

In spite of this odd phenomenon, situational awareness for national infrastructure protection does require a degree of atten- tiveness to daily trivia around vulnerability information. We refer to the information as trivia simply because, once addressed and fi xed, the value of the information drops very close to zero. Nevertheless, it is important information to collect, and most national infrastructure teams use the default approach of active opportunism , where a set amount of effort is expended to gather

Determination of security risk level is a fl uid process; it changes as new information is revealed or as situations change.

Neutral

High

Confidence

of Attack

High

Confidence

of Non-Attack

Increased Confidence

Attack is Under way Additional Confidence

Required for Certainty

Event Explained

(No Attack)

Moderate Confidence

Attack is Under way

Event 1

(Server Overload)

Event 2

(Strange Files)

Event 3

(Insider Admits to Testing)

Figure 10.4 Attack confi dence changes based on events.

Chapter 10 AWARENESS 185

as much data as possible and anything else that comes in is wel- comed. The problem with active opportunism is that it will never be complete and cannot be depended upon for accurate man- agement decisions. For example, the question of whether a given vulnerability has been coded into an exploit and made available on the Internet can be researched by one, two, or 50 people. If no evidence of such an exploit is found, then the weak conclusion can be drawn that it does not exist. Obviously, information about the vulnerability could be tucked away in some IRC discussion or on an obscure hacking site, but unless it is found or volunteered the security team will never know for sure.

The best one can hope for is to create as active and complete a vulnerability information-gathering process as possible. See the box for practical heuristics that have been useful for infrastruc- ture protection in the past.

Practical Heuristics for Managing Vulnerability Information

● Structured collection —The root of all vulnerability management processes must be some sort of structured collection approach with means for assuring proper delivery of information, validating the source, cataloguing the information in a suitable taxonomy, and maintaining a useful database for real-time reference with provision for indexing and crawling vulnerability data in real-time. This structured approach should be integrated into all day-to-day cyber security activities so that accurate vulnerability information is available across the entire security infrastructure and team. Filters should exist to assure incoming data, as well as to ensure that external entities only obtain appropriate information (see Figure 10.5 ).

● Worst case assumptions —Many situations arise where a security team cannot determine whether some important piece of vulnerability-related information has actually been disclosed or has become known to an adversary group. The most mature and healthy approach in such scenarios is to assume the worst possible case. Most experts would agree that if the possibility arises that some vulnerability might be known externally, then it probably is known.

● Nondefi nitive conclusions —Making defi nitive statements about national infrastructure security is not recommended. Too many cases exist where a security team draws the confi dent conclusion that a system is secure only to later obtain vulnerability-related information to the contrary. Experienced managers understand, for example, that they should always include caveats in security posture reports given to senior leaders in government or industry.

● Connection to all sources —Managing vulnerability information should include connections to all possible sources such as industry groups, vulnerability-reporting services, hacking conferences, internal employee reports, and customer data. Sometimes the most critical piece of vulnerability information comes from the most unlikely source.

Collecting daily trivia around vulnerability information should not be dismissed as unimportant but should be considered one of many methods of achieving situational awareness.

186 Chapter 10 AWARENESS

Following the heuristics listed in the box above will help to ensure that the best available data is collected, stored, and used, but these heuristics can never provide assurance that the vulner- ability management process is perfect. Instead, managers are strongly advised to follow three basic rules: (1) always assume that the adversary knows as much or more about your infrastruc- ture than you do, (2) assume that the adversary is always keeping vulnerability-related secrets from you, and (3) never assume that you know everything relevant to the security of your infrastruc- ture. Such complete knowledge is unattainable in large, complex national infrastructure settings.

Cyber Security Intelligence Reports A technique commonly used in government intelligence commu- nity environments, but almost never in most enterprise settings, involves the creation and use of a regularly published (usually daily) intelligence report. For cyber security, such a report gener- ally includes security-related metrics, indicators, attack-related information, root-cause analysis, and so on for a designated period. It is typically provided to senior management, as well as all decision-makers on the security and infrastructure teams. The report should also be indexed for searches on current and previ- ous information, although this is not a common practice.

Although the frequency and content of intelligence reports should be tailored to the needs of the local environment, some

Daily cyber security intelligence reports that are standard in government agencies would be equally useful in enterprise settings.

Vulnerability

Data Sources

Internal Organizational Boundry

Internal

Security

Team

External

Entities

Vulnerability

Database

Index

Assured

Request

Crawl

Look-Up

Export Raw

Raw

Raw

Information

Sharing

Filter

Source

Validation

and

Delivery

Assurance

Figure 10.5 Vulnerability management structure.

Chapter 10 AWARENESS 187

types of information that one would expect in any daily intelli- gence report include the following: ● Current security posture —The situational status of the cur-

rent security risk would be required in any intelligence report, especially one issued over a daily or weekly interval (monthly intervals create too long a gap for information to be consid- ered “intelligence”).

● Top and new security risks —Characterization of the top risks, as well as any new risks, is also important to include in an intelligence report. Visualization and other techniques are often helpful to highlight changes in risk posture.

● Automated metrics —Security systems that generate metrics should provide input to the intelligence report, but care must be taken to avoid the creation of a voluminous document that no one will read. Also, raw output from some devices is indis- cernible and should be either summarized or avoided in the report.

● Human interpretation —Ultimately, the most useful cyber security intelligence includes analysis by experienced and expert human beings who can interpret available security data and recommend suitable action plans. It is unlikely that this interpretation function will be automated in the near future. The activity associated with the realization of a cyber secu-

rity intelligence report can be viewed as an ongoing and iterative process made up of three tasks (see box).

Tasks for Creating a Cyber Security Intelligence Report

1. The fi rst task involves intelligence gathering of available vulnerability and security posture data. This can be automated but should allow for manual submission from people who might have useful information to share. Many organizations do this gathering in the early morning hours, before the bulk of the business activity begins (a luxury that does not exist for global companies).

2. The second task involves interpretation and publication of the gathered data, not unlike similar processes in daily news publications. The interpretation should focus on the audience, never assuming too much or too little knowledge on the part of the reader. It is during this task that the human interpretive summary of the collected data is written.

3. The third task involves protected dissemination and archiving of the report for use by end users with a need to know. Report transmission is generally protected by encryption, and report archives and storage are protected by access controls (see Figure 10.6 ).

Human interpretation is bound to catch vulnerabilities that automated algorithms will miss.

188 Chapter 10 AWARENESS

One byproduct of creating an intelligence report is that it helps guide the local culture toward greater attentiveness to real-time security considerations. Everyone knows that, during an incident, response activity summaries will fi nd their way to senior managers which tends to heighten concentration on the accuracy and completeness of the report. In addition, when an incident occurs that does not fi nd its way into the report, manag- ers can justifi ably question the completeness of reporting around the incident.

Risk Management Process Managers of essential national services must understand the security risks associated with their underlying infrastructure. Although this can be done using all sorts of fancy risk taxono- mies, tools, and methodologies, the recommended approach is to simply maintain a prioritized list. Depending on the severity of the risks in the list, managers can decide to focus on a subset of the top ones, perhaps the top 10 or 20. Funding and resource allocation decisions for cyber security can then be driven by the security risk profi le of the organization, keeping in mind that the list of risks will change with any adjustments in threat environ- ment, technology deployment, or reported vulnerabilities.

Automated

Intelligence

Sources

Task 1 Task 2 Task 3

Intelligence

Recipients

Intelligence Report

Creation

Encrypted

Local

Intelligence

Gathering

Interpretation

and

Publication

Cyber

Intelligence

Report

Dissemination

and Archiving

Internet

Intelligence

Archive

Figure 10.6 Cyber security intelligence report creation and dissemination.

Security risks must be tracked (listed) and prioritized to drive appropriate funding and resource allocation.

Chapter 10 AWARENESS 189

The generally agreed-upon approach to measuring the secu- rity risk associated with a specifi c component begins with two estimations: ● Likelihood —This is an estimate of the chances an attack

might be successfully carried out against the specifi c compo- nent of interest.

● Consequences —This is an estimate of how serious the result might be if an attack were carried out successfully. These two estimates must be performed in the context of an

agreed-upon numeric range. The actual values in the range matter less than the relative values as the estimates increase and decrease. The simplest and most common values used are 1, 2, and 3, cor- responding to low, medium, and high for both estimates. Once the likelihood and consequences have been estimated, risk is obtained by multiplying the values. Thus, if some component has a high likelihood of attack (value 3) and medium consequences result- ing from an attack (value 2), then the associated risk is 3 times 2, or 6. If security measures are put in place to reduce the likelihood of an attack to medium (value 2), then the risk is now 2 times 2, or 4. Again, the absolute value of risk is less important than the rel- ative value based on security decisions that might be made.

A useful construct for analyzing security decisions in infra- structures compares relative security risk against the costs asso- ciated with the recommended action. The construct allows managers to consider decision paths that might increase, decrease, or leave unaffected the security risk, with the balancing consideration of increased, decreased, or unaffected associated costs (see Figure 10.7 ).

To interpret the choices in the decision path structure, start at the middle of the diagram and consider the effects of each path labeled A through H. The path labeled G shows a security deci- sion that increases costs in order to reduce risk. This is a normal management decision that is generally considered defensible as long as suffi cient budget is available. Similarly, the path labeled C is also normal, as it accepts increased risk in order to reduce costs, which is unfortunately a common enough decision.

Interestingly, any decision path in the area shaded on the fi g- ure will be generally acceptable in most cases because the rela- tionship between cost and risk is reasonable. The decision paths in the unshaded portion of the graph, however, are generally con- sidered unacceptable because of the odd balance between the two factors. Decision path H, for example, increases costs with no impact on security risk. This case corresponds to the situa- tion encountered all too often where a security safeguard is put in place that actually has zero impact on the risk profi le.

The actual numeric value of a security risk is less important than its overall relative risk.

Increasing risks likely incur increased costs; assessing relative risk will help determine the value of investing in risk reduction.

190 Chapter 10 AWARENESS

To summarize, all decisions about national infrastructure pro- tection should be made in the context of two explicit manage- ment considerations: (1) maintaining a prioritized list of security risks to the system of interest, and (2) justifying all decisions as corresponding to paths in the shaded portion of the decision path structure shown in Figure 10.7 . If these two simple consid- erations were mandatory, considerable time, effort, and money would be immediately saved for many infrastructure manage- ment teams.

Security Operations Centers The most tangible and visible realization of real-time security situational awareness is the security operations center (SOC), also referred to as a fusion center . The most basic model of SOC opera- tions involves multiple data, information, and intelligence inputs being fed into a repository used by human analysts for the pur- pose of operations such as interpretation, correlation, display, storage, archival, and decision-making. The SOC repository is constructed by active solicitation or passive acceptance of input information, and information processing combines human analy- sis with automated processing and visual display (see Figure 10.8 ).

Most SOC designs begin with a traditional centralized model where the facility is tied closely to the operations of the center.

Infrastructure

Security Cost

Infrastructure Security Risk

Path A (Worst)

Increase Risk,

Increase Cost

Path C (Normal)

Increase Risk,

Decrease Cost

Path G (Normal)

Increase Cost,

Decrease Risk

Path E (Best)

Decrease Risk,

Decrease Cost

C

D

A

B

E

F

G

H

"Shaded

Portion

Desireable"

"Unshaded

Portion

Undesireable"

Figure 10.7 Risk versus cost decision path structure.

Chapter 10 AWARENESS 191

That is, methods and procedures are created that presume SOC resources, including all personnel, are located in one place with no need for remote coordination. All data is stored in a local repository that can be physically protected in one location. This approach has its advantages, because it removes so many coor- dination-related variables from the management equation. That said, an SOC can be created from distributed resources in geo- graphically dispersed locations. Repositories can be distributed, and analysis can be performed using remote coordination tools. Generally speaking, this approach requires more work, but the main benefi t is that more expert analysts can be recruited to such an approach, especially if the requirement is that 24/7 operations be supported. Experts can be hired across the globe in a “follow- the-sun” support arrangement.

Typical operational functions supported in an SOC include all human interpretation of data by experts, management of spe- cifi c incidents as they arise, support for 24/7 contact services in case individuals have security-relevant information to share, and processing of any alarms or tickets connected to a threat management or intrusion detection system. The 24/7 aspect of SOC operation is particularly useful to national-level situational awareness, because key infrastructure protection managers will know that they can obtain a security posture status at any time from a human being on call in the SOC. Government procure- ment efforts for national services should include requirements for this type of coverage in the SOC.

Consoles

Display

ProcessingRepository

Active Solicit

Passive Accept

Human

AnalystsInformation

Sources

Response

Partners

Response

Process

Figure 10.8 Security operations center (SOC) high-level design.

The advantage to global dispersal of SOC resources is an around-the- clock real-time analysis of security threats.

192 Chapter 10 AWARENESS

National Awareness Program The goal of supporting a national-level view of security posture should not be controversial to most security and infrastructure managers. Everyone will agree that such a view is necessary and useful for supporting national infrastructure protection-related management decisions. The challenge, however, lies with the following important practical considerations: ● Commercial versus government information —To achieve full

situational awareness at the national level will require consid- erable support from both commercial and government entities. Groups supplying security status information must be pro- vided with incentives and motivations for such action. Patriotic justifi cation helps, but global companies must be more delib- erate in their sharing of information with any government.

● Information classifi cation —When information becomes clas- sifi ed, obviously the associated handling requirements will increase. This can cause problems for data fusion. In fact, the essence of data compartmentalization for classifi ed informa- tion is to prevent and avoid any type of fusion, especially with unclassifi ed data. The result is that situational awareness at the national level will probably include two views: one unclas- sifi ed and public, the other based on more sensitive views of classifi ed information.

● Agency politics —Government agencies are famous for using information as a basis for political agendas, including support for project funding, hiring plans, and facility expansion. This tendency is counter to the goal of information sharing for sit- uation awareness and must therefore be managed carefully.

● SOC responsibility —If a national SOC is to be realized, then some organization must be designated to run it. The deci- sion as to whether this should be a defense- or civilian-related initiative is beyond the scope of this book, but most security experts agree that current defense-related awareness initia- tives provide many of the elements required in a fully func- tioning SOC. If these challenges are not addressed properly, the risk is

that inaccurate views of situational awareness could arise. If an agency, for example, fi nds out about a vulnerability but decides to not share this information, then a hole emerges in any national- level risk estimation. Similarly, if a commercial organization is unable to receive and process classifi ed information, then their view of current security risk posture will not be accurate. Attentiveness to managing these issues on a case-by-case basis, perhaps as part of a national SOC, would seem the best approach.

193 Cyber Attacks. DOI: © Elsevier Inc. All rights reserved.

10.1016/B978-0-12-384917-5.00011-1 2011

RESPONSE

11

1 K. van Wyk and R. Forno, Incident Response , O’Reilly Media, Sebastopol, CA, 2001.

Incident response is a vital part of any successful IT program and is frequently overlooked until a major security emergency has occurred, resulting in untold amounts of unnecessary time and money spent, not to mention the stress associated with responding to a crisis .

Kenneth van Wyk and Richard Forno 1

The most familiar component of any cyber security program is the incident response process. This process includes all security- related activities that are initiated as a result of an attack that is imminent, suspected, under way, or completed. Incident response will generally be optimized to the local environment in an organization, but in most cases it will include at least the fol- lowing four distinct process phases: 1. Incident trigger —Some warning or event must trigger the inci-

dent response process to be initiated. Obviously, if the trigger involves a system that has already been maliciously attacked, then the response must be focused on reconstitution and disaster recovery. If the trigger involves an early warning, then it is possible that the incident response process could avoid visibly negative effects.

2. Expert gathering —This involves a gathering together of the appropriate experts to analyze the situation and make recom- mendations. Most organizations have a base set of incident response staff that work all incidents and manage a repository of information related to all previous incidents. In addition, each incident will dictate that certain subject matter experts be brought into the process to work the details. These experts will also provide a local information base relevant to the inci- dent at hand.

3. Incident analysis —Analysis of the incident is the primary task for the experts gathered during incident response. This can include detailed technical forensics, network data analysis,

194 Chapter 11 RESPONSE

and even business process examination. Generally, the most diffi cult part of any analysis involves fi guring out the under- lying cause of the incident. Once this has been determined, developing the best solution is the key goal.

4. Response activities —The output of any incident response pro- cess will be a set of management recommendations on how to deal with the incident. These often include rebuilding sys- tems, working around problems, informing customers, and the like. Providing this information to the correct individuals and organizations requires that the incident response teams be properly plugged into the specifi cs of which groups are responsible for which relevant functions. Specifi c incident response processes will vary from organi-

zation to organization, but virtually every company and agency process is based on some version of these four elements and includes incident response processes local to an organization or that might exist as a special response resource for citizens, busi- nesses, or government groups (see Figure 11.1 )

In spite of the commonality inherent in the incident response processes found in various companies and agencies, great differ- ences exist in their respective success patterns. The biggest dif- ferences reside in the relative effectiveness of incident response

Incident

triggers

Incident

response

staff

Generic

information base

(Previous incidents)

Feedback

Applicable

infrastructure

components

Feedback

Subject

matter

experts

Specific

information base

(Current incident)

Expert

Gathering

Incident

Analysis

Response

Actions

Figure 11.1 General incident response process schema.

Most organizations have some form of incident response process in place that generally incorporates the same elements.

Chapter 11 RESPONSE 195

in avoiding, rather than simply responding to, serious infrastruc- ture problems. To optimize the early-warning aspect of incident response, certain key considerations must be well understood. These include a focus on pre- versus post-attack responses, detailed understanding of what constitutes a valid indication or warning, proper construction of how an incident response team should be managed, best practices in forensic analysis, optimal interactions with law enforcement, and good processes for recov- ering from disasters. These elements are explained in more detail below, with an emphasis on how national infrastructure response processes must be constructed and operated.

Pre- Versus Post-Attack Response The most critical differentiating factor between incident response processes involves the two fundamental types of triggers that ini- tiate response. The fi rst type involves tangible, visible effects of a malicious attack or incident. These effects are usually noticed by end users in the form of slow application performance, clogged gateway performance, inability to get e-mail, slow or unavailable Internet access, and so on. Incident response in this case is usu- ally urgent and is affected by the often vocal complaints of the user base. The second type of trigger involves early warning and indications information, usually embedded in some system or network management information. These triggers are usually not visible to end users but are prone to high levels of false positive responses, where the warning really does not connect to a mali- cious action.

Incident response processes can thus be categorized into two specifi c approaches, based on the degree to which these triggers are addressed: ● Front-loaded prevention —This includes incident response

processes that are designed specifi cally to collect indications and warning information for the purpose of early prevention of security attacks. The advantage is that some attacks might be thwarted by the early focus, but the disadvantage is that the high rate of false positive responses can raise the costs of incident response dramatically.

● Back-loaded recovery —This includes incident response pro- cesses that are designed to collect information from various sources that can supply tangible, visible information about attacks that might be under way or completed. This approach reduces the false positive rates but is not effective in stopping attacks based on early warning data.

Early warning triggers are generally not visible to end users and are prone to high levels of false positives.

Effective incident response is critical, but avoiding infrastructure problems in the fi rst place will reduce the work required of the incident response team.

196 Chapter 11 RESPONSE

Hybrid incident response processes that attempt to do both front-end and back-end processing of available information are certainly possible, but the real decision point is whether to invest the time, resources, and money necessary for front-loaded pre- vention. These two types of processes can be illustrated on the time line of information that becomes available to the security team as an attack proceeds. For front-loaded prevention, the associated response costs and false positive rates are high, but the associated risk of missing information that could signal an attack is lower; for a back-loaded response, these respective val- ues are the opposite (see Figure 11.2 ).

Back-loaded incident response might be acceptable for smaller, less-critical infrastructure components, but for the pro- tection of essential national services from cyber attack the only reasonable option is to focus on front-end prevention of prob- lems. By defi nition, national infrastructure supports essential ser- vices; hence, any process that is designed specifi cally to degrade these services misses their essential nature. The fi rst implica- tion is that costs associated with incident response for national infrastructure prevention will tend to be higher than for typical enterprise situations. The second implication is that the famil- iar false positive metric, found so often in enterprise settings as a cost-cutting measure, must be removed from the vocabulary of national infrastructure protection managers.

Time

Back-Loaded RecoveryFront-Loaded Prevention

Response Cost

False Positive

Rate

Risk of Missing

Attack

Reports from Early Warnings and Indications

Systems

Reports from Users of Visible Effects from

Attack

LowHigh

LowHigh

HighLow

Figure 11.2 Comparison of front-loaded and back-loaded response processes.

Combining front-loaded prevention with back- loaded recovery creates a comprehensive response picture; however, an emphasis on front-loaded prevention may be worth the increased cost.

It is worth suffering through a higher number of false positives to ensure protection of essential national assets.

Chapter 11 RESPONSE 197

Indications and Warning Given the importance in national infrastructure protection of front-loaded prevention based on early indications and warning information, it becomes urgent to clarify the types of early trig- gers that should be used to initiate response processes. Because these triggers will vary between organizations due to obvious dif- ferences between their respective environments, the best that can be done is to categorize the various types of triggers into a broad taxonomy. Some of the elements of the taxonomy will be obvious and consistent with most current methodologies, whereas others will be quite different from current practice and will require process enhancements.

Taxonomy of Early Warning Process Triggers

The taxonomy of early warning process triggers includes: ● Vulnerability information —Knowledge of any new vulnerability is an obvious trigger for front-loaded prevention.

The vulnerability might never be exploited, but response teams should still analyze the possibilities and work toward developing proactive steps to ensure that an exploit cannot occur. In many cases, the vulnerability will be reported by a vendor, which implies that they will have to become part of the local incident response process.

● Changes in profi led behavioral metrics —Incident response teams should use meaningful changes in any measured behavioral metric as a trigger for process initiation. This can include changes in network behavior, changes in processor utilization, or changes in some application profi le. Initiation of incident response as a result of behavioral change represents a dramatic departure from current incident response processes in most organizations.

● Match on attack metric pattern —Similarly, if a signature or attack metric pattern is detected on some application, system, or network, then preventive incident response dictates that analysis be performed on the data for security implications. This is also a departure from current incident response approaches.

● Component anomalies —Any anomalous behavior detected in an infrastructure component is a candidate trigger for incident response. More intense behavioral anomalies found on more critical components will clearly trigger greater response processes.

● External attack information —Information that comes from external sources about attacks that might be locally relevant could trigger an incident response process. For national infrastructure protection, this is even more important if the information comes from a credible source regarding systems or technology having some local signifi cance.

One way to view the difference between the front-loaded and back-loaded methods is in the context of the trigger inten- sity required to initiate a response process. For the trigger approaches listed above, the information should be suffi cient to

198 Chapter 11 RESPONSE

cause the incident response team to take immediate action. In more conventional and familiar contexts, these triggers would not be suffi cient for such action (see Figure 11.3 ).

The triggers for front-loaded response share one important aspect—namely, they provide partial information that may signal a possible attack but that also could be explained in a non-security context. Thus, the major obligation of the incident response team in front-loaded prevention is to piece together all partial infor- mation into as complete a view as possible; from this view, for national infrastructure protection, the most conservative recom- mendation should be made. That is, it should be presumed that an attack is ongoing even if the team is not sure. This increases costs and decreases convenience to the local staff, but it errs on the side of caution and is thus appropriate for protecting essential services.

Incident Response Teams The optimal incident response team for national infrastructure protection includes two different components. First, a core set of individuals will manage the incident response process, main- tain relevant repository information, document all incident- related data, provide briefi ngs to anyone interested in the process (including senior management), and interact with other incident response teams. Second, a more dynamically allocated set of sub- ject matter experts will be brought into the incident response activity when an attack is targeting systems they understand best.

Back-Loaded

Recovery

Threshold

High Confidence

Attack On-Going

Front-Loaded

Prevention

Threshold

Lesser Confidence

Attack On-Going Not Enough

for Either

Response

Process

Minor

Vulnerability

Reported

Users

Detect

E-mail Virus

No

Internet

Access

Change in

Internet

Port Activity

Report of

External

Worm

Trigger

Intensity

Front-Loaded

Response

Back-Loaded

Response

Figure 11.3 Comparison of trigger intensity thresholds for response.

Front-loaded prevention responses have a high sensitivity to triggers; that is, response is initiated more often than with a back-loaded recovery response.

Erring on the side of caution is worth the extra time and expense when it comes to protecting our national assets.

Chapter 11 RESPONSE 199

In complex settings, the core incident response team is likely to be working multiple incidents simultaneously, generally with different sets of subject matter experts. Thus, response triggers will spawn new cases, which are worked in parallel to successful completion. In smaller environments, it is rare for multiple cases to be ongoing, but for larger, more complex critical infrastructure it is unusual to fi nd times when multiple incident response cases are not being worked simultaneously. This leads to the unique incident response obligation for national infrastructure protec- tion of ensuring that concurrent response activities do not mutu- ally confl ict (see Figure 11.4 ).

The notion of managing simultaneous response cases is largely unexplored in conventional computer security. This is unfortunate, because every large organization eventually comes to the realization that this is not only possible but is generally the norm. Furthermore, those national attack scenarios with the most serious potential consequences to infrastructure routinely include multiple concurrent attacks aimed at the same company or agency. Response teams in a national setting must therefore plan for the possibility of multiple, simultaneous management of different incident response cases. Some considerations that help plan properly for this possibly include the following: ● Avoidance of a single point of contact individual —If a single

individual holds the job of managing incident response pro- cesses, then the risk of case management overload emerges.

Requires Assurance that no Conflicts Between A and B

Trigger A

Trigger B

Subject Matter

Experts: A

Case B

Case A

Core Response

Team

Subject Matter

Experts: B

Spawn Case A

Spawn Case B

Figure 11.4 Management of simultaneous response cases.

Individuals on incident response teams need to ensure they are not working at cross-purposes with their colleagues.

It is unlikely that a large organization would not have simultaneous attack scenarios to face.

200 Chapter 11 RESPONSE

This might seem like a minor management detail, but given the importance of response, especially in a recovery scenario, avoidance of such weaknesses is a requirement.

● Case management automation —The use of automation to manage, log, and archive incident response cases will improve the productivity of the core incident response team and can lead to streamlined analysis, especially if previous case infor- mation is available for online, automated query and search.

● Organizational support for expert involvement —The entire organization must readily agree to provide experts for incident response when requested. This is not controversial when the process follows a back-loaded recovery method, because every- one is visually aware of the consequences of the incident. It is more challenging, however, when a front-loaded prevention approach is used and the triggers that initiate incident response are more subtle.

● 24/7 operational support —Without full 24/7 coverage every day of every year, the success likelihood of managing multiple, concurrent incident response cases drops considerably. Most organizations integrate their incident response function into an SOC to ensure proper management coverage. An interesting recent trend in infrastructure management

involves the outsourcing of certain security operations to a third party. For status monitoring of security devices such as fi rewalls and intrusion detection systems, this is a reasonably mature activ- ity and will have no materially negative effect on local security protection efforts (unless the outsourcing fi rm is incompetent). Even for certain SOC operations, outsourcing is often an excel- lent idea, especially because collection and correlation are always more effective if the vantage point is large. Outsourced SOC oper- ations can also provide the security team with access to technical skills that may not reside locally.

Incident response processes, however, can easily become awkward for full outsourcing because of the embedded nature of prevention and recovery efforts for local infrastructure. Certainly, an outsourcing provider or vendor can and should be of assis- tance, and third-party SOC experts might offer excellent guid- ance and advice. Ultimately, however, incident response must be a local management function, and the organization will have no choice but to expend time, energy, and resources to ensure that the correct local management decisions are made. Third par- ties can never prioritize actions or tailor recovery procedures to the local environment as well as the organization itself. Instead, they should be used to augment local functions, to provide expert guidance, to automate processes, to manage equipment

Companies cannot avoid complete responsibility for incident response by outsourcing the entire process; prioritizing and tailoring recovery procedures must be done locally.

Outsourcing some aspects of security operations may make good business sense.

Chapter 11 RESPONSE 201

and networks, to support data collection and correlation, and to assist in recovery.

Forensic Analysis Forensic analysis involves those activities required to investigate, at both a high level and a detailed lower level, the root cause and underpinnings of some event. Typical questions addressed dur- ing the forensic analysis process include: ● Root cause —How specifi cally was the target system attacked? ● Exploits —What vulnerabilities or exploits were used in the

attack? ● State —Is the system still under an active state of attack by an

adversary? ● Consequences —What components of the system were read,

stolen, changed, or blocked? ● Action —What actions will stop this attack (if ongoing) or pre-

vent one in the future? To answer these diffi cult questions during incident response,

forensic analysis requires the ability to drive deeply into a target system of interest, gathering relevant information but doing so in a manner than never destroys, affects, or changes key evidence. This is a critical requirement, because clumsy forensic analy- sis might overwrite important fi les, change important stamped dates on system resources, or overwrite portions of memory that include critical evidence. Forensic analysis is a diffi cult activ- ity requiring great skill and competency, as well as the ability to investigate a system both manually and with the assistance of special tools (see Figure 11.5 ).

The forensic process is performed on a computer to deter- mine how, when, and where some event on that computer might have occurred as the result of hardware, software, human, or network action. Corporate security groups, for example, often perform forensic analysis on a computer when the owner is sus- pected of violating some guideline or requirement. Law enforce- ment groups perform similar actions on computers seized from suspected criminals. Forensics can, however, be performed on a target much broader than a computer. Specifi cally, for the pro- tection of essential national services, the organization must have the ability to perform forensic analysis on the entire supporting infrastructure.

The individual technical skills required to perform such broad forensic analysis are easy to write down, but qualifi ed person- nel are not always so easy to recruit and hire. This problem is so

Great care must be taken during forensic analysis not to change or destroy fi les or other critical evidence.

Forensic analysis can be specifi c (one computer) or broad based (entire supporting infrastructure).

202 Chapter 11 RESPONSE

severe for most large organizations that it is not uncommon for a company or agency to have no local expert with suffi cient skills to properly lead the investigation of a widespread infrastructure attack. This is unacceptable, because the only options for that organization are to locate such talent externally, and this will result in a less intimate evaluation process. Long-term employees who are committed to a career in an organization will always be more knowledgeable than consultants or third parties; further- more, they will be suitably trusted to investigate an incident into the deep recesses of the local environment.

As such, the irony of forensic analysis is that most businesses and agencies would be wise to begin building and nurturing a base of talent with these skills. Typically, to maintain and satisfy forensic experts requires several things: ● Culture of relative freedom —Most good forensic analysts are

creative individuals who learned their craft by exploring. They tend to maintain their skills by continuing to explore, so orga- nizations must give them the freedom to seek and analyze systems, networks, applications, and other elements of inter- est. When they are working an incident, the target is obvious, but when they are not then managers must offer them the freedom to explore as they see fi t. This is not easy for some managers, especially in relatively mature organizations with (ahem) long legacies of tight employee controls.

● Access to interesting technology —A related aspect of the local environment required to keep forensic analysts happy is con- stant access to interesting, changing, and emerging tech- nology. What this means is that assigning your best forensic analysts to day-to-day operations around a single technology might not be the best idea.

● Ability to interact externally —Forensic analysts will also need the freedom to interact with their peer community and to

Forensic Process

Cannot Make

Changes to

Target System

Considerable

Skill and

Experience

Required

Forensic

Data

Manual

Target System

(High-Level View)

Forensic

Tools

Forensic

Analysts

Target System

(Lower-Level View)

Figure 11.5 Generic high-level forensic process schema.

An internal expert will be the one most likely to properly lead a company investigation, but few company employees have the requisite skills.

Chapter 11 RESPONSE 203

learn from experts outside the organization. This must be per- mitted and encouraged. These environmental elements are not unique to forensic

experts, but of all the skill sets required in a national infrastruc- ture protection setting forensic analysis is the one that is the most diffi cult for an organization to obtain. Good forensic ana- lysts can command the highest premium on the market and are thus diffi cult to keep, especially in a relatively low-paying govern- ment job. As such, attention to these quality-of-work-life attri- butes becomes more than just a good idea; instead, it becomes a requirement if the organization chooses to have the ability to perform forensic analysis as part of the overall incident response process.

Law Enforcement Issues A common issue faced by response teams is whether a given incident should be turned over to law enforcement for support. Most countries have laws that obligate response teams to contact law enforcement groups in the event of certain crimes; incident response teams must be familiar with these laws and must obey them without question. They must, in fact, be burned into inci- dent response processes with full review by legal council in the organization. The issue of law enforcement involvement is also driven, however, by emotional considerations, especially when great time and effort have been directed toward dealing with some incident. The team often wishes to see tangible retribution, perhaps involving the bad guys actually going to jail.

In the end, however, interaction with law enforcement for infrastructure protection should follow a more deliberate and routine process. National infrastructure protection has a singu- lar goal—namely, to ensure the continued and accurate delivery of essential services to the citizenry and businesses of a nation. This does not include the goal of catching bad guys and throwing them in jail, as much as security teams might like this result. The result is that discretionary law enforcement involvement should only be considered when the local security team believes that such enforcement could help with a current incident, perhaps through offering some relevant data or hints, or could help pre- vent a future incident by putting away some group that appears to be a repeat offender. A decision process for law enforcement involvement emerges as shown in Figure 11.6 .

This decision process does recognize and support the clear requirement that crimes must be reported, but the fi gure also

Investing in a good forensic analyst will be expensive but worthwhile for the protection of national security assets.

Carefully review local, regional, and national laws regarding when law enforcement must be contacted during a security incident.

204 Chapter 11 RESPONSE

highlights a particularly fuzzy aspect of cyber security—namely, detecting suspicious behavior on a computer network usually does not constitute suffi cient evidence of a crime being commit- ted. Even if evidence of a break-in to a given system is observed, the argument could be made that no crime has occurred, espe- cially if the break-in is the result of some automated process as one fi nds in a botnet attack.

The result is that national infrastructure protection teams will need to understand the decision process for law enforcement and follow it carefully during every incident. They will also need to create a local process for determining whether a crime has been committed in the context of their infrastructure. The result not only will optimize the interface between an organization and law enforcement but will also minimize the inevitable resource demands that will arise for the local team if law enforcement gets involved.

Disaster Recovery The process of disaster recovery after a security attack is more mature than other aspects of incident response. This stems from the commonality that exists between recovery from attack and recovery from natural disasters such as fl oods, tornados, fi res, and the like. Unfortunately, many large organizations charged with responsibility for national infrastructure do not properly address their obligation to include disaster recovery in their plan- ning. Specifi cally, disaster recovery programs have three fun- damental components, whether they are driven by concerns of malicious attack or natural disaster (see box).

Decisions on a Per-Incident Basis:

Requires

Traceability

Information

to Source

Report Incident to Law Enforcement

Evidence of a

Mandatory Reported

Crime?

View that Law

Enforcement Might

Provide Useful Data?

Evidence of

High-Likelihood

Repeat Offender?

Forensic

Analysts

Figure 11.6 Decision process for law enforcement involvement in forensics.

Incident response teams should report relevant information to law enforcement, even if it does not result in arrest.

Chapter 11 RESPONSE 205

Three Components of a Disaster Recovery Program ● Preparation —The decision to prepare in advance for disaster recovery is easy to make but much more diffi cult to

support in practice. Operational funding is usually the stumbling block, because the process of preparing for disaster in advance involves more than just writing down a list of potential actions. Instead, it often requires architectural changes to avoid single points of potential failure. It could require installation of safe, redundant means for communication between recovery teams, and it could even require upgrades to cyber security systems to ensure proper protection through a disaster.

● Planning —An essential element in a disaster recovery program is an explicit plan that is written down and incorporated into all operational methods and procedures. The plan can be continually improved as the organization deals with real disasters. For example, many organizations who relied on the use of commercial airplanes to shuttle equipment to disaster sites found that this did not work well in the aftermath of 9/11.

● Practice —The decision to practice for disasters is also an expensive one, requiring that teams of experts be funded to support mock drills. The best way to practice for a disaster is to create a realistic scenario and work through the specifi cs of the written plan. Usually, this will involve the use of spare computing or networking capacity that is set aside in a hot confi guration (see Figure 11.7 ).

Create "Mock"

Disaster Analyzed and Repaired

(If Real Incident)

Critical Infrastructure

Component "Hot" Spare

Component Provisioned

During Exercise

Now Live

Component

Preparation for Exercise Exercise Configuration

Figure 11.7 Disaster recovery exercise confi gurations.

Realistically, very few organizations actually practice for disas- ters. It requires a discipline that is generally missing from most enterprise system and network teams and can only work if the senior leadership team makes it a priority. Sadly, the only time disasters are considered is after they occur, especially after they have some impact on the local environment. This familiar process

206 Chapter 11 RESPONSE

of taking disasters seriously only after they occur is something we have all witnessed in our society, especially as it relates to natural disasters and terrorism. For proper protection of national infra- structure from cyber attack, this attitude must be adjusted.

National Response Program The most important function in any national response program involves emergency coordination among government, business, citizens, and other nations during a cyber attack incident. The respective interfaces must be identifi ed and managed as part of response planning. National programs can provide central- ized coordination, but intrasector coordination should also be encouraged (see Figure 11.8 ).

This coordination function would seem obvious, but most existing national emergency response programs and computer emergency response team (CERT) programs tend to focus on dis- semination of vulnerability-related information. This is useful, especially for smaller organizations that have no security team, but this focus tends to leave a gap in national-level coordination should a major national incident occur. Amazingly, at the time of this writing, such a major national incident has yet to occur, but if one should happen soon then national coordination in the United States is unlikely to be smooth. This is unacceptable and requires immediate attention to properly protect national infra- structure from the effects of cyber attack.

Global

Programs

(International)

Business

Enterprise

Interface

Domestic

Citizen

Interface

Intra-Sector Response Coordination

Government

Agency

Interface

Infrastructure

Sector

Interface

Telecom

Transportation

Banking

Energy

Other...

Military

Intelligence

Civilian

State

Local

National Response Program

(National-Level Coordination)

Figure 11.8 National response program coordination interfaces.

Proper planning for disaster response and recovery requires time and discipline, but the outcome is well worth the effort.

207

SAMPLE NATIONAL INFRASTRUCTURE PROTECTION REQUIREMENTS

Any discussion of computer security necessarily starts with a statement of requirements .

U.S. Department of Defense “Orange Book” ( Trusted Computer System Evaluation Criteria , DoD 5200.28-STD)

Readers of this book associated with enterprise organizations should consider translating the security material presented in this book into an action plan relevant to their local environment. For the majority, this will involve creating a set of new security requirements for infrastructure protection. Valid scenarios might include public offi cials embedding new security requirements for collection or correlation into a Request for Proposal (RFP). They might also include enterprise security engineers writing new types of security policy requirements on the fi ltering of distributed denial of service attack (DDOS) aimed at their company, as well as researchers and product engineers embedding new security requirements for deceptive honey pots into their innovation plans.

Obviously, the best way for any requirement to properly match a target environment is for it to be tailored specifi cally to that environment. This requires that the security engineer writ- ing the requirement must possess an understanding of local con- straints, along with suffi cient insight into the purpose and intent of the new security control. For this reason, it is not practical to propose in this appendix a set of requirements for national infra- structure protection that will perfectly address all cases. Instead, presented below is a set of sample base requirements that pro- vide context and illustration for readers determined to embed some of the ideas presented in this book into their local program.

Each sample requirement is written as a constraint on how a given organization might operate. In fact, the terminology for our samples follows the general format: “ The organization must …,”

APPENDIX

208 Appendix: SAMPLE NATIONAL INFRASTRUCTURE PROTECTION REQUIREMENTS

and readers should be capable of tailoring the statement to a locally specifi c format: “… do such and such under conditions XYZ in environments ABC for purposes IJK .” The requirements are not comprehensive, so the idea of cutting and pasting the exam- ples to create a new policy would be a bad idea. The require- ments are also not complete, so one should not presume that the sample requirements on correlation, for example, provide a suf- fi cient summary of the material presented on that topic. Instead, this appendix is offered as a pedagogical tool to help readers create requirements that not only may be effective at protect- ing infrastructure but are also meaningful and practical in local environments.

Sample Deception Requirements (Chapter 2) In this section, we provide three sample deception requirements that will reduce the risk of attack to a given target infrastructure component by introducing uncertainty to the attacker and by creating a means for analyzing live attacks. Readers are warned, however, that locally relevant legal issues must be carefully attended to before deploying any sort of honey pot. Attorneys who are knowledgeable in the area of practical deception deploy- ment are unfortunately quite scarce.

The organization must … (DEC-1) … operate deceptive honey pot functionality, in con- nection with infrastructure supporting essential services, that is attractive and locally accessible to malicious insiders. This requirement ensures that effort has been made to operate trap functionality focused on catching insiders, including employ- ees, consultants, visitors, and contractors, who might dem- onstrate malicious intent to commit system sabotage or data exfi ltration. The deployment does not have to be extensive but should be tailored to the size and scope of the infrastructure component being protected. The decision to run in stealth or non-stealth mode can be a local decision. Demonstration of compliance should include a test in which the honey pot is shown to be accessible from an internal network and is designed well enough to be reasonably convincing to a typical internal adversary. (DEC-2) … operate deceptive honey pot functionality in con- nection with supporting essential services that is attractive and externally accessible to malicious outsiders. This requirement ensures that effort has been made to operate trap function- ality that is focused on malicious outsiders who might target

Appendix: SAMPLE NATIONAL INFRASTRUCTURE PROTECTION REQUIREMENTS 209

organizational resources via the Internet or some other exter- nal access point, such as an extranet or virtual private network (VPN). The deployment also does not have to be extensive but should be tailored to the target environment and can be done in a stealth or non-stealth manner, depending on local needs. Penetration testing from the Internet can be used to check compliance. (DEC-3) … provide evidence that all deceptive honey pot func- tionality is associated with explicit management and support systems for the purpose of initiating response. This require- ment ensures that the organization has suffi cient back-end systems for the deception to be effective, especially if it is done in stealth mode. This requirement is best met by a honey pot alarm notifi cation system connected to human beings trained to interpret the results and direct a response action. Without such back-end support, the deception is unlikely to operate properly. It is also generally important that the back- end systems include means for dealing with innocent autho- rized users who gain access to a honey pot inadvertently.

Sample Separation Requirements (Chapter 3) In this section, we introduce six sample requirements on how fi re- walls, access controls, and fi lters can be effectively used to help protect national infrastructure. The inclusion of fi ltering require- ments for mobile wireless systems will be controversial in the vast majority of environments simply because such functionality might not be locally accessible or available through any practical means.

The organization must … (SEP-1) … proactively redirect or fi lter live DDOS traffi c before it reaches local network ingress points. This requirement ensures that the organization takes steps to reduce the risk associated with inbound DDOS attacks. A service provider operating fi lters on a large capacity backbone is a good option here. The amount of fi ltering should be expressed as a multi- ple of inbound ingress capacity. Obviously, this multiple must be greater than one—and the greater, the better. The fi lters must not operate on the ingress gateway, for obvious reasons (do the math). Testing of this capability should be done care- fully, as the creation of a live, inbound attack can easily get out of hand. (Disaster recovery procedures should always be in place before creation of a live test attack on anything.) (SEP-2) … provide evidence that inbound attacks on externally accessible applications cannot produce an amplifi cation-based

210 Appendix: SAMPLE NATIONAL INFRASTRUCTURE PROTECTION REQUIREMENTS

DDOS attack on local network egress points. This requirement ensures that the organization is addressing the risk of inbound amplifi cation attacks on poorly designed, externally acces- sible applications. The evidence required here most likely will be the result of a set of functional tests, code reviews, and requirements audits. The idea is to check for evidence that small questions at an application cannot produce very large responses to the external requestor. In the most com- plex application environments, this effort will not remove the egress DDOS risk, but the evidence gathering process should identify obvious problems. It should also raise general aware- ness of the risk for developers creating new applications. (SEP-3) … fl exibly enforce network access controls (fi rewalls) between designated groups of insiders, especially those work- ing in direct support of essential services. This requirement ensures that the organization is using internal fi rewalls to cre- ate trusted internal domains. Casual insiders, including the majority of a typical employee base, should not have the abil- ity to view, change, or block a broad set of internal resources as a result of their special access as employees, contractors, or visitors. This is especially true for access to the systems sup- porting essential services. Certainly, employees working on a specifi c component might have the ability to cause local prob- lems, but this effect should be limited to the local component. This can be accomplished with fi rewalls, access lists on rout- ers and switches, encryption-based systems, and other types of security mechanisms. Penetration testing from Intranet locations can be used to establish compliance. (SEP-4) … fl exibly enforce network access controls (fi rewalls) between organizational resources and any untrusted external network, including any mobile wireless infrastructure. The famil- iar part of this requirement involves fi rewalls between an orga- nization and external, untrusted networks such as the Internet. Almost every organization on the planet will be able to meet this requirement, albeit with a ragged perimeter model that might include hundreds or even thousands of access exceptions in their rule base. The unfamiliar part of the requirement is that mobility-based access over wireless carrier networks is included in the mediation. Because most companies and agencies do not have easy access to an enterprise mobile policy enforcement engine, cooperation with the mobile network carrier may be required (and don’t be surprised if your carrier has some trouble supporting your needs, as this is very new territory). (SEP-5) … stop inbound e-mail and web-based viruses, spam, and other malware before they reach network ingress points

Appendix: SAMPLE NATIONAL INFRASTRUCTURE PROTECTION REQUIREMENTS 211

to any local infrastructure supporting essential services. This requirement ensures that unwanted inbound traffi c is col- lected before it hits the ingress point to a target network— most likely the existing organizational Intranet. This greatly reduces the risk of a volume-based attack using these ser- vices and simplifi es gateway security requirements. Effi ciency and cost reduction concerns are a good byproduct in this approach, even though they are not the primary motivations for inclusion. Compliance can be established here through simple injection of inbound test traffi c aimed at the target. (SEP-6) … demonstrate that separation controls based on orga- nizational security policy are in place for cloud-hosted appli- cations, resources, and systems in support of essential services. This requirement ensures that the use of cloud infrastructure for applications, hosting, storage, and other components sup- porting essential services is properly protected based on orga- nizational security policy rules. With increasing adoption of cloud services for software, storage, applications, and systems, this requirement is likely to gradually develop into a set of best practices for cloud-based security. Integration of existing orga- nizational identity management functionality is likely to be one of the most challenging aspects of cloud security.

Sample Diversity Requirements (Chapter 4) In this section, we introduce two diversity requirements that will not be easy to implement in most environments. The practical reality is that most chief information offi cers (CIOs) have inten- tionally created networks that are lacking diversity, standard- ized, and cost effective but that are also susceptible to failure by a single vendor and do not have suffi cient backup by an alter- nate vendor. The desktop operating system is a good example. These requirements remain, nevertheless, powerful weapons for reducing the cascading effect of certain attacks and should thus be championed by the security team. The decision not to follow a diverse path should be made only after careful debate and con- sideration of all available options. A compromise might involve restricting the diversity to highly focused areas associated with especially critical systems.

The organization must … (DIV-1) … provide evidence that no single vendor failure or com- promise can produce a cascading effect across any combination of application, computing, or network components support- ing essential services. This requirement reduces the risk that a

212 Appendix: SAMPLE NATIONAL INFRASTRUCTURE PROTECTION REQUIREMENTS

cascading chain of failure can occur in critical infrastructure because of a common vendor thread in a technology. As sug- gested above, this is a tough requirement for most organiza- tions to meet on the desktop, given the pervasiveness of a common architecture and set of applications. It is nevertheless critical that the cascading problem be addressed through atten- tion to diversity. Compliance can be checked manually. (DIV-2) … utilize at least one live, alternative backup vendor in a substantive manner for all software, PCs, servers, and net- work components in support of essential services. This require- ment implies one possible component of meeting DIV-1 by dictating a live, alternative backup. The requirement might be tailored in practice to a target percentage; for example, the requirement might state that at least 10% of all organizational PC operating systems in support of essential services be pro- vided by a backup vendor. Compliance can be checked manu- ally here as well.

Sample Commonality Requirements (Chapter 5) In this section, two commonality requirements are included that should be well suited for integration into most environments. The goal for most organizations will be to improve policy and compliance strategies rather than to create them from scratch.

The organization must … (COM-1) … have a written security policy, with training pro- grams for decision-makers, auditable mechanisms for com- pliance, and written processes for punishing violators. The familiar part of this requirement is that a security policy must be in place with mechanisms for compliance. The unfamiliar part involves training emphasis for decision-makers and writ- ten processes for dealing with violations. (COM-2) … demonstrate full organizational compliance to at least one recognized information security standard verifi ed by an external auditor. This requirement ensures that the orga- nization has targeted at least one reasonably well-known and accepted security standard for compliance. While there are some differences between standards, the reality is that the recognized ones all include a basic core set of requirements that dictate essentially the same sort of controls. Thus, it really doesn’t matter, in the vast majority of cases, which standard is selected as long as at least one is being used.

Appendix: SAMPLE NATIONAL INFRASTRUCTURE PROTECTION REQUIREMENTS 213

Sample Depth Requirements (Chapter 6) In this section, three sample requirements are offered that are intended to improve the depth of security mechanism layers for essential services. The requirements focus on access, fail- ure, integrity, and encryption; readers can easily extrapolate this emphasis to other technical or security areas.

The organization must … (DEP-1) … provide evidence that no individual, inside or out- side the organization, can directly access systems supporting an essential service without at least two diverse security authenti- cation challenges. This requirement ensures that two types of authentication are used in accessing essential infrastructure. Local interpretation would be required to determine if the selected methods are suffi ciently diverse. A personal iden- tifi cation number (PIN) with a handheld authenticator, for example, is often touted as providing suffi cient two-factor validation of identity; however, a group might locally interpret these two factors as a single challenge. (DEP-2) … provide evidence that failure of any one protection system cannot lead to a direct compromise in any application, computing, or networking functionality supporting essential services. This requirement ensures that failure of a single pro- tection system cannot compromise the overall mission. This might be achieved via network-based security, duplication and distribution, or some other means. Firewalls, in particu- lar, are often single points of defense that require a corre- sponding alternative protection method. (DEP-3) … provide evidence that all information, whose unau- thorized disclosure could directly affect the integrity and opera- tion of any essential service, is subjected to at least two diverse levels of encryption during both storage and transmission. This requirement ensures that the most critical information for essential services be encrypted twice using diverse means. The interpretation of what constitutes “most critical informa- tion” can be negotiated locally and should truly correspond to only that information whose confi dentiality is critical to the operation of an essential service. Thus, one could imag- ine this being a very small portion of information in limited types of circumstances. End-to-end plus link-level encryp- tion is an example of how this requirement might be met in some cases.

214 Appendix: SAMPLE NATIONAL INFRASTRUCTURE PROTECTION REQUIREMENTS

Sample Discretion Requirements (Chapter 7) This section introduces two sample requirements on how infor- mation is handled. The requirements are reasonably conven- tional, and many organizations will fi nd that complying with these examples is not challenging. The real goal, however, is to create a culture of discretion in an organization; unfortunately, it is not a trivial exercise to write objective requirements that mea- sure how well a culture is suited to critical infrastructure protec- tion. The sample requirements below at least provide a start.

The organization must … (DIS-1) … provide evidence that organizational information related to any essential service is properly marked and that such markings are suitably enforced. This requirement should include evidence, perhaps through an unplanned audit, that all documents contain the proper markings. So many orga- nizations violate this simple principle, and this is a shame, because it provides powerful protection against certain types of data leakage. Data leakage tools, for example, can be tuned to detect properly marked documents that might be inadver- tently transmitted to an untrusted destination. (DIS-2) … provide evidence that organizational staff asso- ciated with essential services is fully trained in local poli- cies for how information is handled and shared externally. Compliance analysis here might require some interpretation, as most organizations will have some level of training. The key question is whether this training is considered accept- able, as well as how well the organization ensures that all staff completes the training on a regular basis. Obviously, if any of the requirements described here are inserted in the organiza- tional policy, then training must be updated accordingly.

Sample Collection Requirements (Chapter 8) This section introduces two sample collection requirements that help establish more formal, written policies on how information is collected for security purposes. A key goal in establishing any type of collection policy is to ensure that basic privacy consider- ations are fully attended to, in a manner that allows the security team suffi cient access to data to identify early indicators and to perform proper security forensic analysis.

The organization must … (COL-1) … provide evidence that a set of criteria has been established for which types of information in which contexts

Appendix: SAMPLE NATIONAL INFRASTRUCTURE PROTECTION REQUIREMENTS 215

should be collected and stored by the organization. The crite- ria for collection and storage must certainly include attention to various factors, including privacy, but the focus here is on security. The intent is to require that a set of criteria is in place for what is collected and stored, with the goal of ensuring that relevant attacks and indicators will be detectable in the col- lected data. If the collection process involves loose sampling of packets on a small percentage of network links, for exam- ple, then the likelihood of detecting an important security indicator might be low. (COL-2) … provide evidence that collection systems are in place to gather in real time and store in a secure manner all desired information from applications, systems, and networks. Having real-time access to data enables early warnings of attack. If the collection process is done in a casual batch mode, perhaps employing daily, weekly, or even monthly reports, then great damage could occur to an essential service before a corre- sponding trend might even be noted.

Sample Correlation Requirements (Chapter 9) This section introduces two sample correlation requirements that help focus an organization on a structured approach to ensuring that proper data analysis is being performed in an envi- ronment that allows for awareness and response.

The organization must … (COR-1) … provide evidence that effective algorithms are in place to correlate relevant information in real-time toward actionable results. Correlation algorithms do not have to be complex; rather, they must be properly in place and effec- tive in their operation, and they should lead to some sort of actionable security processes. In truth, complex algorithms might not even be desirable. I’ve seen simple packet counters provide more relevant information than complex pattern- matching signature-based intrusion prevention systems. (COR-2) … provide evidence that correlative output (presum- ably in a security operations center) is connected to organiza- tional awareness and response functions. This requirement ensures that the correlation, collection, awareness, and response functions are all connected. The presumption that this be done in a security operations center is based on the practical observation that most organizations that try to ensure such connections do so in a security operations center.

216 Appendix: SAMPLE NATIONAL INFRASTRUCTURE PROTECTION REQUIREMENTS

Sample Awareness Requirements (Chapter 10) This section introduces three sample requirements that focus on embedding situational awareness capabilities into the day-to-day infrastructure of an organization. Particular emphasis is placed on real-time, comprehensive capabilities.

The organization must … (AWA-1) … provide evidence that cyber security intelligence information related to essential services is collected on a regu- lar basis and disseminated to decision makers on a timely basis. This requirement ensures that an intelligence collecting process is in place. It should include mechanisms for safely obtaining raw data, for interpreting the data in a way that pro- tects its integrity as well as any privacy constraints, and for creating a set of actionable intelligence information for cyber security control. (AWA-2) … provide evidence that a real-time security oper- ations function exists that coordinates any preventive or response actions based on collected information and correlative analysis (presumably in an operations center). This require- ment ensures that the organization has a means for taking action as a result of collected intelligence. Too many groups create fancy security intelligence collection processes, render interesting patterns on large glowing wallboards, and can pro- vide anecdotes about all sorts of previous security attacks. It is far less common, however, to fi nd an organization that truly coordinates action based on available information. (AWA-3) … provide evidence that a real-time and comprehen- sive threat and vulnerability management process is in place and that relevant data is used to minimize security risk to all equipment and software supporting essential services. It is not uncommon to fi nd a threat and vulnerability management process in place in an organization. Assurance is not always available, however, that the process is real-time or comprehen- sive. That is, the data might become available in an arbitrary manner, and coverage issues for all equipment and software supporting essential services might not be properly considered.

Sample Response Requirements (Chapter 11) This section introduces two sample requirements on how an organization performs incident response. The emphasis is on enhancing existing response processes to include more proactive

Appendix: SAMPLE NATIONAL INFRASTRUCTURE PROTECTION REQUIREMENTS 217

responses to indicators as well as improved documentation and metrics.

The organization must … (RES-1) … provide evidence that the organization has the abil- ity to respond to indicators and warning signals in advance of an attack on any critical resource. This requirement ensures that an incident response can be initiated based on indica- tors, rather than just outages. Every organization has the abil- ity to notice that things have gone completely haywire (e.g., network down, e-mail not working), but only more aggres- sive groups have built processes for responding to more sub- tle data, perhaps from network devices, servers, or security systems. (RES-2) … provide evidence that the organization maintains documentation and metrics on the root cause of past security problems, as well as the effectiveness of response activities for past and present security incidents. Amazingly, few solicita- tions include this requirement; in fact, as a member of a ser- vice provider security team for the past 25 years, I’ve only seen this partially required a couple of times in major government procurements. More generic past practice requirements are often specifi ed by government buyers (rarely, if ever, in com- mercial settings), but the specifi cs regarding root cause met- rics, documented effectiveness, and other statistics are rarely dictated.

This page intentionally left blank

INDEX 219

INDEX

Access control lists (ACLs) LAN controls , 14 layered access controls ,

120 Access controls

functional separation , 55 layered , 120–122 , 122f national infrastructure SSO ,

116 remote e-mail , 118 separation principle , 14

Access paths, national depth program , 127

Access techniques, separation principle , 13–14

Accuracy data collection , 170–171 intelligence reports , 188 national infrastructure

fi rewalls , 57 SCADA systems , 62

ACLs , see Access control lists (ACLs)

Actionable information , 176 , 182

Active opportunism, vulnerability information management , 184–185

Actual assets and honey pot , 35 separation techniques , 54

Administrators, as infrastructure decision-makers , 103

Adversary separation , 53 Adversary types , 4–5 , 5f , 9–11 Aggregation

data collection , 146f system data collection , 152

Air gapping , 63–64 Alarm feed, intrusion detection

information , 126f Alarms

and actionable information , 176

false , 44 intrusion detection , 167 , 168 layered intrusion detection ,

125 SIEM threat management ,

167 SOC , 191

Alarm streams and correlation , 163 , 169f , 170 SIEM , 154–155

Algorithms and actionable information ,

176 antispam , 163–164 attack detection , 183 and awareness , 25 and collection , 23 , 145 , 157 and correlation , 24–25 ,

167–168 , 177 DDOS fi ltering , 60 and discretion , 21 vs. human interpretation , 187

Amplication approach, DDOS fi ltering , 60–61

Analysis objective, as deception , 32

Antivirus software botnet detection , 120 and botnets , 7–8 and correlation , 163–164 , 171 relevance , 119–120 as safeguard , 2 and separation , 15 , 51 system data collection , 152

Apple® PC diversity , 77 Application interoperability, and

desktop diversity , 79 Applications metric, data

collection , 151 Application strengthening,

encryption methods , 123 Approach factor, separation

techniques , 54

Approved external site, and obscurity layers , 141

Architectural separation layered e-mail fi ltering , 120f trusted networks , 15

Architecture issues, and awareness , 180

Asset identifi cation, national depth program , 127

Asset separation DDOS and CDN-hosted

content , 69f overview , 68–70

Assistance questions, TCB , 132 Attack confi dence, event

dependence , 184f Attack entry points, and

deception , 33–34 Attack metric pattern, early

warning process , 197 Attack motivations, national

infrastructure , 5 Attention objective, as

deception , 31 Attribute differences, and

diversity , 73–74 , 74f Attributes, information

reconnaissance , 139 Audits

and best practices , 18 and collection principle ,

22–23 defi nition , 89 importance , 18 meaningful vs. measurable

best practices , 91 national infrastructure

simplifi cation , 102 organization examples , 90f purpose , 90 security , see Security audit SIEM threat management ,

167

220 INDEX

Authentication layered , 115–118 , 117f remote e-mail access , 118 separation principle , 13

Authorized services, deception scanning stage , 36

Automated attacks botnets , 48–50 , 203–204 propagation , 74 , 81 worms , 77

Automated control systems , 1–2 , 2f

Automated metrics, intelligence reports , 187

Automation and actionable information ,

176 case management , 200 data collection , 21–22 data correlation , 169 in deception , 37 fusion center , 23–24 vs. human interpretation , 187 incident response cases , 200 intelligence gathering , 187 ,

188f reconnaissance , 138 situation awareness , 26f SOC , 190 statistics generation , 22

Availability deception exploitation stage ,

43–44 as security concern , 4

Awareness principle , see also Situational awareness

cyber security methodology , 11

implementation , 25–26 large-scale infrastructure

protection , 26 process fl ow , 26f sample requirements , 216 and security policy , 103 , 104

Back-end insiders, deception exploitation stage , 44 Back-loaded response ,

195 , 196f

Backup centers, diversity issues , 85

Behavioral metrics, early warning process , 197

Bell-La Padula disclosure, and MLS , 70–72

Best practices , see also Commonality principle

common standards , 90–91 consistency principle , 17–18 examples , 89 meaningful vs. measurable ,

91 , 92f national commonality

program , 108 national infrastructure

protection , 94–95 vs. security audit , 93

Biba integrity model , 70–72 Blaster worm , 76–77 Bogus vulnerabilities, and

deception discovery stage , 39–40 exploitation stage , 43–44 open ports , 38f and real assets , 44 scanning stage , 36

Botnets and antivirus software , 120 attack components , 7 bot defi nition , 6–7 controller defi nition , 7 correlation-based detection ,

172–174 , 174f and correlation principle ,

24–25 data collection trends , 157 ,

158f DDOS attack , 8f and deception , 12 domain-based correlation ,

164–165 , 165f operator defi nition , 7 and PC diversity , 78 real-time analysis , 48 as security concern , 4 and separation techniques ,

56–57 software drop defi nition , 7

system data collection , 152–153

target defi nition , 7 threat , 6–9 time-based correlation , 165 ,

166f Boundary scanning, air-gapped

networks , 64 British Security Standard, best

practices , 91 BS-7799, best practices

standards , 91 Business environment, and

awareness , 180

Career path basic considerations , 105–106 security teams , 95

Carrier-centric network-based fi rewalls , 59f

Cascade modeling, national diversity program , 87

Case studies deception discovery stage , 40 depth effectiveness , 111

CDNs , see Content distribution networks (CDNs)

Centralized mediation functional separation ,

56 , 56f smart device security , 58–59

CERT , see Computer emergency response team (CERT)

Certifi cation/education programs

best practice recommendations , 102–105

national infrastructure protection , 95

ROI trends , 104 , 104f Certifi ed Information Systems

Security Professional (CISSP) , 105

Circuit-switched technology , 82 Citizen-based data collection ,

153–154 Clark-Wilson integrity model ,

67

INDEX 221

Classifi cation commercial vs. government

information , 192 and information disclosure ,

142f organizational compartments ,

141 Clearance

commercial mapping , 143f organizational compartments ,

141 Clear policy, air-gapped

networks , 64 Cloud computing

diversity paradox , 80–82 fi rewalls , 59 layered e-mail virus/spam

protection , 119–120 network-based fi rewalls , 15

Clutter engineering chart example ,

100f national infrastructure

simplifi cation , 102 Collection of bots , 7 Collection principle , see also

Data collection and awareness , 25 cyber security methodology , 10 defi nition , 145 implementation , 21–23 large-scale trending , 156–159 national infrastructure , 22f national program , 161–162 sample requirements ,

214–215 security goals , 146–147 SIEM , 154–156 , 155f , 156f

Commercial databases data collection , 152 size , 3 system data collection , 152

Commercial fi rewalls and correlation , 168 national infrastructure , 57 and SCADA , 63 tailored separation , 53

Commercially motivated attack , 5

Commercial operating systems Mac OS® , 81 PC diversity , 77 UNIX® , 120 vulnerabilities , 139 Windows® , 74 , 77 , 81 , 120

Commercial organizations , see also Industry environments

botnet attacks , 174 clearances/classifi cations ,

143f competition issues , 175 e-mail protection , 119 government assistance , 136 information sharing , 28–29 insider separation , 66 intrusion detection , 125 national awareness program ,

192 national services , 1 and PII , 20–21 security audits , 108 security policy , 95–96 SIEM , 154 volunteered data , 158 vulnerability reports ,

129–130 Commercial tools

actionable information , 176 and deception exposing stage ,

46–47 large-scale offerings , 56 national infrastructure

protection , 14 , 15f satellite data services , 86 SIEM , 167–168 threat management systems ,

2–3 Commissions and boards

cyber security principle implementation , 28

national commonality program , 108

Commonality principle career path , 105–106 certifi cation/education ,

102–105 culture of security , 99f

engineering chart cluttered , 100f simplifi ed , 101f

infrastructure simplifi cation , 99–102

national infrastructure protection best practices , 94–95

national program , 107–108 overview , 89 past security practice ,

106–107 reward structure , 105–106 sample requirements , 212 security education ROI trends ,

104f security policy , 95–97 , 97f security protection culture ,

97–99 world-class infrastructure

protection , 94f Compartmentalization

and discretion principle , 141–143

information classifi cation , 192

separation techniques , 54f Competition

large-scale correlation , 175 PC diversity , 79

Complex environments, simplifi cation , 101–102

Complex networks, fi rewalls , 52f

Component distribution, as separation objective , 53

Computer emergency response team (CERT) , 206

Computer-to-human interface, and deception , 47–48

Confi cker worm , 158–159 Confi dentiality

as security concern , 4 vulnerability risk , 6

Consistency principle cyber security methodology , 10 implementation , 17–19

Consumer entertainment systems , 1

222 INDEX

Content condition, deceptive documents , 41

Content distribution networks (CDNs) , 69 , 69f

Correlation principle actionable information , 176 analytical methods , 163 and awareness , 25 basic considerations , 165–166 botnet detection , 172–174 ,

174f collection issues , 170f conventional methods ,

167–169 cyber security methodology ,

10–11 domain-based example , 165f implementation , 23–25 , 24f improvement steps , 24 intrusion detection and

fi rewalls , 169f large-scale , 174–176 , 175f national program , 176–177 network service providers ,

171 overview , 163 profi le-based example , 164f quality/reliability issues ,

169–170 sample requirements , 215 scenario taxonomy , 166f , 167 signature-based example ,

164f time-based example , 166f worm detection , 170–172

Cost issues cyber security principle

implementation , 29 and diversity principle , 75 platform diversity , 79 vs. risks , 190f

Country-sponsored warfare , 5 Coverage

data collection trends , 158 national infrastructure

fi rewalls , 57 SCADA systems , 62

Critical applications, as security concern , 4

Critical path analysis, national diversity program , 87

Culture of security basic considerations , 94–95 ,

97–99 implementation , 99 options , 99f

Cyber attack example , 2f Cyber security methodology

awareness principle , 25–26 collection principle , 21–23 , 22f components , 9–11 consistency principle , 17–19 correlation principle , 23–25 ,

24f deception , 11–13 depth principle , 19–20 discretion principle , 20–21 diversity principle , 16–17 intelligence reports , 186–188 national principle

implementation , 28–29 response principle , 26–28 , 27f separation , 13–15

Cyber security scale, large vs. small , 3f

Databases actionable information , 176 asset separation , 68–69 as national infrastructure , 1 , 3 national infrastructure vs.

commercial , 3 past security practices , 106 system data collection , 152 vulnerability information

management , 185 , 186f Data collection , see also

Collection principle with aggregation , 146f botnet behavior , 158f botnet detection , 173 and correlation issues , 170f decision analysis template ,

147f examples , 153f generic example , 148f network metadata , 148–150 network service providers , 171

system data , 150–154 top areas , 151 vulnerability detection , 149f vulnerability information

management , 185 worm tracking , 159–160 , 160f ,

161f Data feeds

and correlation principle , 24 national correlation program ,

177 quality issues , 169–170

Data formats, large-scale correlation , 174–175

Data leakage protection (DLP) systems , 67 , 141

Data marking enforcement , 66–67

Data sampling technique , 149 Data services , 82 , 86–87 Data sources, national collection

program , 161 Data storage

encryption methods , 123 national collection program ,

162 DDOS , see Distributed denial of

service attack (DDOS) Deception principle

adversary considerations , 33 and botnets , 12 cyber security methodology , 9 deliberately open ports , 37–39 discovery stage , 39–40 documents , 41–42 , 42f example use , 32f exploitation stage , 42–44 exposing stage , 46–47 , 46f honey pots and software bugs ,

37 human-computer interfaces ,

47–49 , 48f implementation , 11–13 interface components , 12f national asset service

interface , 36f national program , 49–50 objectives , 31–32 overview , 31

INDEX 223

procurement tricks , 45–46 , 45f

sample requirements , 208–209

scanning stage , 35–37 stages , 34 stages for national

infrastructure , 34f Decision-makers

back-end insiders , 44 and certifi cation/education ,

95 , 102 , 104–105 , 104f and data correlation , 163 and intelligence reports , 186 and security policy , 104 and TCB , 132

Decision process data collection , 147f forensic analysis , 204f risk vs. cost , 190f risk management , 189 security policy , 97f

Decomposition, asset separation , 69

Defense in depth cyber security methodology ,

10 effectiveness , 111–114 , 112f ,

114f end-user authentication , 117f general schema , 110f implementation , 19–20 , 19f ,

110 intrusion detection

information sharing , 126f layered access controls ,

120–122 layered authentication ,

115–118 layered e-mail fi ltering , 120f layered e-mail virus/spam

protection , 119–120 layered encryption , 122–124 ,

124f layered intrusion detection ,

124–126 national infrastructure , 19f national program , 126–127 overview , 109

remote e-mail access , 118 sample requirements , 213

Depth principle , see Defense in depth

Designers, as decision-makers , 103

Desktop computer systems , see Personal computers (PCs)

Developers, as decision-makers , 103

Digital rights management (DRM), and worms , 77

Disaster recovery process exercise confi gurations , 205f process , 204–206 program components , 205

Disclosure clearance/classifi cation

control , 142f deception exploitation stage ,

43–44 as security concern , 4

Discovery phase defi nition , 34 overview , 39–40

Discretion principle clearance/classifi cation

commercial mapping , 143f

cyber security methodology , 10

implementation , 20–21 information disclosure

control , 142f information reconnaissance ,

137–139 information sharing , 135–137 ,

137f national program , 143–144 obscurity layers , 139–141 ,

140f organizational compartments ,

141–143 overview , 129 sample requirements , 214 “security through obscurity” ,

133–135 and TCB , 131 top-secret information , 20

trusted computing base , 130–133 , 131f

vulnerability disclosure lifecycle , 135f

Distributed denial of service attack (DDOS)

and authentication and identity management , 13

botnets , 8f CDN-hosted content , 69 , 69f national separation program ,

72 network-based fi rewalls , 14 network technology diversity ,

83 separation principle , 9

Distributed denial of service attack (DDOS) fi lter

challanges , 61 inbound attacks , 61f separation techniques ,

60–61 Distributed mediation, functional

separation , 56 , 56f Diversity principle

and attribute differences , 73–74 , 74f

cloud computing , 80–82 cyber security methodology , 10 desktop computer systems ,

77–80 , 80f enforcing , 17 implementation , 16–17 national infrastructure , 16f national program , 87 network technology , 82–84 overview , 73 PC nondiversity example , 78f physical diversity , 85 proof factors , 116 sample requirements , 211–212 satellite data services , 86–87 ,

86f with SSO , 116 and worms , 75–77 , 76f , 83f

DLP systems , see Data leakage protection (DLP) systems

DNS , see Domain name system (DNS)

224 INDEX

Domain-based correlation , 164–165 , 165f

Domain name system (DNS) and CDNs , 69–70 cyber security principle

implementation , 29 deceptive open ports , 37–38

DRM , see Digital rights management (DRM)

Dual-homing , 64–65 , 65f Duplication

deception discovery stage , 40 honey pot design , 40 , 41f

Duty controls, and best practices , 18

E-mail layered fi ltering , 120f layered virus protection ,

119–120 remote access authentication ,

118 Emergency response

as national infrastructure , 1 national program , 206

Encryption best practices , 91 data collection , 152 deceptive documents , 42 intelligence reports , 187 layered , 122–124 , 124f national infrastructure , 2 ,

114 , 123 past security practice , 107 protected transit , 162

End user education , 105 Energy objective, as deception ,

31 Enforceability, security policy , 96 Engineering analysis, depth

effectiveness , 111 Engineering chart

cluttered , 100f simplifi ed example , 101f

Engineering standards, quality levels , 19

Enterprise security and deception principle , 12 desktop diversity options , 80f

layered authentication , 116 and PC diversity , 79 separation principle , 13–14 well-known techniques , 2–3

Expert gathering , 193 Exploitation points

deceptive open ports , 39 defi nition , 4–5 forensic analysis , 201 and honey pots , 34 national infrastructure , 5f scanning stage , 35–36 and “security through

obscurity” , 134 Exploitation stage

defi nition , 35 overview , 42–44 pre- and post-attack stages , 43f

Exposing stage defi nition , 35 overview , 46–47 , 46f

External adversary , 4–5

False positives deception exploitation stage , 43 rate , 28 and response principle , 27 response to , 43

Federal Information Security Management Act (FISMA) , 18 , 90

Fiber routes network technology diversity ,

83 worm propagation , 84f

Field control systems , 62 Filtering

DDOS , 60–61 e-mail, layered , 119–120 , 120f packet fi ltering routers , 15 system data collection , 152 vulnerability information

management , 185 Financial applications, as

national infrastructure , 1 Financially driven criminal

attack , 5 Financial networks, insider

separation , 66

Firewalls , see also Separation principle

approaches , 51–53 carrier-centric network-

based , 59f cloud computing , 59 intrusion detection

correlation , 169f large-scale networks , 51 layered access controls ,

121–122 , 122f national infrastructure ,

57–60 network-based , see Network-

based fi rewalls SCADA architecture , 63f separation enhancements ,

14 , 15f separation principle , 14 SIEM threat management , 167 simple/complex networks , 52f and worms , 76

FISMA , see Federal Information Security Management Act (FISMA)

Fix questions, TCB , 132 Flaws

and defense in depth , 112 and security posture , 182f

Forensic analysis decision process , 204f incident response , 201–203 ,

202f Front-loaded response , 195 ,

196f , 198 Functional controls, and

defense layers , 19–20 Functional separation

distributed vs. centralized mediation , 56f

overview , 55–57 Fusion centers , see also Security

operations centers (SOC) and correlation principle , 23–24 and response principle , 28 situational awareness , 190

Generalization, and infrastructure simplifi cation , 100 , 102

INDEX 225

Geographic location, botnet detection , 173

Global threats, and awareness , 180 Google® , 77 Government agencies/

environments audits , 18 botnets , 174 cloud computing , 15 , 15f commissions/boards , 108 competition , 175 data collection , 22f , 145 , 146 ,

151–153 data markings , 66–67 and deception , 12 discretion issues , 20 , 129 fi rewalls , 15 information sharing , 28–29 ,

136 , 137f infrastructure best practices ,

92–93 insider separation , 66 intelligence reports , 186 intrusion detection , 125–126 known vulnerabilites , 179 layered authentication , 115 layered intrusion detection ,

125–126 MLS , 70 national awareness program ,

192 national commonality

program , 108 national discretion program ,

143 national diversity program , 87 national response program ,

206 , 206f national separation program ,

71–72 national services , 1 network violations , 64 organizational compartments ,

141 PC diversity , 77 physical diversity , 85 politics , 192 response issues , 194 security policy , 95–96

separation program , 71–72 SIEM , 154 SOC , 191 system data collection ,

152–153 system size issues , 2–3 TCB , 132 volunteered data , 158 vulnerability information

management , 185 vulnerability reporting , 6 worm detection , 170–171

Hacking and awareness , 180–181 and discretion , 129 motivation , 5 national discretion program ,

143–144 and “security through

obscurity” , 134–135 Hardening (servers), and

deliberately open ports , 37

Hardware profi les, and awareness , 180

Health Insurance Portability and Accountability Act (HIPAA) , 90

Hidden probes, deception exposing stage , 44 , 47

HIPAA , see Health Insurance Portability and Accountability Act (HIPAA)

HMI , see Human-machine interface (HMI)

Honey pot and actual assets , 35 and deception , 32 defi nition , 11 duplication , 40 , 41f environmental mimics , 33 and exploitable points , 34 insider separation , 66 monitoring , 35 in normal server complex , 39f and real assets , 13 and software bugs , 37

testing , 12 vulnerability mimics , 40

HTTP , see Hypertext transfer protocol (HTTP)

Human-computer interfaces, and deception , 47–49

Human-human interfaces, and deception , 47–48 , 48f

Human interpretation, automated metrics , 187

Human-machine interface (HMI) , 62

Hypertext transfer protocol (HTTP), deceptive open ports , 37–38 , 38f

ICMP , see Internet Control Messaging Protocol (ICMP)

Identity management, separation principle , 13

Identity theft, as security concern , 4

IEC , see International Electrotechnical Commission (IEC)

Implied statement, and deception principle , 13

In-band detection , 125 Incident analysis , 193–194 Incident response , see also

Response principle defi nition , 194 disaster recovery , 204–206 ,

205f early warning triggers , 197 forensic analysis , 201–203 , 202f front- vs. back-loaded , 196f indications/warnings ,

197–198 law enforcement issues ,

203–204 , 204f national program , 206 , 206f phases , 193–194 pre- vs. post-attack , 195–196 process , 194f security teams , 198–201 simultaneous cases , 199f trigger intensity thresholds ,

198f

226 INDEX

Incident trigger defi nition , 193 early warning , 197

Inclusiveness, security policy , 96

Indications and warnings defi nition , 42–43 early triggers , 197 incident response , 197–198 response principle , 26–27

Industry environments , see also Commercial organizations

access control , 142 authentication issues , 115 career path/salary , 105 data collection , 22f , 151 and hackers , 129–130 information sharing , 28–29 ,

136 , 137f intrusion detection ,

125–126 national discretion program ,

143 physical diversity , 85 system size issues , 2–3 vulnerability information

management , 185 Information management,

vulnerabilities , 184–186 , 186f

Information reconnaissance information types , 138–139 overview , 137–139 planning levels , 138

Information sharing commercial vs. government ,

192 cyber security principle

implementation , 28–29 and discretion , 135–137 by government agencies , 136 ,

137f hacker perspective , 129 and incident response , 197 and intrusion detection , 126f national discretion program ,

143 occurrences , 135

and “security through obscurity” , 133

Infrastructure protection and awareness , 179–180 and meaningful best

practices , 92–95 Infrastructure simplifi cation

commitment , 95 , 99–102 national infrastructure , 101–102

Insider separation, basic considerations , 65–68

Integrity and best practices , 18 deception exploitation stage ,

43–44 as security concern , 4

Intelligence community daily briefs , 26 and discretion principle , 20 intelligence reports , 186

Intelligence reports creation , 187 creation/dissemination , 188f for cyber security , 186–188

Interfaces and deception principle ,

11–12 , 12f human-computer , 47–49 national infrastructure

simplifi cation , 102 national response program ,

206f Internal adversary , 4–5 Internal fi rewalls

insider separation , 66 layered access controls , 122

Internal separation as fi rewall approach , 52–53 national separation program ,

72 International Electrotechnical

Commission (IEC) , 91 International Organization for

Standardization (ISO) , 91 Internet Control Messaging

Protocol (ICMP), worm detection , 171

Internet Explorer®, PC diversity , 77

Internet Protocol (IP) intrusion detection , 168 layered access controls , 121 packet-switched technology ,

82 separation principle , 14

Internet Protocol over Satellite (IPoS) , 86

Internet Relay Chat (IRC), and botnets , 7–8 , 172

Intrusion detection with data security , 125 fi rewall policy correlation ,

169f information sharing , 126f layered , 124–126 SIEM threat management ,

167 Intrusion prevention , 125 Inventory processes, system

data collection , 151–152

Investment considerations and centralized security , 59 ROI and security education ,

104 , 104f IP , see Internet Protocol (IP) iPhone® , 77 iPod® , 77 IPoS , see Internet Protocol over

Satellite (IPoS) IRC , see Internet Relay Chat

(IRC) ISO , see International

Organization for Standardization (ISO)

LAN controls , see Local area network (LAN) controls

Large-scale correlation example , 175f factors , 174–176

Large-scale cyber security fi rewall protection , 51 , 56 vs. small-scale , 3 , 3f

Large-scale trending, data collection , 156–159

Law enforcement issues databases as infrastructure , 1

INDEX 227

incident response , 203–204 Layered access controls ,

120–122 Layered authentication

end-user , 117f overview , 115–118 remote e-mail access , 118

Layered encryption multiple layers , 124f national infrastructure , 123 overview , 122–124

Layered intrusion detection , 124–126

Layer of protection defense in depth overview ,

109 effectiveness , 112f , 114f

Legality questions, TCB , 132 Likelihood, risk management ,

189 Limits questions, TCB , 132 Local area fi rewall aggregation

example , 58f technique , 57

Local area network (LAN) controls , 14

Log fi les and collection principle ,

22–23 SIEM threat management ,

168 Logical access controls,

separation principle , 14 Logical diversity, network

technology , 82 Low radar actions , 42–43

MAC , see Media access control (MAC)

Mac OS®-based operating systems , 81

Mainframe data storage encryption methods , 123 system data collection , 150–

151 , 153 , 153f Malware

and awareness , 179–180 botnets , 7–8 , 172 and cloud computing , 81

and correlation , 165 , 168–169 and data collection , 152 and depth , 114 , 119–120 and open ports , 37 and PC diversity , 78 and separation , 56–57 , 65

Mandatory controls, and TCB , 131

Master terminal unit (MTU) , 62 Meaningful best practices

for infrastructure protection , 92–95

vs. measurable , 91 , 92f Measurable best practices vs.

meaningful , 91 , 92f Media access control (MAC),

separation principle , 14 Metadata

data collection , 148 sampling , 149 SIEM threat management ,

168 Military support services, as

national infrastructure , 1 Misinformation, in deception ,

11 MLS , see Multilevel security

(MLS) Mobile devices

encryption methods , 123 layered authentication issues ,

117 virus/spam issues , 119

Mobile telecommunications, as national infrastructure , 1

Monitoring deception exposing stage ,

46–47 honey pot , 35 intruders , 37 by network service providers ,

171 MTU , see Master terminal unit

(MTU) Multilevel security (MLS)

example , 71f for separation of assets , 70–72

Multiple access control systems, management , 122

Nachi worm , 171 National infrastructure

adversaries and exploitation points , 4–5 , 5f

attack detection , 183–184 attack motivations , 5 and awareness , 25–26 , 216 and collection , 21–23 , 22f ,

214–215 and commonality , 212 common security concerns , 4 and consistency , 17–19 and correlation , 23–25 , 24f ,

174–176 , 215 cyber attack vulnerability ,

1–2 , 2f cyber security methodology

components , 9–11 cyber threats, vulnerabilities,

attacks , 4–6 database size , 3 data collection , 145 data correlation issues , 170 DDOS fi ltering , 60 and deception , 11 , 34f , 43 , 46 ,

208–209 deceptive documents ,

41–42 and depth , 19–20 , 19f , 213 disaster recovery , 204–205 and discretion , 20–21 , 214 and diversity , 16–17 , 16f , 73 ,

211–212 exploitation points , 5f fi rewalls , 15f , 57–60 functional separation

techniques , 55–56 insider separation , 65–68 layered access controls ,

121–122 layered authentication , 115 layered encryption , 122–123 network technology diversity ,

84 obscurity layers , 139–140 overview , 1 and past security practice ,

106–107 PC diversity , 78

228 INDEX

National infrastructure –(contd.) physical attack vulnerability ,

1–2 , 2f and protection , 94–95 , 207–208 and response , 26–28 , 27f , 196 ,

203 , 216–217 and separation , 13–15 , 51 ,

209–211 service interface with

deception , 36f simplifi cation , 101–102 small- vs. large-scale security ,

2f , 3 smart device management , 58 SSO access system , 116 system data collection , 150 TCB assets , 132 well-known computer security

techniques , 2 National programs

awareness , 192 collection , 161–162 commonality , 107–108 correlation , 176–177 deception , 49–50 depth , 126–127 discretion , 143–144 diversity , 87 implementation of principles ,

28–29 response , 206 , 206f separation , 71–72

Need questions, TCB , 132 Netfl ow , 148 Network-based fi rewalls

and cloud computing , 15 DDOS fi ltering , 60 as fi rewall approach , 52 layered access controls ,

121–122 national separation program ,

71–72 separation enhancements , 14 simple/complex , 52f

Network data collection , 148–150 SIEM threat management , 168

Network perimeter, and defense layers , 20

Network routes, diversity issues , 85

Network service providers data collection , 171 network monitoring , 171

Network technology diversity , 82–84 and worms , 83f

Network transmission, encryption methods , 123

Nondefi nitive conclusions, vulnerability information management , 185

Nonuniformity, and infrastructure simplifi cation , 101

Obscurity layers discretion principle , 139–141 examples , 140f leaks , 141 national discretion program ,

144 Obviousness, and infrastructure

simplifi cation , 100 Off-the-shelf fi rewalls , 14 One-to-many communication,

botnet detection , 173 Online access, security policy ,

96 Open solicitations, deception

discovery stage , 40 Operational challenges

and collection principle , 22–23

and deception principle , 46 incident response , 200 smart device security , 59

Operational confi gurations, and best practices , 18

Operational costs, cyber security principle implementation , 29

Organizational culture incident response , 200 security implementation , 99 security options , 99f security protection , 94–95 ,

97–99

Outages metric, data collection , 151

Out-of-band correlation , 125 Outsourcing

and global threats , 180 incident response , 200 insider separation , 65–66 security operations , 200 security team members , 103 supply chains , 4–5

Packet fi ltering routers, separation principle , 15

Packet-switched technology , 82 Parceling, separation principle ,

15 Past security practice,

responsible , 95 , 106–107 Patching (software and systems),

and best practices , 18 Patterns, national infrastructure

simplifi cation , 102 Payment Card Industry Data

Security Standard (PCI DSS), best practices standards , 90

PCI DSS , see Payment Card Industry Data Security Standard (PCI DSS)

PCs , see Personal computers (PCs)

Permissions vectors, UNIX® , 120

Personal computers (PCs) botnet attacks , 6–7 botnet detection , 172 DDOS attacks , 8 diversity considerations ,

77–80 , 80f and diversity principle , 17 ,

77–80 nondiversity example , 78f system data collection , 150–

151 , 153 , 153f Personally identifi able

information (PII) and discretion principle ,

20–21 and TCB , 130

INDEX 229

Physical attacks, national infrastructure vulnerability , 1–2 , 2f

Physical diversity issues , 85 network technology , 82 satellite data services , 86–87

Physical security, layered access controls , 121 , 122

Physical separation dual-homing example , 65f technique , 63–65

PII , see Personally identifi able information (PII)

PKI tools , see Public key infrastructure (PKI) tools

Plain old telephone services (POTS) , 82

Planning, disaster recovery program , 205

Platforms, diversity costs , 79 Politics

and awareness , 180 and information sharing , 136 national awareness program ,

192 Port scanners, deceptive open

ports , 38 Post-attack vs. pre-attack

response , 195–196 POTS , see Plain old telephone

services (POTS) Power control networks, as

national infrastructure , 1 Practical experience, depth

effectiveness , 111 Practice, disaster recovery

program , 205 Pre-attack vs. post-attack

response , 195–196 Predators, deception-based

tools , 11 Preparation, disaster recovery

program , 205 Prevention

data collection security , 146 front-loaded , 195 past security practice , 107

Privacy policy, and collection principle , 22–23

Procedural controls, and defense layers , 19–20

Process allowance, deception exploitation stage , 44

Process coordination, deception exploitation stage , 44

Procurement discipline and deception principle ,

45–46 national diversity program , 87

Profi le-based correlation defi nition , 163 example , 164f

Proof factors, diversity , 116 Proprietary information

and discretion , 129–130 national depth program , 127

Protected transit, national collection program , 162

Protection condition, deceptive documents , 41

Protections, information reconnaissance , 139

PSTN , see Public switched telephone network (PSTN)

Public key infrastructure (PKI) tools, encryption methods , 123

Public speaking, and obscurity layers , 141

Public switched telephone network (PSTN) , 82

Published case studies, deception discovery stage , 40

Quality issues data collection , 147 data correlation , 169–170 defense in depth , 109 engineering standards , 19

Real assets and bogus assets , 38f , 44 and deception , 31 , 32f , 43 honey pot connection , 201 interfaces and deception , 12f

Real-time analysis botnet attacks , 48 honey pots , 32–33

Real-time awareness implementation , 25 process fl ow , 26f

Real-time observations, deception exposing stage , 47

Real-time risk, situational awareness , 182

Real vulnerabilities, deception scanning stage , 36

Reliability issues, data correlation , 169–170

Remote terminal unit (RTU) , 62 Removal option, PC diversity ,

81 , 81f Replication, asset separation ,

68–69 Requests for Information (RFIs),

deception discovery stage , 40

Requests for Proposals (RFPs), deception discovery stage , 40

Response principle , see also Incident response

cyber security methodology , 11

implementation , 26–28 , 27f past security practice , 107 sample requirements ,

216–217 Return on investment (ROI),

security education , 104 , 104f

Reward structure basic considerations ,

105–106 security teams , 95

RFIs , see Requests for Information (RFIs)

RFPs , see Requests for Proposals (RFPs)

Right-of-way routes, network technology diversity , 83

Risk management process , 188–190

230 INDEX

Risk reduction adversary separation , 53 by asset separation , 68–69 and botnet detection , 174 and cloud computing , 81 cyber security methodology ,

9–11 DDOS attacks , 60 , 69f and deception , 13 , 32 and depth , 19 , 113 by insider separation , 66–67 national separation program ,

72 by network technology

diversity , 84 by physical diversity , 85 by physical separation , 65 principles, national

implementation , 28 Root cause, forensic analysis ,

201 RTU , see Remote terminal unit

(RTU)

Salary , 105 Sarbanes-Oxley controls

consistency principle , 17–18 diversity principle , 74 internal separation , 72

Sasser worm , 76–77 Satellite data services

physical diversity , 86–87 SCADA confi gurations , 86f

SCADA , see Supervisory control and data acquisition (SCADA) systems

Scaling issues, system data collection , 150

Scanning stage deceptive open ports , 38 defi nition , 34 overview , 35–37

Search for leakage, and obscurity layers , 141

“Secret,” and MLS , 70 Secure commerce, encryption

methods , 123 Secure Sockets Layer (SSL),

encryption methods , 123

Security audit vs. best practices , 93 and certifi cation/education ,

102–103 defi nition , 89 infrastructure protection

relationship , 92 meaningful best practices , 92 meaningful vs. measurable

best practices , 91 national commonality

program , 108 organization examples , 90f purpose , 90

Security information and event management (SIEM)

defi nition , 154–156 generic architecture , 154–155 ,

155f generic national architecture ,

156f threat management , 167–168

Security information management system (SIMS), and collection principle , 21–22

Security operations centers (SOC) , see also Fusion centers

high-level design , 191f incident response , 200 responsibility , 192 situational awareness ,

190–191 Security policy

awareness , 103 and certifi cation/education ,

102 and decision-makers , 104 decision process , 97f intrusion detection

correlation , 169f locally relevant and

appropriate , 94–97 Security posture

and activity/response , 182f estimation , 181f intelligence reports , 187

Security standard

defi nition , 89 national commonality

program , 108 Security teams

career path/reward structure , 95

incident response , 198–201 as infrastructure decision-

makers , 103 “Security through obscurity”

and asset vulnerability , 21 defi nition , 133–135 and discretion principle , 21 exploitable fl aws , 134 knowledge lifecycle , 134f objectionable applications ,

133 primary vs. complementary

control , 133–134 Segregation, asset separation ,

69 Segregation of duties

defi nition , 67 work functions , 68f

Senior managers and career path , 106 as infrastructure decision-

makers , 103 Sensitive information, as

security concern , 4 Separation principle , see also

Firewalls asset separation , 68–70 carrier-centric network-based

fi rewalls , 59f cyber security methodology , 9 DDOS fi ltering , 60–61 distributed vs. centralized

mediation , 56f enhancements for national

infrastructure , 14 fi rewall approaches , 51–53 fi rewall enhancements , 15f functional separation , 55–57 implementation , 13–15 insider separation , 65–68 MLS , 70–72 , 71f national infrastructure

fi rewalls , 57–60

INDEX 231

national program , 71–72 objectives , 53–55 overview , 51 physical separation , 63–65 ,

65f sample requirements ,

209–211 SCADA architecture , 62–63 ,

63f techniques , 54–55

Separation vs. segregation of duties , 67

Server complex, honey pots , 39f Server data storage

encryption methods , 123 system data collection , 150–

151 , 153 , 153f Service level agreements (SLAs)

and data quality , 169 national infrastructure

fi rewalls , 59–60 Service ports

bogus assets , 38f and deception , 33–34 , 36f ,

37–39 post-scanning , 38

SIEM , see Security information and event management (SIEM)

Signature-based correlation defi nition , 163 example , 164f

Signature sharing , 125–126 Simple networks, fi rewalls , 52f Simplifi cation , see Infrastructure

simplifi cation SIMS , see Security information

management system (SIMS)

Single sign-on (SSO) initiatives and diversity , 116 layered authentication , 115 national infrastructure , 116

Situational awareness attack confi dence , 184f cyber security posture , 181f defi nition , 179 implementation , 25 and information sharing , 136

infrastructure attack detection , 183–184

intelligence reports , 187 , 188f , 186–188

national correlation program , 177

national program , 192 optimal system usage , 181f real-time risk , 182 risk categorization , 181–182 risk vs. cost decision paths ,

190f risk management process ,

188–190 security operations centers ,

190–191 , 191f vulnerability information

management , 184–186 , 186f

Sizing issues national infrastructure

simplifi cation , 101 security policy , 96 system data collection , 150

SLAs , see Service level agreements (SLAs)

Small-scale vs. large-scale cyber security , 3f , 3

Smart devices fi rewall issues , 58 national infrastructure

protection , 58 protection complexity , 58

SMTP, deceptive open ports , 37–38

SOC , see Security operations centers (SOC)

Software bugs, and honey pots , 37

Software engineering standards , 19

Software lifecycle, and best practices , 18

Software profi les, and awareness , 180

Spam, layered protection , 119–120

Sponsored research, deception discovery stage , 40

SQL/Slammer worm , 76–77 tracking , 159–160 , 160f , 161f

SSL , see Secure Sockets Layer (SSL)

SSO , see Single sign-on (SSO) initiatives

Stalkers, deception-based tools , 11

Standard audit, infrastructure protection , 93

State, forensic analysis , 201 Stream-of-consciousness

design, and infrastructure simplifi cation , 100–101

Subjective estimations, national depth program , 127

Suffi cient detail, deception exposing stage , 47

Suitability, and defense in depth , 112–113

Supervisory control and data acquisition (SCADA) systems

architecture , 62–63 , 63f insider separation , 66 IPoS , 86 , 86f layered access controls , 121 as national infrastructure , 1 national infrastructure

fi rewalls , 57 off-the-shelf fi rewalls , 14 separation principle , 9 tailored separation , 53 , 72

Supplier adversary deception techniques ,

45 , 45f defi nition , 4–5

Suppliers, diversity issues , 17 , 85

Supply chain , 4–5 Support and training, and

desktop diversity , 79 System administration, and best

practices , 18 System administration and

normal usage , 4–5 System data, collection ,

150–154

232 INDEX

Tailored separation as fi rewall approach , 53 national separation program ,

72 Target factor

large-scale correlation , 175 separation techniques , 54

Tarpit , 49–50 TCP/IP , see Transmission

Control Protocol/Internet Protocol (TCP/IP)

TDM , see Time-division multiplexed (TDM) services

Telecommunications collection systems , 22–23 insider separation , 66 as national infrastructure , 1

Terrorist attacks motivation , 5 9/11, physical attack

vulnerability , 1–2 Testing and simulation, depth

effectiveness , 111–112 Theft

deception exploitation stage , 43–44

as security concern , 4 Threat factor

insider separation , 65–66 separation techniques , 54

Threat management and best practices , 18 conventional security

correlation , 167–168 SIEM , 167–168

Time-based correlation defi nition , 165 example , 166f worm detection , 172f

Time-division multiplexed (TDM) services, diversity , 82

Tools and methods, national deception program , 49

Top-secret information disclosure control , 142 , 142f and discretion principle , 20 and MLS , 70

Transmission Control Protocol/ Internet Protocol (TCP/ IP), metadata collection , 148

Transparency and deception , 44 national correlation program ,

177 Transportation infrastructure,

insider separation , 66 Trap functionality, and deception

principle , 11–12 Trap isolation, deception

exploitation stage , 44 Trends, data collection ,

156–159 Trusted computing base (TCB)

basic questions , 132 defi nition , 130–133 discretion program goals ,

130–131 national discretion program ,

143 size issues , 131 , 131f

UDP , see User Datagram Protocol (UDP)

Uncertainty objective, as deception , 32

UNIX®-based operating systems , 120

Usage metric data collection , 151 optimal for security , 181f

Use-case studies, depth effectiveness , 111

User Datagram Protocol (UDP), worm tracking , 159–160 , 160f , 161f

Utilization metric, data collection , 151

Value proposition, national correlation program , 177

Vantage point, centralized security , 58–59

Vendors diversity issues , 85 and diversity principle , 17

Vigilant watch, botnet detection , 173

Violation issues access policies , 20 air-gapped networks , 64 and depth , 109–110 information leaks as , 142 infrastructure protection best

practices , 93 Viruses

attack initiation , 1–2 layered protection , 2f , 119–120 past security practice , 107 and response , 198f and trending , 158 and voice services , 84

Voice services , 83–84 Volunteered data , 24 , 158 , 169 ,

184–185 Vulnerability issues

and awareness , 179 and culture of security , 97 and data collection , 149f and deception , 32 , 36 , 42–44 and deceptive open ports , 38 and defense in depth , 19 disclosure lifecycle , 135f early warning process , 197 honey pot mimics , 40 information management ,

184–186 , 186f information reconnaissance ,

139 national infrastructure , 4–6 and “security through

obscurity” , 133–135 Vulnerability risk advisory , 6

Well-known computer security techniques

and exploitation points , 6 and national infrastructure , 2

Wide area fi rewall aggregation example , 58f technique , 57

Windows®-based operating systems

access control lists , 120 and diversity principle , 74

INDEX 233

PC diversity , 77 , 81 Work functions, segregation of

duties , 67 , 68f World-class focus

infrastructure protection , 93 methodology , 94f national commonality

program , 108 Worms

attack initiation , 1–2 , 2f

cloud computing , 80 and correlation , 167 , 170–172 ,

172f and diversity , 75–77 , 76f functionality , 75 Microsoft® Windows® target ,

78 and network diversity , 82 , 83f past security practice , 107 propagation , 75–77 , 76f , 84f

protection against , 4 and response , 198f as security concern , 4 tracking , 159–160 , 160f , 161f and trending , 158

Worst case assumptions, vulnerability information management , 185