Assert4soa 2nd cluster meeting

1

Ernesto [email protected]

Università degli Studi di Milano

You live in a certified house,you drive a certified car,why would you use an uncertified service?

• SAP• Università degli Studi di Milano• Engineering Ingegneria Informatica• SIT - Fraunhofer Institute• City University of London• University of Malaga• Fondazione Ugo Bordoni

2

Talk Talk outlineoutline

●ASSERT4SOA in a nutshell

●Ongoing work, open problems, and (hopefully) some sharable ideas●Next Exit: The Future

Doctoral School – Security Patterns for ITC Infrastructures, March-April 2011

3

MotivationMotivation (I)(I)

● Emerging paradigms like Cloud and SaaS are reviving the notion of open service ecosystem• Toward service virtualization : Invocation paradigm no longer

an issue, security and reliability more an issue than ever.

• Toward service communities: no single open-to-all service registry, but several large ones managed by cloud providers and/or communities

● This ongoing evolution of SOA requires re-thinking of testing and verification methodologies.

● Our two foundational ideas:• Make documentation of assurance available at run time to

increase users’ confidence and enable assurance-aware service composition

• Sign such documentation. Certification can play a role to establish a trust model suitable for service ecosystems

BSME 20

4

ModifiedModified TrustTrust

● Modified trust model of software assurance documentation with certification

BSME 20

5

MotivationMotivation (II)(II)

● Existing certification techniques and protocols not suitable for services• Defined for traditional monolithic software components

• Provide engineers in charge of software procurement with human-readable evidences signed by a trusted third party

● Service-oriented certification techniques and protocols• Requires dynamic and machine-readable certificates• Should be integrated in run-time service selection and

composition processes

BSME 20

6

ASSERT4SOA GOALSASSERT4SOA GOALS

● Produce novel techniques and tools for expressing, assessing and certifying security properties for complex service-oriented applications

● Integrate certification in the SOA lifecycle

● Extend SOA infrastructure for certificate-based selection and comparison of services

7

Service DiscoveryASSERT Aware

ServiceConsumer

Service

1. Register

2. Lookup

4. Interact

Existing Component

ASSERT ComponentASSERT Component

Digital World

Physical WorldASSERT4SOA visionASSERT4SOA vision

Service Discovery

ServiceConsumer

Service

1. Register

Certification SchemesCertifiers

(CC, SAS70, SOA Specific..)

2. Lookup

3. Interact

Certification

Current SituationCurrent Situation

Requested AssuranceProperties

ASSERT

Certificate Administration Point




Certificate Decision Point


ASSERT Accredited Authority

ASSERT Accredited Authority

ASSERT

ASSERT

3. Evaluate properties

0. Deliver ASSERT

Certification SchemesCertifiers

(CC, SAS70, SOA Specific..)



ASSERT4SOA VisionASSERT4SOA Vision

8

ASSERT4SOA Certification ClassesASSERT4SOA Certification Classes

● Evidence-based certification provides evidence-based proofs that a test carried out on the software has given a certain result, which in turn shows (perhaps with a certain level of uncertainty) that a given property holds for that software

● Model-based certification provides formal proofs that an abstract model (e.g., a set of logic formulas, or a formal computational model such as a finite state automaton) representing a software system holds a given property

● Ontology-based certification provides a solution to issue an ASSERT4SOA certificate starting from the certificates of a given software product (e.g., Common Criteria)

9

Certificate Evaluation PointCertificate Evaluation Point



ASSERT AccreditedAuthority

ASSERT AccreditedAuthority



Service DiscoveryASSERT Aware

ServiceConsumer

ASSERT

ASSERT



ASSERT4SOA CertificationASSERT4SOA Certification

Models

EvidenceReasoner Ontology

Ontology Reasoner

10

Ongoing work, open problems and (hopefully) sharable ideas

11

WhatWhat shallshall wewe certifycertify??

● Security properties (a.k.a. generic security requirements) for the service under evaluation (e.g., Confidentiality, Integrity, Authenticity)• Maybe reliability and dependability

● Need a top ontology of such properties• Coordinated effort with Ed Fernandez’s NSF

project on reliability


12

Linking security properties to security mechanismsLinking security properties to security mechanisms

