Top Banner
Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group
23
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

Secure Middleware (?)

Patrick Morrison

3/1/2006

Secure Systems Group

Page 2: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

Agenda

• Why middleware?

• What is middleware?

• How do you secure middleware?

• Next Steps

Page 3: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

Why do a Presentation on Middleware?

• Follow-up on last year’s report– Tasks to be completed

– Areas to be explored

• Look for middleware’s place in a comprehensive methodology

• Suggest some ideas for dealing with COTS/externally-developed/NIH products

• Ask questions for which I don’t have answers

Page 4: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

Why? Follow-up

• Tasks from “A methodology for secure software design of complex applications” (Report 4)

– T1 - Complete and refine our methodology to develop secure software. Define security requirements and their mapping to software aspects such as distribution and components. For this purpose we need to analyze possible threats and relate them to use cases and architectural levels.

– T2 - Define an access control model able to express a variety of security policies.

– T3 - Design an abstract multi-layer enforcement architecture for the model of T2. High-level constraints are mapped to implementations, including middleware, web services, database management systems (DBMSs), and operating systems. (Use MDA CIM and PIM)

– T4 - Develop patterns that correspond to sets of policies and build a catalog of conceptual security patterns for complex applications.

– T5 - Apply this methodology to the teaching of security.

– T6 - Validate the methodology and model by testing them in real environments.

– Develop a Common Criteria Protection Profile for secure medical/financial data access systems

– Develop matrix (concern by lifecycle phase) to show methodology’s coverage

Page 5: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

Why Middleware: Follow-up

• Task 1 …Define security requirements and their mapping to software aspects such as distribution and components. …

• Task 3 … High-level constraints are mapped to implementations, including middleware …

Page 6: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

What Is Middleware?

• Definitions

• Attributes

• Examples

• Security Goals

Page 7: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

What is Middleware: Definitions

• “Typically, as indicated earlier, these rules are kept in a centralized middleware (a Web Application server) that connects all databases. The WAS keeps a model of the institution information. This model is

used as a reference to define security constraints.” [1]

• “The applications in these systems are usually integrated using a Web Application Server (WAS), a type of middleware that has a global enterprise model, typically implemented using object-oriented components such as J2EE or .NET.” [2]

• “This will be a multi-layer architecture where the high-level constraints are mapped to implementation-oriented mechanisms such as middleware, web services, database management systems (DBMSs), and operating systems.”[3]

Page 8: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

What is Middleware: Definitions (2)

• Wikipedia: “In computing, middleware consists of software agents acting as an intermediary between different application components. It is used most often to support complex, distributed applications. The software agents involved may be one or many.”

• Pat: “If it’s not your application and it’s not the OS, it’s middleware*.” (* - unless your application is the middleware)

• For the methodology, our definition is ____________________________________

Page 9: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

What is Middleware: Attributes

• Provides services to applications

• Requires system resources, dependencies

• Has vulnerabilities and constraints

• May or may not implement its own access control model

• Developer may not have control over its design

Page 10: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

What is Middleware: Examples

• Web Application Servers

• Web Servers

• DBMS’s

• Web Services

• …

Page 11: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

What is Middleware: Security Goals

• Engineer application to depend on middleware only as much as necessary, in view of middleware’s capabilities, liabilities and constraints

• Engineer system to account for middleware’s capabilities, liabilities and constraints.

• So, how do you find middleware’s capabilities, liabilities and constraints?

Page 12: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

How do you secure middleware?

• DIY – Do It Yourself

• CC – Common Criteria

• MDA – Model-Driven Architecture

• Suggestions: _______________

Page 13: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

Securing Middleware: DIY

• Consider security principles

• Research thoroughly

• Choose wisely

• Configure carefully

• Document everything

• Hope for the best

Page 14: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

Securing Middleware: Common Criteria

• Common Criteria collects substantial security knowledge in a structured English framework [4]

• Define your security requirements - ST• Find a Protection Profile that meets your ST• Choose TOE’s that have been validated against

the PP/ST you’ve selected• Follow advice of TOE/ST/PP on configuration

and use of selected product(s)• If you know CC, you know this is oversimplified

Page 15: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

CC compared to DIY

• Consider security principles – shared effort

• Research thoroughly – shared effort

• Choose wisely – (probably) limited to existing CC profiles – shorter list

• Configure carefully – shared effort

• Document everything – shared effort

• Hope for the best – risk somewhat mitigated

Page 16: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

Securing Middleware: MDA

• MDA – Model-driven architecture, a platform for abstracting system details in a machine-readable format [5]

• Models and Meta-models – CIM – Computation Independent Model

• “Domain Model” – business-level view

– PIM – Platform Independent Model

– PSM – Platform Specific Model

• UML-based

• machine-readable

• Documented standards

Page 17: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

Securing Middleware: MDA

Figure from MDA Guide Version 1.0.1 [5]

Page 18: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

Securing Middleware: MDA

• [e.g.] UML Profile for enterprise distributed Object Computing (EDOC) (CIM)– Enterprise Collaboration Architecture (ECA)– Metamodel and UML Profile for Java and EJB (PIM-

>PSA)– Flow Composition Model (FCM)– UML Profile for Patterns– UML Profile for ECA– UML Profile for Meta Object Facility

– UML Profile for Relationships

Page 19: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

Securing Middleware: MDA

• Obtain or develop CIM – embodies requirements• Obtain or develop PIM – embodies analysis,

design• Obtain or develop PSM for system’s middleware –

embodies implementation• *Obtain tool support for automated translation*• Hope for the best!

Page 20: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

Method Comparisons

• DIY can be risky… but it’s easy to get started

• CC is more rigorous than DIY, but there are fewer options. Covers requirements and analysis phases.

• MDA can be as rigorous as CC, and is amenable to machine transforms… but few tools, data-points exist. Spans the lifecycle.

Page 21: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

Methodology and the MDA

Desirable methodology attributes MDA Cover Requirements, Analysis, Design, Implementation phases

MDA addresses requirements-level (CIM), analysis and design level (PIM), and implementation level (PSA) concerns.

Use UML to present requirements (Use Cases), analysis and design models

MDA represents its artifacts as machine-readable UML, through the MOF, to allow for transition between development phases.

Allow use of any common access control model (e.g. Multi-level, RBAC, etc)

MDA is access-control agnostic; it only determines a means for representing models, it does not dictate the content of those models.

Specific enough to be usable, generic enough to be manageable

MDA artifacts are intended to migrate from the generic to the specific, as projects move forward.

Page 22: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

Next Steps

• Decide whether to commit to MDA, building CIM’s, PIM’s

• Explore other options – suggestions?

Page 23: Secure Middleware (?) Patrick Morrison 3/1/2006 Secure Systems Group.

References

• [1] “Aspect-Oriented versus architecture-oriented security”, Eduardo B.Fernandez, Carlos Oviedo, and Alex J. Kotlarchyk

• [2] "Towards Secure Architectures for Middleware Systems", Eduardo B. Fernandez, Shihong Huang, Maria M. Larrondo-Petrie

• [3] “A methodology for secure software design of complex applications”, E.B. Fernandez, T. Sorgente, M. VanHilst, and M.M. Larrondo-Petrie

• [4] http://www.commoncriteriaportal.org/

• [5] www.omg.org/mda