Security QoS Modeling (SQML) for Enterprise DRE Systems (eDRE)

1. Security QoS Modeling (SQML) for Enterprise DRE Systems (eDRE) By Akshay V. Dabholkar <aky@dre.vanderbilt.edu> Adviser Dr. Aniruddha Gokhale <a.gokhale@vanderbilt.edu> CS 388: Model Integrated Computing

2. Motivation Security is one of the key QoS Aspects in addition to Real-Time, & Fault Tolerance in making Enterprise DRE (eDRE) systems Trustworthy Apply the MDE approach to security to be able to express security policy annotations at a higher level and evaluate conflicting requirements at modeling time Goal is to add model-driven security enhancements to component middleware like CCM (CORBA Component Model) CS 388: Model Integrated Computing

3. Security • Definition of security “Safety“ or “freedom from worry“ • Types of protection: • Authorization • Access control and data protection (untrusted environment) • Accountability • Audit (weaker) and non-repudiation (stronger) • Availability • Service continuity and disaster recovery • Assurance • System safety and operational correctness CS 388: Model Integrated Computing

4. Multiple Security Concerns • Role-Based Access Control (RBAC): for managing user identity and roles for authorization • Evidence Generation: Component code running in the CCM container can be restricted to only use well-defined interfaces, which allows security to be effectively enforced on the code enabling safe deployment of large applications with varying degrees of security enforcements • Multi-level Security Policies: Enterprise, Machine, User & Application Domain policy types • System Partitioning: Based on domain security policies • Container Security: Infrastructure support in the CCM leveraging the CORBA security service and supported protocols for communication, authentication, encryption, integrity and interoperability CS 388: Model Integrated Computing

5. Client Application (Message Sender) Target Object ORB Security Enforcement Subsystem Execution Context Message Domain Credential Policy Decision Core Domain Policy Identity Privileges CORBA Security Model v1.8 • Security protection based upon policy • Policy may be domain specific • Policy enforced by ORB CCM Security adopts the EJB Security Specification • The ORB enforces • Access Control • Message Protection • Audit Policy • The ORB implements • PEP (Policy Evaluation Points) • PDP (Policy Decision Points), i.e., portable interceptors • The ORB Services implement • Policy Repository • Security Protocols (e.g., SSLIOP) • Authentication Methods • Cryptographic Algorithms CS 388: Model Integrated Computing

6. Credentials Credentials Target Client Current Current Policy Policy Obj-Reference ORB Security ORB Security Access Decision Access Decision Access control Access control Secure Invocation Secure Invocation Security Association Security Association ORB Core ORB Core Secure Inter-operability Secure Invocation Model CS 388: Model Integrated Computing

7. Modeling Approach Platform Independent Component Modeling Language (PICML) Captures CCM application lifecycle e.g., Assembly, Packaging, Deployment, etc. Component QoS Modeling Language (CQML) Enhances PICML Captures Component QoS requirements Leverage and enhance to capture security requirements for eDRE applications Solution: Security QoS Modeling Language (SQML) CS 388: Model Integrated Computing

8. User-Role-Rights Mapping (Effective Rights) • Responsibility of the System Administrator and defined in the application server deployment site through access control policies • The roles can be application specific or platform (CCM) specific • CCM Specific roles: Designer, Developer, Implementer, Assembler, Packager, Deployer, End-User • Application Specific roles: Administrator, User, Director, Programmer, Manager, etc. The Users & Groups are shown for completeness. User/Group →Role mappings are defined in the application access policies CS 388: Model Integrated Computing

9. Operation/Interface Classification Modeling (Required Rights) • Responsibility of the Component Developer • Operations/Interfaces are classified according to the standard CORBA family rights [corba:gsum] • Well-defined Component Interfaces • Allows for coarse-grained control over operation access • Used underneath in the container to determine access decisions to the operations • Granted Rights vs. Required Rights Rights assignment on a two-way method CS 388: Model Integrated Computing

10. Effective Vs. Required Rights • Granted by Policy • Per domain • Specified by developers • Per-type! • System-wide! • Group operations by “sensitivity“ • get(g), set(s), use(u), manage(m) • Rights Combinators: any, all Different effective set of rights based on role CS 388: Model Integrated Computing

11. The CORBA Component Model CCM QoS Levels A CCM Assembly Configure Security QoS Properties Address three CCM QoS levels – ports, components and assemblies SQML provides fine-grained as well as coarse-grained access control and security guarantees CS 388: Model Integrated Computing

12. Access Control Granularity • Fine-grained: • Interface Operation • Assembly Property • Component Attribute • Coarse-grained: • Interface • Set of Operations • Class of Operations (based on Required Rights - corba:gsum) • Inter-Component Execution Flow (Path in an Assembly) CS 388: Model Integrated Computing

