This document discusses information assurance (IA) in the context of model driven architecture (MDA) and service oriented architecture (SOA). It notes that MDA and SOA can help address IA needs by enabling loose coupling, interoperability, and other benefits, but capturing and validating non-functional IA requirements like security policies is challenging. The document proposes strategies for discovering, modeling, and validating such requirements across multiple models. Potential research problems are identified around maintaining alignment between models, addressing issues in large distributed systems, and managing policies.

1. Information Assurance
in a World of
Model Driven Architecture and
Service Oriented Architecture
UC San Diego
CSE 294
May 30, 2008
Barry Demchak

2. Motivation
 Large scale applications have many
stakeholders with diverse needs
MDA SOA
Application
enables
models organizes
 Loose Coupling
 Late Binding
 Scalability
 Composition
 Interoperability
 Testability
 Malleability
 Manageability
 Dependability
 Incremental
development
 Multilevel modeling
(…UML)
 Alignment fidelity
 NO GAPS

3. Motivation
 Common concern is Information Assurance
 Reliable information delivery to intended parties under
appropriate circumstances
MDA SOA
Application
enables
models organizes
IA
needs
models organizes

4. Outline
 Motivation
 Background
 Problem and Strategy
 Related Techniques and Analysis
 Potential Research Problems
 Conclusion

5. Information Assurance
 Availability and integrity
 Confidentiality and non-repudiation
 Use by proper parties under proper
circumstances
 Consequence
 A large scale system with many stakeholders
may become impaired or dangerous if IA is
impaired or missing

6. Information Assurance (cont’d)
 Subproblems
 Security
 Policy
 Governance
 Data Quality
 Digital Rights Management …
 Parties
 User agents
 Data sources
 Data intermediaries
 Applications
 e-Commerce
 All commerce
 HIPAA
 SOX
 DoD
Authentication and
Authorization
Infrastructure (AAI)

7. Authentication Authorization Infrastructure
 Allow access to a resource based on characteristics
of requestor and action requested
 Trust
 PDP/PEP
 RBAC & Administrative
Domains
 Policy
 Separation of Duties
 Separation of Concerns

8. Authentication Authorization Infrastructure
 Grid Systems – “the grid problem”
 Campus/Enterprise Systems
 Web Services – “the web problem”

9. Authentication Authorization Infrastructure
 Grid Systems – “the grid problem”
 Campus/Enterprise Systems
 Web Services – “the web problem”

10. Authentication Authorization Infrastructure
 Grid Systems – “the grid problem”
 Campus/Enterprise Systems
 Web Services – “the web problem”

11. Model of Hypothetical Unified AAI
 ID Providers
 Attribute Authorities
 Virtual Organizations
 Resources
 Policies

12. Model of AAI PEP

13. SOA Benefits for IA
 Crosscutting Concerns
 Interoperability and Reuse
 Understandability and Maintainability
 Configurability at lower risk
 Attack detection, secure logging, QOS,
performance monitoring, alert generation …
 Hierarchical testability and validation
 Leverage standards WS-*, DoD, IBM, HP, etc

14. Model Driven Architecture
 Approach that can produce SOAs
 Fidelity of alignment between
user requirements and application
 Multilevel modeling (…UML)
 Transformations between models
… bidirectional
 NO GAPS
 Complimentary to SOA
 Roles
 Interactions
 Separation of logical and
deployment models
 Supports hierarchical
development
Computation
Independent
Model
Platform
Independent
Model
Platform
Specific
Model

15. Rich Services CIM/PIM Process
 Agility
 Completeness
 Scalability
 End-to-End
 Alignment
 No Gaps

16. Outline
 Motivation
 Background
 Problem and Strategy
 Related Techniques and Analysis
 Potential Research Problems
 Conclusion

17. The Problem
 Using existing MDA approaches, it is hard to:
 Capture non-functional AAI requirements
 Model AAI in one or multiple models
 Validate AAI-provisioned models
 Understand effect on deployment models

18. Strategy
 Discover and model non-functional
requirements (NFRs)
 Trust relationships
 Attributes
 Security constraints
 Policies
 Credential Delegations
 Validate models
 Generate code and deliverables (when possible)
 Maintain end-to-end alignment with no gaps

19. Strategy
Discover NFRs Model NFRs
Validate Models Deployment

20. Outline
 Motivation
 Background
 Problem and Strategy
 Related Techniques and Analysis
 Potential Research Problems
 Conclusion

21. Analysis of Related Techniques
 Non-functional Requirements (NFRs)
 Trust Management
 Constraint Modeling
 Quality Assurance
 Policy Management

22. Non-functional Requirements
 Cysneiros
 Notional and behavioral statements for user-
determined symbols
 Generate dependency graphs used to discover
operational requirements
 Sindre
 Discovers unwanted behaviors (misuse cases)
 Identify triggers, assumptions, preconditions,
postconditions, threats, mitigations, and risks
 Alexander
 Augments UML use case diagrams with negative
actors and relationships (threatens, mitigates,
aggravates, conflicts with)

23. Non-functional Requirements
 Pros
 Discover trust, entitlement, VOs, decision
