only Software Assurance: The V Way Ahead

1
only?Software
Assurance The V Way Ahead
2009 IEEE Joint Chapters Meeting
Speaker Ramesh Bharadwaj Center for High
Assurance Computer Systems Naval Research
Laboratory Washington DC 20375 USA Tel
1-202-767-7210 Email ramesh_at_chacs.nrl.navy.mil
2
Medieval Cathedrals

• Medieval builders had to create buildings on
  a huge scale without access to labor- saving
  devices such as cranes and hoists.
• Building skills were highly valued and trade
  secrets were often only available to building
  guild members or passed from father to son.
• Walls often had to be rebuilt since the
  mortar would not set properly, especially in
  bad weather, and stones would crumble and
  collapse.
• Few craftsmen had the satisfaction of seeing a
  cathedral finished in their lifetime.

Cathedrals would take generations to complete
3
La Sagrada Familia, Barcelona
Construction started in 1882 yet to be completed
4
Windows Vista, Redmond WA

• Todays programmers have to build software on
  a huge scale without access to labor- saving
  devices such as tools for automated program
  analysis, refactoring, synthesis, or
  visualization.
• Programming skills are highly valued and trade
  secrets are often only available to mavericks
  or passed from chief programmer to her interns.
• Programs often have to be rebuilt since the
  they usually are buggy, especially when used,
  and systems are prone to frequent crashes or
  data corruption.
• Few programmers have the satisfaction of seeing
  a piece of software finished in their lifetime.

5
MacOS X, Cupertino CA
6
Two ways to design
The Turing Award winning Computer Scientist Prof.
Tony Hoare once said
There are two ways of constructing a software
design. One way is to make it so simple that
there are obviously no deficiencies. And the
other way is to make it so complicated that there
are no obvious deficiencies.
7
Murphy
Murphys Law If anything can go wrong, it will
Corollary If there are many ways for a system to
behave, the exhibited behavior will be the
wrong(-est) one
8
Contrarian View Good Enough is Better
A system that is good enough is better than the
perfect system

• It is impossible (or impractical) to build
  correct systems, so all practical systems need to
  be imperfect
• Corollary Commercial forces will always strive
  towards imperfection
• Example Secure Computer Systems
• What if there are no computer viruses?
• What if there is no spam?
• What if there is a secure operating system?

9
Secure Systems Oxymoron?
All systems are (and will ever be) insecure

• Because good enough is better, security will
  always remain a lucrative business
• Corollary Being in the Security Business is
  guaranteed Job Security
• Examples
• Anti-virus and anti-spyware tools
• Spam filters and Firewalls
• Code vulnerability analyzers

10
Security Industry an Oxymoron?
The Security Industry (including Pundits) does
not like secure systems
Industry will never deliver a secure
system Corollary Building a Secure System will
put the Security Industry out of
business Examples Microsoft, McAfee, Bruce
Schneir
11
Is there hope?
Government Regulation
Government Regulation could put an end to this
state of affairs But, is there political
will? Corollary Government Regulation can call
the bluff of the Security Industry Examples
Locks, Safes, Cell Phones
12
What is SINS?(Secure Infrastructure for
Networked Systems)
Originally Presented at COMPSAC 2005, Edinburgh,
UK
13
Technical Challenge

• Science for Global Ubiquitous Computing (GUC)
• Excerpt from Grand Challenges in Computing --
  ResearchEdited by Tony Hoare and Robin Milner
• System and software architectures for large
  software-intensive systems formed by ad hoc
  networks of heterogeneous components
• Models to support evolution, adaptive behavior,
  loose coupling, autonomy, context-awareness,
  learning, security.
• Calculi and logics for notions of mobility, self-
  and context awareness
• Predictive theory for hybrid systems, e.g.,
  sensor networks
• Stochastic models that provide for compositional
  probabilistic analyses
• Knowledge, trust, security, and privacy Models
  for the acquisition, distribution, management,
  and sharing of information and trust
