Government Security RDTE&T Investments: Successes, Failures, and the Future

Government Security RDTE&T Investments: Successes, Failures, and the Future Jacques Bus, Head of Unit: Security-ICT Programme European Commission Carl Landwehr, Program Manager, IARPA Karl Levitt, Cyber Trust Program Director, National Science Foundation Doug Maughan, Program Manager of Cyber Security R&D, S&T of DHS Moderator: Rob Cunningham, Assoc. Group Leader, MIT Lincoln Lab

Outline • Network, Traffic, and Host-Level Security –Carl Landwehr • Cryptography and Digital Signatures –Jacques Bus • Perimeter Defense and Critical Internet Infrastructure –Doug Maughan • Intrusion Detection and Beyond –Karl Levitt

Pump, Onion Routing, SE-Linux 1970 1980 1990 2000 2010 2020 MULTICS AIM SE - Linux 1995-8: Flux / Fluke / Flask 1999: begin move to Linux 2001: First SE-L release Internet Worm Onion Routing 1996: first paper 1998: prototype up 2003: TOR net up Product Evaluation Schemes Orange Book Common Criteria NRL Pump 1993: first paper 1998: JWID prototype 2001: First delivery 2008: 2nd gen

Network Pump messages messages buffer Trusted High Process Trusted Low Process Stochastic ACKs based on High ACKs’ moving average ACKs • Reliable one-way flow device to support safe flows from low to high networks • Research drew on: • Security modeling • Covert channel modeling and analysis • Assurance arguments • More than 150 produced • New generation system under development

Onion Routing (TOR) B C F A D E W • Web browsing with protection against traffic analysis • Research drew on: • Cryptography • Chaum mixes • Internet protocols, proxies • Prototyped, redeveloped as open source • Globally available, widely use

SE-Linux (NSA) Xen XSM / Xen Flask 2008 + SE-Linux 1999 + DTMach 1992 - 93 Tmach 1988 B3 target Mach Flask 1995 - 99 FreeBSD Trusted BSD / SEBSD 2004 + Open-Solaris / FMAC - 2007 + DTOS 1995 LOCK 1989 B3 target Flux 1995 Darwin SEDarwin 2006 + • Add MAC to Linux via loadable kernel module • Research drew on: • Extensive prior OS prototyping work • Security modeling for type enforcement • Motivated insertion Loadable Security Module mechanism into Linux kernel distribution • Availability and use still growing

Security Product Evaluation Schemes TDI Published TNI Published Orange Book Published: TCB Concept Anderson Report: Reference Monitor Concept Federal Criteria First Draft RISOS, PAP Projects Common Criteria First Draft V. 1.0 NCSC Founded Ware Report 1980 1970 1990 2000 SCOMP KSOS MULTICS You are here! DEC VMM Sec Kernel AFDSC MULTICS (AIM) First Evaluations Completed Security Profiling Common Criteria Int. Std. Decades of effort (admittedly not all research) Relatively minor results in terms of impact on security of marketed products

Security R&D Success: Why do you consider this a success? Pump: Onion Routing: SE-Linux: • Meets a real security need • Exploits real research results • Wouldn’t have happened • without govt. R&D funding

Elements of Success Common Factors: Government focus and investment over an extended period Active technical involvement of government laboratory personnel Interaction with broader technical community through peer review and in other ways Technical transfer advocate within government Open availability of results Open source as a tech transfer path (two out of three)

Security R&D Failure: Evaluation remains a labor-intensive process Outcomes are uncertain Most of the market ignores it The effort put into the evaluation process frequently has little or no effect the security of the product

Elements of Failure Factors: It’s a hard technical problem Security properties are hard to define or measure “market for lemons” problem Government market leverage has declined Government has had trouble applying the leverage it does have

Future Investments What’s critical for success? Identifying the right problem to attack where we want to get to (first) transition path (second) Passionate advocates Endurance An area that a government should invest in and why? There are many -- discuss!

Outline Network, Traffic, and Host-Level Security –Carl Landwehr Cryptography and Digital Signatures –Jacques Bus Perimeter Defense and Critical Internet Infrastructure –Doug Maughan Intrusion Detection and Beyond –Karl Levitt

Introduction - EU Research Funding under FP7 Framework programme 7 (FP7) for EC Research 2007-13 • Budget Cooperative Research: 32,413 Mi€ (7 yr) • ICT (incl ICT security): 9,050 Mi€; Security (multidisc): 1,400 Mi€ • Trustworthy, secure ICT ~ 50 Mi€/yr Conditional environment • Workprogramme gives broad research scope definition per area;is updated every 1 or 2 years • Proposals selected on quality and potential impact within this scope • Only multi-partner projects: Industry / Academia • 50-75% funding maximum • IPR owned by creator • Obligation to share project IPR with partners; also background under normal commercial conditions