points, SoAs, security goals, threats
 Define requirements matching risks and costs
 Leads to prioritization of security goals
 Cons
 Don’t leverage collaboration techniques
 Highly manual
 Don’t leverage ontologies

24. Trust Management
 Giorgini
 Creates privilege and trust model using Secure Tropos
tool identifies:
 Actors and goals
 Service exchanges between actors
 Actors who trust other actors or own services
 Actors who delegate permission to others
 Validates model (completeness/consistency)
 Generates policies
 Pros
 High abstraction level
 Produces actionable policies
 Cons
 Not integrated with UML
 Isn’t aware of VOs

25. Constraint Modeling
 Alam
 SECTET enables annotation of UML models with
security predicates and identifies security principals
 Generates policy statements directly
 Satoh
 Like Alam, but models mechanisms and devices
 Juerjens
 Annotates like Alam, but generates SPIN/Promela
proofs directly
 Burt
 Identifies policy-governed relationships in UML models
… separating policy authorship from functional
modeling

26. Constraint Modeling
 Pros
 Modeling is performed at high level of
abstraction
 Covers high level and low level relationships
 Clear separation between modeling and
deployment
 Cons
 Limited delegation and separation of duty
support
 Unaware of administrative domains (VOs)
 Unaware of distributed systems and policy
distribution concerns

27. Quality Assurance
 Wang
 Leverages threat-oriented UML sequence diagrams
(SDs) to generate threat traces
 Searches execution traces for threats realized
 Krüger
 Leverages normal model Message Sequence Charts
(MSCs) to monitor runtime message sequences
 Pros
 UML models are leveraged directly for validation
 Wang explicitly models threat scenarios
 Cons
 SDs and MSCs likely to be incomplete
 Wang threat trace searching done offline
 Detect flow anomalies but not unauthorized access

28. Policy Management
 Dulay
 General purpose policy deployment and
execution model
 Agnostic to policy language or type
 Updates, enables, disables policies in
distributed environment
 Pros
 Operates in distributed environment
 Cons
 Disconnect between functional modeling (PIM)
and policy deployment

29. Outline
 Motivation
 Background
 Problem and Strategy
 Related Techniques and Analysis
 Potential Research Problems
 Conclusion

30. Potential Research Problems

31. Potential Research Problems
 Alignment
 Policy deployment based on models
 Automatic bidirectional model transitions (e.g.,
for use case modeling)
 Integrate independent systems (e.g., Secure
Tropos) with models

32. Potential Research Problems
 Large System Issues
 Introduce collaboration and information fusion
to requirements and logical modeling stages
 Introduce policy distribution into constraint
modeling
 Integrate VO repositories into modeling
 Model incomplete trust

33. Potential Research Problems
 Policy Issues
 Study relationship between policy authorship
and functional modeling
 Policy enables exogenous application
development
 Policy amounts to late-bound coding
 How to make system guarantees and
validations?
 What are limits of policy and when
should/shouldn’t they be used?
 How does author visualize effects of policy
execution and arrange consistent
deployment?

34. Conclusion
 We discussed
 AAI, MDA, and SOA and related them
 AAI vis-à-vis large organizations with multiple
domains in a hostile environment
 Modeling AAI concerns end-to-end
 Potential research issues: alignment, large
systems, and policy
 We believe improvements to MDA can
facilitate delivering AAI applications as SOAs,
and there are real benefits to doing so

35. References
 L. Cysneiros and J. Leite. Using UML to Reflect Non-Functional Requirements. In procedings of the
11th Annual IBM Centers for Advanced Studies Conference (CASCON), November 2001.
 G. Sindre and A. Opdahl. Eliciting Security Requirements with Misuse Cases. Requirements
Engineering 10(1):34-44, 2005.
 I. Alexander. Initial Industrial Experience of Misuse Cases in Trade-Off. In proceedings of the IEEE
Joint International Conference on Requirements Engineering, Essen, Germany, September 2002.
 N. Sukaviriya, V. Sinha, T. Ramachandra, and S. Mani. Model-Driven Approach for Managing Human
Interface Design Life Cycle. Model Driven Engineering Languages and Systems. Springer-Verlag Berlin
Heidelberg, 2007, pp 226-240.
 L. Wang, E. Wong, and D. Xu. A Threat Model Driven Approach for Security Testing. In procedings of
the Third International Workshop on Software Engineering for Secure Systems (SESS’07), Minneapolis,
MN, May 2007.
 I. H. Krüger, M. Meisinger, and M. Menarini. Runtime Verification of Interactions: From MSCs to
Aspects. in RV 2007, O. Sokolsky and S. Tasiran (Eds.), vol. LNCS, no. 4839, Vancouver, Canada.
Springer-Verlag Berlin Heidelberg, Mar. 2007, pp. 63-74.
 M. Alam, R. Breu, and M. Hafner. Model-Driven Security Engineering for Trust Management in
SECTET. Journal of Software, 2(1), 2007.
 F. Satoh, Y. Nakamura, and K. Ono. Adding Authentication to Model Driven Security. In proceedings of
