1. You live in a certified house,
you drive a certified car,
why would you use an uncertified service?
• SAP
• Università degli Studi di Milano Ernesto Damiani
• Engineering Ingegneria Informatica ernesto.damiani@unimi.it
• SIT - Fraunhofer Institute
• City University of London Università degli Studi di Milano
• University of Malaga
• Fondazione Ugo Bordoni
1

2. Talk outline
●ASSERT4SOA in a nutshell
●Ongoing work, open problems,
and (hopefully) some sharable
ideas
●Next Exit: The Future
Doctoral School – Security Patterns for ITC Infrastructures, 2
March-April 2011

3. Motivation (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
3 BS
ME
20

4. Modified Trust
● Modified trust model of software assurance
documentation with certification
4 BS
ME
20

5. Motivation (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
5 BS
ME
20

6. ASSERT4SOA 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
6

7. ASSERT4SOA Vision
Service
Requested Service Consumer
Assurance Consumer
Properties Requested
Assurance
Certificate
Certificate Properties
2. Lookup Requested Administration Point
Administration Point 3. Evaluate properties
Assurance
Properties ASSERT Certificate Decision
Certificate Decision
2. Lookup Point
Point
Service
Discovery
3. Interact
Service Discovery
ASSERT Aware 4. Interact
1. Register
1. Register
ASSERT Certification Schemes
Service Certifiers
Certificate
Certificate (CC, SAS70,
Certification SOA Specific..)
Administration Point
Administration Point
Certification Schemes ASSERT
Certifiers ASSERT
ASSERT
Service
(CC, SAS70, Accredited
Accredited
SOA Specific..) Authority
Authority
0. Deliver ASSERT
Existing Component Digital World
Current Situation ASSERT4SOA vision 7
ASSERT Component
ASSERT Component Physical World

8. ASSERT4SOA 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)
8

9. ASSERT4SOA Certification
Models
ASSERT Accredited
ASSERT Accredited
Authority
Authority
Service
Consumer
Requested
Certificate
Certificate Assurance
Administration Point
Administration Point Properties
Requested
ASSERT
Assurance
Properties Certificate Decision
Certificate Decision
Point
Point Evidence
Service Discovery Reasoner Ontology
ASSERT Aware Ontology
ASSERT
Reasoner
Certificate Evaluation Point
Certificate Evaluation Point
9

10. Ongoing work, open problems
and (hopefully) sharable ideas
10

11. What shall we certify?
● 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
Doctoral School – Security Patterns for ITC Infrastructures, 11
March-April 2011

12. Linking 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
Doctoral School – Security Patterns for ITC Infrastructures, 12
March-April 2011

13. Linking 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 the
service or container level.
Doctoral School – Security Patterns for ITC Infrastructures, 13
March-April 2011

14. Mapping property certificates to services
● 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)
Doctoral School – Security Patterns for ITC Infrastructures, 14
March-April 2011

15. SOME 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
15
processes.

16. Architectural challenges
● 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
Doctoral School – Security Patterns for ITC Infrastructures, 16
March-April 2011

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

18. Certified security from SOA to Cloud
● 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.
Doctoral School – Security Patterns for ITC Infrastructures, 18
March-April 2011

19. Certified security from SOA to Cloud
● 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
Doctoral School – Security Patterns for ITC Infrastructures, 19
March-April 2011

20. Hard nut to crack: Cross-layering
● 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
Doctoral School – Security Patterns for ITC Infrastructures, 20
March-April 2011