Cryptography and Digital Signatures 1970 1980 1990 2000 2010 2020 EU Response: Stimulation cross-EU Cryptography R&D US Imposes Strict Export Controls on crypto Rijndael algorithm (AES) originates in EU, and accepted as NIST US standard Digital Signature EU Directive, and MS transposition

A European R&D Success Security Crypto (analysis, algorithms) • 1996 US imposed strict export controls on crypto; Internationally only weak encryption (DES) possible • EU funding and stimulation of integration of EU research started mostly in 1999 • Success of EU originating Rijndael Algorithm (NIST standard AES in 2001) • The EU position in Crypto analysis and algorithms has moved from fragmented to world class. EU no longer subservient to other nations.

Why the EU success in Crypto • Strong, though fragmented EU academic basis existed in mathematical number theory • Strong public and market need for end-to-end security in the emerging digital age • International situation and EU strategic positioning and demands • Strengths of collaborative research programme (multi Member State) in EU • Timely take-up in ICT Workprogramme

DIGITAL Signatures and PKI Clear drive and expectations in end 90’ies • Directive 1999/93/EC of 13 December 1999 on a Community framework for electronic signatures • Related to funded and delivering research, which went on (i.p. on PKI’s) during 2000-2005. Why did it not take up? • Complications with EU MS law implementations • 1-n PKI infrastructure led to need of trusted providers which did not interoperate • Complicated deployment under different OS’s and company rules • Society not ready: technology not trusted, user-unfriendly

Some Conditions for Success • WP development in good consultation with the field (academia, industry and public service) • Ensure involvement of all important players • Projects to give attention to research as well as deployment opportunities and market readiness • Projects to include commitment of various parties in the innovation cycle (from research to users) • Need for realistic data to ensure effective research (problem in RTD for CIP, due to reluctance of making data available)

Future Challenges for EU RTD for a Trustworthy Information Society • Technology • Cyber-threats, cyber-crime • The Future of the Internet • Complex ICT Systems and Servicesunderpinning Critical Infrastructures • Users • Trust, accountability, transparency • Identity, privacy and empowerment, • Creativity, Usability • Human values and acceptance

Successes and Failures (in their own time) 1970 1980 1990 2000 2010 2020 • Firewalls: Morris worm • BGP Security: Numerous incidents BGP Security Firewalls

Security R&D Success: Firewalls circa 1989-2000 • Network devices which enforce an organization's security policy • History • Late 1980s: USG funding initiated (based somewhat on the Morris worm) • Early 1990’s: First deployments (AT&T, White House); FWTK open-sourced • Mid-Late 1990’s: First commercial products available

Elements of Firewall Success (at least during its success peak) • “First” example of an entire “market maker” in the information security area • Spawned numerous companies and supporting technologies • Government investments: Accelerated the interest in the use of firewalls • Commercial interest in security • WWW: Birth of the Web created an easier environment for adversaries

Security R&D Failure (so far): BGP circa 1989-2008 • Border Gateway Protocol (BGP): • to exchange network reachability information between autonomous systems and from this information determine routes to networks • 1989: RFC 1105 – June 1989 • Created based on Internet transition to Autonomous Systems • Subsequent versions • BGP-2 (RFC 1163 - 6/90), BGP-3 (RFC 1267 - 10/91), BGP-4 (RFC 1654 – 7/94; RFC 1771-1774 – 3/95) • Securing BGP • Secure BGP (BBN): 1998-2003 • Secure Origin BGP (Cisco): 2000-2004 • Many others ……

Elements of Secure BGP Failure • Adding security to infrastructure protocols is VERY difficult • Customer: Who is the actual “end customer” – ISPs or routing vendors or network engineers?? • ISPs don’t ask for secure products until end consumers complain about security issues • Routing vendors don’t add security into their products until ISPs request those capabilities • Network engineers don’t have a loud enough voice • Bottom Line: Who’s responsible for getting security into the global infrastructure? • Will recent DEFCON attack demonstrations have any impact on the “key BGP players”?

Future Investments • What’s critical for success? • What should researchers think about? • Researchers need to consider the end customer/consumer when doing their research (otherwise it may never be used) • What should future PMs consider? • Research programs need to be full spectrum – not just research, but research, development, test, evaluation, AND transition • An area that a government should invest in and why? • http://www.cyber.st.dhs.gov/documents.html

Section Overview IDS Successes in the abstract IDS Product Successes IDS Failures Trustworthy Computing: Successor to Cyber Trust; NSF’s future investments in security Towards an architecture that builds on IDS Evaluation of IDSs: part of a Science of Security A problem to motivate future IDS research Punch Line: Intrusion is an essential component of any realistic secure system

IDS Successes in the Abstract Different kinds of IDS: Signature-based Anomaly detection Specification-based detection Generic intrusion detection and situation-specific Host-based Network-based Wireless networks/protocols, e.g., Skype Sensor networks To detect spam To detect misconfigured BGP systems To detect misbehaving routers … Languages to specify and optimize signatures

