Secure software and COTS group

Steve Gribble, Somesh Jha, Angelos Keromytis, Carl Landwehr, Peter Lee, Martin Rinard

Workshop on Resilient Financial Information Systems March 2005

Findings

Smaller companies use COTS, but some larger companies do extensive in-house development

IT/business opportunities are often unique advantages in fast custom response

Strong trend towards highly componentized software systems

reinforced by trend towards web services

Major issue is complexity not just of large system of components but also of multiple interacting systems, many of

which not under control

Findings, cont’d

Financial systems are “over-engineered” wrt controls

required security level is not well understood, so systems are built conservatively

Human errors are main source of failure By operators, developers, users not security break-ins

but impact of errors can be magnified by security weakness

reconciliation checks, redundancy, distributed component-based architecture greatly enhance resilience

Findings, cont’d

Confidentiality is less understood concept of “toxic combinations of privilege” manual review of privilege combinations a form of business-rule discovery

Some similarities to military, pharmaceutical, etc. environments

HCI is a big deal and growing but lots of expertise and resources applied

and apparently working

Findings, cont’d

“Business control requirements” The rules by which automated

system must operate

“Application security requirements”

traditional authentication/authorization requirements, for components and systems of components

Research themes

Centrality of business rules

Challenge of “bringing it all together”

Smooth slope / starting out small

Possible research areas, 1

Specification languages for describing / modeling business rules

work at the semantic level of business control rules

checking that a distributed collection of components respects the global rules

static verification dynamic monitoring

component abstraction; and analysis of composed abstractions

Possible research areas, 2

Access control consequence analysis

do the privileges satisfy given business controls?

analogy to model checking

optimization of access controls? tradeoff with run-time checking

change analysis how to additions/changes affect the

system?

Possible research areas, 3

Interactive debugging / root-cause analysis

unify low-level (code failure) and high-level (business-rule violation) views of failures

for debugging, root-cause analysis

human-assisted and/or automated reaction

traceability of low-level behavior and test results to high-level requirements

What about COTS?

Um,…