the IEEE International Conference on Web Services, Salt Lake City, UT, July 2006.
 J. Juerjens. Secure Systems Development with UML. Springer-Verlag Berlin Heidelberg, 2003.
 C. Burt, B. Bryant, R. Raje, A. Olson, and M. Auguston. Model Driven Security: Unification of
Authorization Models for Fine-Grain Access Control. In proceedings of the 7th IEEE International
Enterprise Distributed Object Computing Conference, Brisbane, Australia, Sept. 2003.
 N. Dulay, E. Lupu, M. Sloman, and N. Damianou. A Policy Deployment Model for the Ponder Language.
In proceedings of the 7th IEEE/IFIP International Symposium on Integrated Network Management,
Seattle, WA, May 2001.

36. Backup Slides
 <go back>

38. Non-functional Requirements
 Cysneiros
 User-generated symbol (word) system
 Notional and behavioral statements for each symbol
 Generate dependency graphs
 Organize graphs NFR-centric to discover operational
requirements
 Pros
 Discover trust, entitlement, VOs, decision points,
SoAs
 Improve use cases and logical models
 Cons
 Highly manual, doesn’t leverage ontologies, doesn’t
scale to large collaborations

39. Non-functional Requirements
 Sindre
 Discovers unwanted behaviors (misuse cases)
 Identify triggers, assumptions, preconditions,
postconditions, threats, mitigations, and risks
 Pros
 Identifies critical assets, security goals, threats
 Stimulates analysis
 Define requirements matching risks and costs
 Leads to prioritization of security goals
 Cons
 Can be very recursive – analysis paralysis
 Doesn’t leverage elicitation or collaboration techniques

40. Non-functional Requirements
 Alexander
 Adds negative actors to UML use case
diagrams
 Adds relationships: threatens, mitigates,
aggravates, conflicts with
 Pros
 Compliments Sindre
 Enables less-technical contributors

41. Non-functional Requirements
(Alexander)

42. Rich Services Architectural PatternFrom tightly to l o o s e l y coupled systems
a hierarchically decomposed structure supporting
“horizontal” and “vertical” service integration

43. Rich Services – from UCSD

44. RESCUE Logical Architecture

45. Identity Federation
 Authenticated on one server ⇒ trusted on others
 Standards-based information exchange (SSL, HTTP, SAML, …)
 Result: portable identity

46. Security Attribute Markup Language
 XML framework for marshaling security and
identity information
 Wraps existing security technologies (e.g.,
XACML)
 Describes assertions about subjects
 Bindings for SOAP, HTTP redirect, HTTP
POST, HTTP artifact, URI
 Is not a crypto technology, assertion
maintenance protocol, data format, etc.

47. SAML Assertion
Example: Alice can read finance database

48. SAML Assertion (Query Response)
<SAMLQueryResponse>
<RequestID>urn:random:32q4schaw983y5982q35yh98q324==
<Assertion>
<AssertionID>http://www.bizexchange.test/assertion/AE0221
<Issuer>URN:dns-date:www.bizexchange.test:2001-01-03:19283
<ValidityInterval>
<NotBefore>
<NotOnOrAfter>
<Conditions>
<Audience>http://www.bizexchange.test/rule_book.html
<Claims>
<Subject>
<NameID>mailto:Alice@bizex.test
<Object>
<Authority>
<Permission>Read
<Resource>http://store.carol.test/finance
<Role>URN:dns-date:www.bizexchange.test:2001-01-04:right:finance

49. SAML Assertion (XACML embedded)
<TBS-POLICY-QueryResponse>
<RequestID>urn:random:zwos43i55098w4tawo3i5j09q==
<Assertion>
<AssertionID>http://policy.carol.test/assertion/
<Issuer>URN:dns-date:policy.carol.test:2001-03-03:1204
<ValidityInterval>
<NotBefore>
<NotOnOrAfter>
<Claim>
<Policy>
<Resources>
<string>http://store.carol.test/finance
<ACL>
<ACE>
<Subject>
<Role>URN:dns-date:www.bizexchange.test:2001-01-04:right:finance
<Permit>RWED
<ACE>
<Deny>ED
<Subject>
<Right>URN:dns-date:www.bizexchange.test:2001-01-04:right:ops
<Permit>R
<ACE>

50. Web Browser Password Access
nd Roles {
ncrypt {
}Establish Identity
Enforce Policy {

51. Shibboleth Application
Policy
Decision/
Enforcement
Point
Existing Kerberos,
AD, etc
Java on
Tomcat/Apache
C++ on Apache or IIS
HTTP headers

52. Patterns
Composite Pattern – Hierarchy (Vertical Integration)
Interceptor Pattern
Service 1
Service 1.2Service 1.1 Service 1.3
Service 1.3.1 Service 1.3.2
Service 2
Service 2.2Service 2.1
Interceptor Service
Message Pattern – Loose Coupling (Horizontal Integration)
⇒ Rich Services (UCSD)

53. Services and SOA
 Loose Coupling
 Late Binding
 Scalability
 Composition
 Interoperability
 Testability
Network
Implementation
Single Server,
Multiple
Processes
Single
Application,
Linked Modules
Logical Deployment
 Malleability
 Manageability
 Dependability
 Incremental
development