● Problem 1: abstract security properties are mostly expressed as requirements at the service (or container) design time• Links to service features and mechanisms are seldom specified

• No SLA-style metadata for run-time negotiation of security or reliability features


13

Linking security properties to security mechanismsLinking security properties to security mechanisms

• An idea: an ontology of concrete properties , i.e. abstract properties enriched with a set of “class attributes”: test-generation or formal model of security mechanisms, adversarial model, etc..

• Domain of each attribute has a partial/total order relationship

• Example: confidentiality property on service requests/responses, with a DES algorithm and a key length of 128 bits, adversarial model: can read channel.

• Concrete properties are testable or verifiable at t he service or container level.


14

MappingMapping propertyproperty certificatescertificates to to servicesservices

● Problem 2: security mechanisms are not in a one-to-one relationship with service endpoints• Current security standards are usually implemented at container

level (e.g., Rampart)

• Individual services may have their own implementations to be used in addition or as an alternative to container-level mechanisms

• BTW: services are not even in a one-to-one relationship with their endpoints (especially on cloud, see later)


15

SOME SHARABLE IDEASSOME SHARABLE IDEAS

● Testing and formal methods for certified WS security• With classic WS security standards and patterns as building blocks,

develop assurance mechanisms supporting the certification of basic security properties for individual Web services and for service containers. Such assurance mechanisms can be based on (model-based) security testing and on formal methods.

● Run-time selection of secure services. • Replacing the traditional “red line” between the caller - e.g., a BPEL

engine - and the callee with a mechanism capable of checking customized assurance policies, we support different isolation and protection mechanisms.

• Also, we select accountability and recovery mechanisms at run-time.● Models and techniques for building end-to-end certified business

processes. • Generally speaking, security properties of individual services cannot be

used to infer security properties of a composition they partake. However, such inference can sometimes be drawn when the composition topology is known a priori (e.g., it is a simple orchestration).

• We will investigate a set of domain-specific cases involving different components at different abstraction layers (ranging from secure file system, to financial information control), where it is possible to link everything together and use certified services to build end-to-end certified processes.

16

ArchitecturalArchitectural challengeschallenges

● WITHIN ASSERT4SOA• Extend current SOA infrastructure with security certificates

• Provide a mechanism for runtime certificate matching that evaluates if the assurance level provided by a service’s certificate is compatible with clients’ preferences

● OTHER SHARABLE IDEAS• Use certificate matching to enforce customized assurance

policies, e.g. supporting different isolation and protection mechanisms for processess.

• Use certificate matching to select accountability and recovery mechanisms at run-time


17

OutlookOutlook


18

CertifiedCertified security from SOA to security from SOA to CloudCloud

● Distinction between SOAs and SaaS on clouds increasingly blurred

● One of the core patterns for SaaS over SOA is "Service Virtualization”, used by organizations to expose virtual services in front of their infrastructure. • These virtual services can take the form of lightweight REST APIs

or heavyweight SOAP Web Services. Hybrids are also possible, e.g. exposing a REST service in front of a SOAP service, and convert REST to SOAP dynamically.


19

CertifiedCertified security from SOA to security from SOA to CloudCloud

● How does it work? Use on-the-fly WSDL redirection (as of WSDL 2.0, applies to REST API as well as SOAP).• WSDL includes the address of the service provider host. When

the Gateway exposes a virtual service, it must replace this address with the address of the Gateway.

• FQDN endpoints will still work..• But wxactly who are we talking to?

● A potential security nightmare (see later), but also a new research area: Service virtualization security


20

Hard Hard nutnut to crack: Crossto crack: Cross--layeringlayering

● Service-level security mechanisms are assumed to be independent from channel and protocol level provisions

● BUT: virtualization will introduce a degree of cross-layering• E.g.: WSDL addresses using SSL makes SSL certificates

dependent on hostname changes.

● Typical cross-layered solution: use a SSL Server Name Identifier (SNI) that will dynamically use the appropriate SSL certificate (and private key) for the endpoint.• Introduces potential security concerns in the service endpoint –

to-certificate matching. • No service-level certificate will deal with this


Technology

Assert4soa 2nd cluster meeting