Emerging threats and countermeasures

Cyber At tacks

“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)

Cyber At tacks 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

NetworksSupplier 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 ManagersCollection

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 ).