13. Policy Definition Rules Two-Level evaluation: Operation name & Required Rights Two-Level Evaluation: Operation name & Required Rights Two-Level Evaluation: Operation name & Required Rights Critical path in the system (part of a functionality/workflow) Allow/Deny access to all operations with same rights Component Attributes have implicit get/set rights CS 388: Model Integrated Computing

14. Model Interpreter • Inject security related assertions and constraints to the CCM component deployment and configuration plan and generate security policies and permissions • Generate User → Role → Granted-Rights mappings defined by the system administrator for deployment in Security Assertion Markup Language (SAML) • Generate Operation → Required-Rights mapping for an interface that are determined by the component designer • Generate Policy definition files in eXtended Access Control Markup Language (XACML) • Based on the mappings and policy rules, generate method permissions defined on operations of the interface definition for the User roles that have rights to invoke a method • Generate additional metadata to configure the CCM container for applying the defined Security policies and enforcing them on the object interactions CS 388: Model Integrated Computing

15. Future Work • Define efficient rule and policy validation and rule combining algorithms. • Extend the critical path functionality to provide Business Process & Workflow security • Provide middleware infrastructure support for security in the CCM container through container portable interceptors, leveraging the facilities of the CORBA security service implementation available with TAO • Implement Policy Evaluation Point (PEP), Policy Decision Point (PDP), Policy Repository in CIAO • Enable D & C tools like DAnCE to integrate security QoS properties with application deployment and configure the CCM middleware to enforce them • This project will be extended in future R&D activities at ISIS to support Security QoS that is independent of the underlying middleware technology • Weaving of Concerns: Investigate the ramifications of having FT, RT and Security working in tandem CS 388: Model Integrated Computing

16. Enabling Trustworthy Systems with the DDS Quality of Service Modeling Language Joe Hoffert, Aniruddha Gokhale, Doug Schmidt {joseph.w.hoffert,a.gokhale,d.schmidt}@vanderbilt.edu

17. Outline • Trustworthy Systems via Model Driven Engineering (MDE) • Use Case: Data Distribution Service (DDS) • DDS QoS Modeling Language (DQML) • DQML Metamodel Overview • DQML Application: DDS Benchmark Environment (DBE) • DBE Interpreter • DQML Demonstration • Future Work

18. Trustworthy Systems (1/2) TRUST Goals for Enterprise Publish/Subscribe DRE Systems • Security Technology • Software Security • Software design • specification languages, methods, and tools supporting security by design • Static code verification via: • security-friendly APIs • disciplined styles of programming • automated tools for lightweight static checking • Trusted Platforms • Understanding composition • Evaluating security and vulnerability • Examining minimal configurations (hardware & software) that provide trusted platforms • Systems Science • Model-Based Integration of Secure Systems • model-based design • Quality of Service (QoS)-enabled component middleware

19. Trustworthy Systems (2/2) Facilitation of TRUST Goals via Model Driven Engineering (MDE) • Manage inherent complexity • Scope models to area/level of concern • Compose larger scope using modeling artifacts (e.g., application infrastructure/framework, higher level tools) • Understand composition via separation of concerns • Simplify vulnerability, provability analysis • Reduce accidental complexity • Increase confidence, reuse via MDE tools • Close security loopholes via misused tools, software, and configurations

20. Non-Trustworthy Systems • Coupling of business logic, infrastructure, QoS configuration (i.e., all crafted in handwritten code) • Intermixing of concerns/areas of focus • Lack of composition understanding • “Provability” via testing • Potential loopholes in untested code paths • Unintended functionality (i.e., design != implementation) Vulnerability, Lack of Confidence/Provability

21. Application Application read write write Logical Data Store Application write write Application read read Application Use Case: The OMG Data Distribution Service (DDS) • Provides flexibility, power and modular structure by decoupling: • Location – anonymous pub/sub • Redundancy – any number of readers & writers • Time – asynchronous, time-independent data distribution • Platform – same as CORBA middleware • Architecturally Broken into: • Data Centric Publish/Subscribe (DCPS) • Lower layer APIs to exchange topic data based on QoS policies • Data Local Reconstruction Layer (DLRL) • Upper layer APIs that make topic data appear local

22. QoS Policies Supported by DDS • DCPS entities (e.g., topics, data readers/writers) configurable via QoS policies • QoS tailored to data distribution in tactical information systems • Request/offered compatibility checked by DDS at Runtime • Consistency checked by DDS at Runtime • DEADLINE • Establishes contract regarding rate at which periodic data is refreshed • LATENCY_BUDGET • Establishes guidelines for acceptable end-to-end delays • TIME_BASED_FILTER • Mediates exchanges between slow consumers & fast producers • RESOURCE_LIMITS • Controls resources utilized by service • RELIABILITY (BEST_EFFORT, RELIABLE) • Enables use of real-time transports for data • HISTORY (KEEP_LAST, KEEP_ALL) • Controls which (of multiple) data values are delivered • DURABILITY (VOLATILE, TRANSIENT, PERSISTENT) • Determines if data outlives time when they are written • … and 15 more … • Implications for Trustworthiness

