Secure Systems Research Group - FAU A Pattern-Driven Process for Secure Service-Oriented Applications Ph.D Dissertation Defense Candidate: N. A. Delessy, Advisor: Dr E.B. Fernandez March 2008

Secure Systems Research Group - FAU Agenda Introduction –Problem Statement –Methodology and Overview of the Solution –Summary of Contributions Related Work

Secure Systems Research Group - FAU Agenda Contributions –The Pattern-Driven Process –Security-Enabled Metamodels for Service- Oriented and Web Services-Based Applications –The Decision-Guiding Map of Security Patterns and its Corresponding Catalog –The Chain of Model Transformation Definitions Conclusions and Future Work

Secure Systems Research Group - FAU Introduction Problem Statement –Service-Oriented Architecture (SOA) considered to be the new phase in the evolution of distributed enterprise applications –SOA could enable the design and realization of flexible applications across multiple organizations –Security issues associated with SOA: trust establishment among actors in an inter- organizational context –no central authority –users may not be known in advance channels of communication more vulnerable

Secure Systems Research Group - FAU Introduction Problem Statement –Actual solutions: Production of numerous, often overlapping security standards by the industry –  But there is no clear view of how to use them Security mechanisms and schemes proposed for SOA and web services –  They are not new, they are used in current distributed systems –A real problem hinders the widespread use of SOA: A methodology to design and build secure service- oriented applications is needed

Secure Systems Research Group - FAU Introduction Methodology and Overview of the Solution –We adapt the methodology in [Fer06b],[Fer06c] –Our process builds upon two different approaches to secure service-oriented applications: model-driven engineering the use of security patterns.

Secure Systems Research Group - FAU Introduction Methodology and Overview of the Solution –Security patterns are selected and applied at each step of the development process. We propose the use of a structured map –  Their selection is rendered easier Their application are automated since our patterns are described using UML models –In order to validate our process, we apply it to a real world example: a travel agency system

Secure Systems Research Group - FAU Introduction Summary of Contributions –The Pattern-Driven Process: describes in detail the different activities and artifacts produced at each step of the development –Security-Enabled Metamodels for Service-Oriented and Web Services-Based Applications: Allow the description of service-oriented and web services-based applications, with an emphasis on security, and in a flexible way, thanks to their security interfaces

Secure Systems Research Group - FAU Introduction Summary of Contributions –The Decision-Guiding Map of Security Patterns and its Corresponding Catalog Identified patterns that covered all layers and policy types Wrote and publish some of them –The Chain of Model Transformation Definitions Described using the OMG standard QVT

Secure Systems Research Group - FAU Related Work Several approaches have been presented to secure service oriented applications –Many use a formal approach, but they are applicable in very specific cases e.g. [Yua04] addresses low-level aspects of security at the discovery phase of web services –[Ala04] proposes a model-driven approach that extends OCL to define access control policies –[Nak05] uses a MDA approach, but a low-level only

Secure Systems Research Group - FAU Related Work Several approaches have been presented to secure service oriented applications –[Char05], [Ray04] are Aspect-Oriented approaches to secure web services compositions, by resp. extending BPEL to insert pointcuts and defining model weaving operations the security expert would need to know resp. BPEL language or the unsecure application model –[Gut06] presents a whole process to secure web services-based systems Not detailed, no mention of automatic transformations

Secure Systems Research Group - FAU The Pattern-Driven Process Software Lifecycle Stage ActorsMDA viewpointArtifactDescription of the artifact AnalysisBusiness analysts Computational independentCIMDescribes the problem space (customer needs, a.k.a. requirements) DesignArchitectsPlatform independentPIMDescribes how the chosen architectural style resolves the problem (i.e. in terms or components and connectors) Refined Design Architects Developers Platform specificPSMDescribes how the problem is resolved using the chosen platform CodingDevelopersRuntime executionCode/ Configuration files How the specific language and (virtual) machine resolves the problem

Secure Systems Research Group - FAU The Pattern-Driven Process Software Lifecycle Stage Artifact Artifact for Service-oriented applications as a composition of services Transformations AnalysisCIMUML conceptual class diagram, activity diagram derived from Use cases CIM to PIM (1) is manual CIM2secCIM is a simple automated operation DesignPIMClass diagram in terms of services, activity diagram describing the service compositions PIM2secPIM, and PIM to PSM (PIM2PSM) are automated Refined Design PSMClass diagram describing web services and activity diagram describing the web services interactions PSM2secPSM is automated, PSM to code is semi- automated CodingCode/ Configuration files WSDL files, BPEL files, XACML rules

Secure Systems Research Group - FAU The Pattern- Driven Process

Secure Systems Research Group - FAU Example: Travel Agency

Secure Systems Research Group - FAU Example: Travel Agency

