government security rdte&t investments: successes, failures, and the future jacques bus, head of...
TRANSCRIPT
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
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
OutlineOutline
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
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-LinuxPump, Onion Routing, SE-Linux1970 1980 1990 2000 2010 2020
NRL Pump 1993: first paper 1998: JWID prototype 2001: First delivery 2008: 2nd gen
Internet Worm
Product Evaluation Schemes Orange Book Common Criteria
Onion Routing 1996: first paper 1998: prototype up 2003: TOR net up
SE - Linux 1995-8: Flux / Fluke / Flask 1999: begin move to Linux 2001: First SE-L release
MULTICS AIM
Network PumpNetwork Pump
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
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
TrustedLow
Process
TrustedHigh
Process
messages
Stochastic ACKs based on High ACKs’ moving average
messages
ACKs
buffer
Onion Routing (TOR)Onion Routing (TOR)
W
C F
EDA
B
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
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)SE-Linux (NSA)
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
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
MachTmach
1988
B3 target DTOS1995
DTMach1992 - 93
Flux 1995
Flask 1995 - 99
SE-Linux1999 +
Open-Solaris /FMAC - 2007 +
FreeBSD Trusted BSD / SEBSD
2004 +
DarwinSEDarwin
2006 +
LOCK1989
B3 target
XenXSM / Xen Flask
2008 +
Security Product Evaluation SchemesSecurity Product Evaluation Schemes Decades of effort (admittedly not all research) Relatively minor results in terms of impact on security of
marketed products
Decades of effort (admittedly not all research) Relatively minor results in terms of impact on security of
marketed products
Ware Report
Anderson Report:Reference
Monitor Concept
MULTICSAFDSC
MULTICS (AIM)
SCOMP KSOS
NCSCFounded
Orange BookPublished:
TCB Concept
First EvaluationsCompleted
TNI Published
TDI Published
Federal CriteriaFirst Draft
1970 1980 1990
RISOS,PAP Projects
SecurityProfiling
DECVMM
Sec Kernel
Common CriteriaFirst Draft
V. 1.0
2000
Common CriteriaInt. Std.
You are here!
Security R&D Success: Security R&D Success:
Why do you consider this a success?
Pump: Onion Routing: SE-Linux:
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 SuccessElements 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)
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: 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
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 FailureElements 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
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 InvestmentsFuture 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!
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!
OutlineOutline
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
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
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
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 SignaturesCryptography and Digital Signatures1970 1980 1990 2000 2010 2020
US Imposes Strict Export Controls on crypto
Digital Signature EU Directive, and MS transposition
EU Response: Stimulation cross-EU Cryptography R&D
Rijndael algorithm (AES) originates in EU, and accepted as NIST US standard
A European R&D Success Security Crypto (analysis, algorithms)
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.
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 CryptoWhy 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
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 PKIDIGITAL 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
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 SuccessSome 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)
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 Services
underpinning Critical Infrastructures
Users
Trust, accountability, transparency
Identity, privacy and empowerment,
Creativity, Usability
Human values and acceptance
OutlineOutline
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
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)Successes and Failures (in their own time)
Firewalls: Morris worm BGP Security: Numerous incidents
Firewalls: Morris worm BGP Security: Numerous incidents
1970 1980 1990 2000 2010 2020
FirewallsBGP Security
Security R&D Success: Firewalls circa 1989-2000Security 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
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)
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
“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
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 ……
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 FailureElements 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”?
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 InvestmentsFuture 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
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
OutlineOutline
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
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 OverviewSection 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 researchPunch Line: Intrusion is an essential component of any realistic secure
system
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 researchPunch Line: Intrusion is an essential component of any realistic secure
system
IDS Successes in the AbstractIDS 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
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)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
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 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
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 FailuresIDS 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
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 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.
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.
Evolving Networks are Complex
1980 19991970
A Fundamental Question
Is there a science for understanding the complexity of our networks such that we can engineer them to have predictable
behavior?
NetSE: Fundamental Challenges
- Understand emergent behaviors, local–global interactions, system failures and/or degradations- Develop models that accurately predict and control network behaviors
- 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
- 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
Science
Technology
SocietyEnable new applications and new economies, while ensuring security and privacy
Security, privacy,
economics, AI, social science researchers
Network science and engineering researchers
Understand the complexity of large-scale networks
Distributed systems and
substrate researchers
Develop new architectures, exploiting new substrates
Is There a Science of Security?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?
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
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?
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?
App
P
Policy
Rewriter
SecureApp
The Meaning of Defense has ChangedThe Meaning of Defense has Changed
1st Generation1st Generation(Prevent Intrusions)
‘80s
2nd Generation2nd Generation(Detect Intrusions, Limit Damage)
‘90s
Some Attacks will Succeed
Intrusions will Occur
44thth Generation in ‘10s 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)
“Intel” Will Direct Defenses
3rd Generation(Operate Through Attacks)
‘00s
A Problem to Motivate IDS ResearchA 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?
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?