Скачать презентацию Government Security RDTE T Investments Successes Failures and the Скачать презентацию Government Security RDTE T Investments Successes Failures and the

60caee8d79ab87b6fda950dcf2103edf.ppt

  • Количество слайдов: 43

Government Security RDTE&T Investments: Successes, Failures, and the Future Jacques Bus, Head of Unit: 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 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 MULTICS AIM 1980 1990 Internet Worm Product Evaluation Schemes Pump, Onion Routing, SE-Linux 1970 MULTICS AIM 1980 1990 Internet Worm Product Evaluation Schemes Orange Book Common Criteria 2000 2010 2020 SE - Linux 1995 -8: Flux / Fluke / Flask 1999: begin move to Linux 2001: First SE-L release Onion Routing 1996: first paper 1998: prototype up 2003: TOR net up NRL Pump 1993: first paper 1998: JWID prototype 2001: First delivery 2008: 2 nd gen

Network Pump Trusted Low Process messages Stochastic ACKs based on High ACKs’ moving average Network Pump Trusted Low Process messages Stochastic ACKs based on High ACKs’ moving average buffer messages Trusted High Process 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 A W C D F E § Web browsing with Onion Routing (TOR) B A W C D F E § 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) Mach Tmach 1988 B 3 target 1989 B 3 target SE-Linux DTMach SE-Linux (NSA) Mach Tmach 1988 B 3 target 1989 B 3 target SE-Linux DTMach LOCK Xen XSM / Xen Flask 2008 + 1999 + 1992 - 93 Flask DTOS 1995 - 99 1995 Flux Free. BSD Open-Solaris / Trusted BSD / SEBSD 2004 + FMAC - 2007 + 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 § Decades of effort (admittedly not all research) § Relatively Security Product Evaluation Schemes § Decades of effort (admittedly not all research) § Relatively minor results in terms of impact on security of marketed products TDI Anderson Report: Reference Monitor Concept RISOS, PAP Projects Ware Report 1970 TNI Orange Book Published: Published TCB Concept MULTICS AFDSC MULTICS (AIM) Federal Criteria First Draft Common Criteria First Draft V. 1. 0 NCSC Founded 1980 SCOMP KSOS Published 1990 DEC First VMM Evaluations Sec Kernel Completed 2000 Security Profiling You are here! Common Criteria Int. Std.

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

Elements of Success § Common Factors: § Government focus and investment over an extended 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 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 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 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 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 FP 7 Framework programme 7 (FP 7) for EC Introduction EU Research Funding under FP 7 Framework programme 7 (FP 7) 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 US Imposes Strict Export Controls on crypto 1990 Cryptography and Digital Signatures 1970 1980 US Imposes Strict Export Controls on crypto 1990 2000 2010 2020 EU Response: Stimulation cross-EU Cryptography R&D 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 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 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 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, 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 § § Future Challenges for EU RTD for a Trustworthy Information Society § Technology § § § Cyber-threats, cyber-crime The Future of the Internet Complex ICT Systems and Services underpinning Critical Infrastructures § Users § § Trust, accountability, transparency Identity, privacy and empowerment, Creativity, Usability Human values and acceptance

Outline § Network, Traffic, and Host-Level Security –Carl Landwehr § Cryptography and Digital Signatures 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

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

Security R&D Success: Firewalls circa 1989 -2000 § Network devices which enforce an organization's Security R&D Success: Firewalls circa 1989 -2000 § Network devices which enforce an organization's security policy § History § Late 1980 s: 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 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): 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 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? § 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

Outline § Network, Traffic, and Host-Level Security –Carl Landwehr § Cryptography and Digital Signatures 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

Section Overview § § IDS Successes in the abstract IDS Product Successes IDS Failures 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 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 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. , DDo. S

IDS Product Successes § Signature-based IDS: Use signature optimization methods from research community § IDS Product Successes § Signature-based IDS: Use signature optimization methods from research community § Anomaly Detection Systems: Especially for highspeed 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 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) § $45 M/year § Deeper and broader than CT § Five Trustworthy Computing (TC) § $45 M/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 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 (Net. SE); TC, Data Intensive Computing: Cross-Cutting vs. Core § Network Science and Engineering (Net. SE); TC, Data Intensive Computing: cross-cutting § Network Technology and System (Ne. TS): core § Net. SE 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. § Ne. TS 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.

Evolving Networks are Complex 1970 1980 1999 Evolving Networks are Complex 1970 1980 1999

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

Net. SE: Fundamental Challenges Science Understand the complexity of large-scale networks - Understand emergent Net. SE: Fundamental Challenges Science Understand the complexity of large-scale networks - Understand emergent behaviors, local–global interactions, system failures and/or degradations - Develop models that accurately predict and control network behaviors Technology Develop new architectures, exploiting new substrates - 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 Society Enable new applications and new economies, while ensuring security and privacy - 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 Network science and engineering researchers Distributed systems and substrate researchers Security, privacy, economics, AI, social science researchers

Is There a Science of Security? § Are there impossibility results? § Are there 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?

Enforcement by Program Rewriting? Fred Schneider § Fundamental issues: § Does the application behave 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 App P App Rewriter

The Meaning of Defense has Changed 1 st Generation (Prevent Intrusions) ‘ 80 s The Meaning of Defense has Changed 1 st Generation (Prevent Intrusions) ‘ 80 s Intrusions will Occur 2 nd Generation (Detect Intrusions, Limit Damage) ‘ 90 s Some Attacks will Succeed 3 rd Generation (Operate Through Attacks) ‘ 00 s 4 th Generation in ‘ 10 s (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) “Intel” Will Direct Defenses

A Problem to Motivate IDS Research Suppose an adversary inserts malicious logic into a 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?