• Isolation of language features appropriate to GUC
• Algorithms for coordination, cooperation and
  autonomy
• Software technology and design support tools
• Verification techniques and technology

SINS Secure Agents IA Arch. SOL SOLver
14
Extant and SINS Approaches toSystem Construction
Extant Approaches
SINS Approach
15
Reconfigurability
16
Agent-Based Approach forDistributed Systems
Development
Feature Requirements
Requirements in
Natural Language
Ontologies of
Ontologies of
Decomposed and
Decomposed and
Validated and
Security Policies
Security Policies
Verfied Policy Sets
Ontologies of
Ontologies of
Verfied Policy Sets
Verified Secure Agents
Formalization
Security Policies
Security Policies
Security Policy
Security Policy
Formal
Specifications
Specifications
Specification
Formal Models
17
Advantages of Proposed Approach

• Agents (middleware components) designed and
  verified independently
• Model-driven synthesis of implementation from
  requirements and available agents
• No need to reprogram middleware infrastructure to
  add functionality
• Adaptability Can transform cathedral into a
  chapel
• Example Agents

Security
Situation-awareness
Reconfiguration
Fault-tolerance
18
Traditional Approaches to Information Assurance
(IA)

• Signature based methods
• Host checks applications digital signature to
  verify authenticity and for selection of
  appropriate policy
• Host must trust producer of code to provide
  guarantees
• Confinement based methods
• Applications are run in a sandbox which
  prevents system calls that would lead to
  violations of host policy
• Enforceable security policies are limited to
  invariants and sandboxes are not easily
  reconfigured
• Also, information leaks (e.g., steganography) are
  not detectable

Unlike these approaches, ours is based on formal
verification
19
SINS Approach to IA
VerificationEngine (Salsa)
Policy Repository
Agents

• Verification may be undecidable
• Enforcement fallback requires that policy
  be in enforceable class

Yes
No
EnforcementMechanisms
DeploymentInfrastructure
20
Policy Enforcement Security Agents
SECURITY AGENTS
APPLICATION-SPECIFIC AGENTS
CRYPTO ASSIST AGENTS
MONITORING AGENTS

• intrusion detection
• application monitoring
• survivability
• infrastructure monitoring

POLICY ENFORCEMENT AGENTS
AUTHORIZATION AGENTS
Security Agents act as mini-firewalls between an
application and the OS resources.
21
Long-Term Vision Interoperability over
Multiple-Security Levels
App
App
Secure Operations Layer
AND
AND
AND
AND
Secure Spread Middleware
TS
S
U
S
Legend
AND
Secure agent
Security Agent
Application
App
22
What we have right now.
Application
SINS Distributed deployment framework for Agents

• Secure Spread Provides
• Access Control
• Confidentiality (secure multicast)
• Virtual synchrony
• Replication and persistence (NRL extensions to
  JHU Spread)

• Secure Operations Layer Provides
• Secure Distributed Active Components
• Synchronous semantics (correctness)
• Location transparent publish/subscribe
• Asynchronous service invocation

23
Control Panel
S P R E A D
Agent Repository
SINS Virtual Machine 1
Deploy
Safety Injection
S P R E A D
S P R E A D
Water Pressure
SINS Virtual Machine 3
Deploy
SINS Virtual Machine 2
Deploy
Control Panel
Water Pressure
Safety Injection
DACs
Repository URL http//10.0.6.348080/safety_injec
tion.jar
24
Long-Term Challenges

• Adapt SINS to diverse application domains
• Customize for operation over disadvantaged
  networks and limited platforms
• Scale to hundreds of thousands of network nodes
• Design Patterns for explication and ease-of-use
• Programming language support with rich behavioral
  type systems
• Tightly integrate development environment, design
  patterns, deployment platform, with program
  analysis and transformation tools, to provide a
  distributed computing toolkit for the
  application developer

25
END