IDS Successes in the Abstract (more) Composition of IDSs, e.g., for scenario attacks Layering of intrusion detection systems, e.g., for monitoring protocol stack IDMEF/CDIF: Languages to share intrusion reports Beyond intrusion detection: Intrusion tolerant systems False positives/negatives and ROC as the basis for evaluating IDSs Lincoln Lab test data and evaluation exercise Towards IDSs for high-speed networks, largely based on multi-processing Towards a response to attacks; e.g., DDoS

IDS Product Successes Signature-based IDS: Use signature optimization methods from research community Anomaly Detection Systems: Especially for high-speed networks; multi-processor systems IDS + Firewall: Generates FW rule from anomaly detector Bot-Killer: Detects “incomplete” packet traffic

IDS Failures Little progress on IDS to detect malicious insiders Very little progress towards analytical evaluation Possible exception: Roy Maxions’s IDS to identify purveyor of keystrokes Beyond Lincoln Lab exercise, very little progress towards an experimental methodology for IDS Little progress towards a security architecture for which IDS is a component Very few textbooks

Trustworthy Computing (TC) • $45M/year • Deeper and broader than CT • Five areas: • Fundamentals: new models that are analyzable, cryptography, composability (even though security is not a composable property), new ways to analyze systems • Privacy: threats to privacy, surely metrics, privacy needs security, privacy might need regulation, database inferencing, tradeoffs between privacy and x

Trustworthy Computing (TC) (cont’d) • Usability: for home user (parent wanting to keep files from child), security administrator (who is overloaded), forensics • Security Archicture: much of what CT has funded; currently we have point solutions, so we need to combine them • Evaluation: especially experimental, testbed design, looking for research needed for better testbeds but also to use testbeds, data (sanitized) to support experiments

Cross-Cutting vs. Core • Network Science and Engineering (NetSE); TC, Data Intensive Computing: cross-cutting • Network Technology and System (NeTS): core • NetSE Encourages all communities to engage in integrative thinking to advance, seed, and sustain the transformation of networking research to enable the socio-technical networks of the future. • NeTS Supports the exploration of innovative and possibly radical network architectures, protocols, and technologies – for wired and/or wireless environments – that are responsive to the evolving requirements of large-scale, heterogeneous networks and applications.

EvolvingNetworks areComplex 1980 1999 1970

A Fundamental Question Is there a science for understanding the complexity of our networks such that we can engineer them to have predictable behavior?

Understand the complexity of large-scale networks Network science and engineering researchers Science - Understand emergent behaviors, local–global interactions, system failures and/or degradations- Develop models that accurately predict and control network behaviors Develop new architectures, exploiting new substrates Distributed systems and substrate researchers Technology - Develop architectures for self-evolving, robust, manageable future networks- Develop design principles for seamless mobility support- Leverage optical and wireless substrates for reliability and performance- Understand the fundamental potential and limitations of technology Enable new applications and new economies, while ensuring security and privacy Society Security, privacy, economics, AI, social science researchers - Design secure, survivable, persistent systems, especially when under attack - Understand technical, economic and legal design trade-offs, enable privacy protection - Explore AI-inspired and game-theoretic paradigms for resource and performance optimization NetSE: Fundamental Challenges

Is There a Science of Security? • Are there impossibility results? • Are there powerful models (like Shannon’s binary symmetric channel) so that realistic security and privacy properties can be computed? • Is there a theory that enables: • Secure systems to be composed from insecure components, or even • Secure systems to be composed from secure components • Is there a theory such that systems can be ordered (or even partially ordered) with respect to their security or privacy? • Are there security-related hypotheses that can be validated experimentally? • What kind of an instrument (testbed) is needed to validate such hypotheses?

App Enforcement by Program Rewriting?Fred Schneider • Fundamental issues: • Does the application behave the same? • Can the application subvert enforcement code? • Pragmatic issues: • What policies can be enforced? • What is the overhead of enforcement? Policy Secure P App Rewriter

Intrusions will Occur Some Attacks will Succeed “Intel” Will Direct Defenses The Meaning of Defense has Changed 1st Generation (Prevent Intrusions) ‘80s 2nd Generation (Detect Intrusions, Limit Damage) ‘90s 3rd Generation (Operate Through Attacks) ‘00s 4th Generation in ‘10s (E.g.,prediction of vulnerabilities, cross-enterprise negotiation before attacks, real-time reverse engineering of attacks and malware, planning methods to deal with expected attacks, automatic patching)

A Problem to Motivate IDS Research Suppose an adversary inserts malicious logic into a program that controls a critical process. Can the presence of the malicious logic be reliably detected? Jim Gossler, Sandia Corp. Possible solutions: • Determine by proof that the program does more than intended; requires a specification • Monitor the behavior of the program with respect to a specification. • What if the adversary knows the specification? • What if the adversary knows details of the monitoring system?

Government Security RDTE&T Investments: Successes, Failures, and the Future