Secure Systems Research Group - FAU The Security-Enabled Metamodel for Service-Oriented Applications Survey of existing SOA metamodels A security-enabled metamodel, not a secure metamodel –For enhanced flexibility: security patterns can be added dynamically Includes a simple security interface –Designed from the security requirements for service oriented applications

Secure Systems Research Group - FAU The Security-Enabled Metamodel for Service-Oriented Applications Security goals/TrustSecurity RequirementsPolicy type Confidentiality of stored information SR1. Access to services and their operations must be controlledAccess Control policies SR2. Service requesters must be authenticatedAuthentication policies Confidentiality of information in transmission SR3. The contents of exchanged messages must be kept confidential Message-level confidentiality policies Integrity of stored information SR1. Access to services and their operations must be controlledAccess Control policies SR2. Service requesters must be authenticatedAuthentication policies Integrity of information in transmission SR5. A service must verify that the contents of received messages have not been modified during their transit. Message-level integrity policies SR6. The contents of the received message must be authenticated Message-level authenticity policies SR7. A service must verify that the received messages have not been replayed.Message freshness policies Trusted participants SR8. Services and principals must be trusted only in a determined way Trust establishment and trust propagation policies SR9. Identity management and identity propagation must be clearly definedIdentification policies Non repudiation SR10. Service requester cannot deny having sent a message Message-level non-repudiation policies SR11. Accesses to a service must be logged Logging policies Audit policies Non repudiation policies

Secure Systems Research Group - FAU The Security- Enabled Metamodel for Service- Oriented Applications

Secure Systems Research Group - FAU The Security-Enabled Metamodel for Service-Oriented Applications Using the metamodel

Secure Systems Research Group - FAU The Security-Enabled Metamodel for Service-Oriented Applications Using the metamodel

Secure Systems Research Group - FAU The Security- Enabled Metamodel for Web Services- Based Applications

Secure Systems Research Group - FAU The Decision-Guiding Map of Security Patterns

Secure Systems Research Group - FAU The Corresponding Catalog of Security Patterns Examples –The Identity Provider Pattern allows the formation of a dynamically created identity within an identity federation consisting of several service providers. Therefore, identity and security information about a subject can be transmitted in a transparent way for the user among service providers from different security domains. –The Policy-Based Access Control Pattern decides if a subject is authorized to access an object according to policies defined in a central policy repository.

Secure Systems Research Group - FAU The Identity Provider Pattern context FederatedIdentity inv: forall(p | self.federatedAttributes->includes(p) implies self.subject.localIdentity.localAttributes->includes(p)) inv: self.federatedAttributes->excludes( self.subject.localIdentity.localAttributes.oclAsType( PrivateAttribute))

Secure Systems Research Group - FAU Policy-Based Access Control Pattern

Secure Systems Research Group - FAU The Chain of Transformation Definitions PIM2PSM –Simple QVT Relations CIM2secCIM, PIM2secPIM and PSM2secPSM –Relations between models are not static –  Model weaving operation

Secure Systems Research Group - FAU PIM2PSM Transformation Definition Example: Relation InvRec2All

Secure Systems Research Group - FAU PIM2PSM Travel Agency Example: Generated PSM

Secure Systems Research Group - FAU PIM2secPIM Transformation Definition Travel Agency example: Produced relation

Secure Systems Research Group - FAU PIM2secPIM Transformation Definition Travel Agency example: Produced PIM

Secure Systems Research Group - FAU Conclusions Benefits: –The process decouples the application domain expertise from the security expertise that are both needed to build a secure application.  The inclusion of security during the software development process becomes more convenient for the architects/designers.  Understanding security patterns from their human- readable description and knowing how to use the security-enabled metamodels are sufficient skills to use our process..

Secure Systems Research Group - FAU Conclusions Benefits: –The insertion of security is semi-automated and traceable.  The process is flexible and can easily adapt to changing requirements. –Given that SOA was developed in order to provide enterprises with modular, reusable and adaptable architectures, but that security was the principal factor that hindered its use, we believe that our process can act as an enabler for service-oriented applications.

Secure Systems Research Group - FAU Future Work Identification and writing of more security patterns at all levels, in order to ‘cover’ all security policies. Implementation into a tool. It should be able to make accurate suggestions of security patterns during the development of an application using all relationship types. Additionally, many MDA frameworks exist. The model transformation specifications should be implementable easily using one of those.

Secure Systems Research Group - FAU Future Work Our results consist in the design of a software development process for secure service- oriented applications. However, it would be valuable to abstract this process so that it could be architectural-style-independent, not only applicable to service-oriented applications. Finally, we need to investigate ways to validate our process. In particular, this leads to the problem of security patterns validation, which is resolved using methods in [Jur02]. But how can we verify that their application produces a secure design?

Secure Systems Research Group - FAU Thank You!