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 firstname.lastname@example.org• SIT - Fraunhofer Institute• City University of London Università degli Studi di Milano• University of Malaga• Fondazione Ugo Bordoni 1
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
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
Modified Trust● Modified trust model of software assurance documentation with certification 4 BS ME 20
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
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
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 PointCertification 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
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
ASSERT4SOA Certification Models ASSERT Accredited ASSERT Accredited Authority Authority Service Consumer Requested Certificate Certificate Assurance Administration Point Administration Point PropertiesRequested ASSERTAssuranceProperties Certificate Decision Certificate Decision Point Point Evidence Service Discovery Reasoner Ontology ASSERT Aware Ontology ASSERT Reasoner Certificate Evaluation Point Certificate Evaluation Point 9
Ongoing work, open problemsand (hopefully) sharable ideas 10
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
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
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
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
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.
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
OutlookDoctoral School – Security Patterns for ITC Infrastructures, 17March-April 2011
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
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
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
A particular slide catching your eye?
Clipping is a handy way to collect important slides you want to go back to later.