23. DataWriter DataReader Durability- Volatile Durability- Transient Deadline- 20ms Deadline- 10ms Timebased- 15ms Topic DataWriter Liveliness- Manual By Topic Liveliness- Automatic Reliability- Best Effort Reliability- Reliable DDS QoS Policies • Interactions of QoS Policies have implications for: • Consistency/Validity • e.g., Deadline period < TimeBasedFilter minimum separation (for a DataReader) • Compatibility/Connectivity • e.g., best-effort communication offered (by DataWriter), reliable communication requested (by DataReader) Will Data Flow? Or Will QoS Settings Need Updating? DataReader Will Settings Be Consistent? Or Will QoS Settings Need Updating?

24. DDS Trustworthiness Needs (1/2) • Compatibility and Consistency of QoS Settings • Data needs to flow as intended • Close software loopholes that might be maliciously exploited • Fixing at run-time untenable • Updating QoS settings on the fly • Introduces inherent complexity • Unacceptable for certain systems (e.g., RT, mission critical, provable properties) • Fixing at code time untenable • Implies long turn-around times • Code, compile, run, check status, iterate • Introduces accidental complexity • DDS QoS Modeling Language (DQML) models QoS configurations and allows checking at design/modeling time • Supports quick and easy fixes by “sharing” QoS policies • Supports correct-by-construction configurations

25. QoS Settings DDS Trustworthiness Needs (2/2) • QoS configurations generated automatically • Eliminate accidental complexities • Close configuration loopholes for malicious exploitation • Decouple configurations from application logic • Refinement of configuration separate from refinement of code • DQML generates QoS settings files for DDS Applications • Creates consistent configurations • Promotes separation of concerns • Configuration changes unentangled with business logic changes • Increases confidence

26. QoS Configuration DDS Application Development • Business/application logic mixed with QoS configuration code • Accidental complexity • Obfuscation of configuration concerns QoS configuration & publisher creation DataWriter QoS configuration & datawriter creation • DQML decouples QoS configuration from business logic • Facilitates configuration analysis • Reduces accidental complexity Business logic = Higher confidence DDS application

27. DQML Design Decisions • No Abortive Errors • User can ignore constraint errors • Useful for developing pieces of a distributed application • Initially focused on flexibility • QoS Associations vs. Containment • Entities and QoS Policies associated via connections rather than containment • Provides flexibility, reusability • Eases resolution of constraint violations

28. DataWriter DataWriter DataWriter DataWriter DataReader DataReader DataReader DataReader QoS QoS QoS QoS QoS QoS QoS QoS DQML Application: DDS Benchmark Environment (DBE) • Part of Real-Time DDS Examination & Evaluation Project (RT-DEEP) • http://www.dre.vanderbilt.edu/DDS • Developed by DRE Group at ISIS • DBE runs Perl scripts to deploy DataReaders and DataWriters onto nodes • Passes QoS settings files (generated by hand) • Requirement for testing and evaluating non-trivial QoS configurations

29. QoS Settings QoS Settings Invoke the DBE Interpreter Model the Desired QoS Policies via DQML DataReader DataWriter DBE Interpreter Generates One QoS Settings File for Each DBE DataReader and DataWriter to Use No Manual Intervention DBE Have DBE Launch DataReaders and DataWriters with Generated QoS Settings Files

30. DQML Demonstration • Create DDS entities, QoS policies, and connections • Run constraint checking • consistency check • compatibility check • fix at design time • Invoke DBE Interpreter • automatically generate QoS settings files

31. Future Work • Incorporate with TRUST Trustworthy Systems • Combine QoS polices and patterns to provide higher level services • Build on DDS patterns1 • Continuous data, state data, alarm/event data, hot-swap and failover, controlled data access, filtered by data content • Fault-tolerance service (e.g., using ownership/ownership strength, durability policies, multiple readers and writers, hot-swap and failover pattern) • Security service (e.g., using time based filter, liveliness policies, controlled data access pattern) • Real-time data service (e.g., using deadline, transport priority, latency budget policies, continuous data pattern) • Incorporate into Larger Scale Tool Chains • e.g., Deployment and Configuration Engine (DAnCE) in CoSMIC Tool Chain • Develop mapping between SQML security model and DDS security service (as input for security PIM) DQML DAnCE 1 Gordon Hunt, OMG Workshop Presentation, 10-13 July, 2006