Technologies for Federation and Interoperation of Coalition Networks

1. Technologies for Federation and Interoperation of Coalition Networks Seraphin Calo, David Wood, Petros Zerfos, IBM T.J. Watson Research Center, NY, USA David Vyvyan, Patrick Dantressangle, Graham Bent IBM Emerging Technology Services, Hursley, UK

2. Coalition Operations US Site Coalition Camp Site Mobile Ad Hoc Network Sensor Assets Mobile Assets Command & Control UK Site

3. Controlled Information Sharing & Filtering • Key capability to enable for coalition operations: • deliver the right information, to the right coalition member, in conformance with the policies of all • Where to enforce policies and control the information flow: Network of Federated Gateways Centralized Data Repository Info. Filtering on every Node Centralized Distributed

4. Controlled Information Sharing in Coalition Operations Requirements Approaches for Information Filtering Policy-enabled Federated Gateway Data Filtering: Policy Management Library Information Federation: GaianDB Design & Implementation Performance Evaluation Results Conclusions Outline

5. Distributed, ad hoc policy deployment Define policies locally, enforce them globally Transparent deployment of information filters and control points No modifications required in the data sources Context-awareness for interoperation To describe conditions in the dynamic deployment environment Data-centric policies for information sharing: Act as an application-layer firewall Information interchange usually carried out through a (standard) application-level protocol: JDBC (SQL), SOAP (XML), Message Bus (Pub/Sub) System Requirements

6. Approaches for Filtering SQL Data Client Data source SQL Query ResultSet • “Forward” direction with query rewriting: re-write the SQL submitted by the client • Augment the query with filters in the WHERE clause (σ- operation in relational algebra) • Remove an entire column from the query from the FROM clause (π-operation in relational algebra) • “Reverse” direction by filtering the returned results (ResultSet): • Evaluate filtering of policies on a row-by-row basis • Remove complete rows from the returned results or conceal the values of certain columns

7. Data filtering & transformation through SPL Policies: Developed managed runtime for the relational model: rows, columns, tables, as well as “query context” Exposed JDBC semantics to SPL policies Information Federation through JDBC proxy: Intercepts transparently the SQL query submitted from clients Integrates results from multiple data sources onto a single ResultSet that is returned to the querying client Policy-enabled Federated Gateway

8. Information Filtering: Watson Policy Management Library • Policies are authored and deployed from within the management environment • Policy Enforcement Points (PEP) request policies decisions and supply runtime data to policy • Policy Decision Point (PDP) determines applicable policies and evaluates them Management Environment Operational Environment PoliciesMatched w/Request Policy Authoring Policy Decision Point PolicyRepository Policy Creation Decision Requests Deployment & Activation Policy Enforcement Point Policy Management Managed Environment 8

9. //// { //// "name" : “Hide UAV Locations", //// "type" : "OBLIGATION", //// "description" : “Conceal the location of our UAV assets", //// } Import Class com.ibm.watson.pml.pfg.schema.IRow:row; Import Class com.ibm.watson.pml.pfg.schema.QueryContext:queryContext; Strategy Execute_All_Applicable; Policy { Condition { // Make sure the query has a ASSET_TYPE column row.hasColumn(“ASSET_TYPE") == true && // Check if the TYPE column has the desired value (UAV) row.getColumnByName(“ASSET_TYPE").getCellData().getString() == "UAV“ && // Check if the affiliation of the requestor is not “US” queryContext.getAffiliation() != “US” } Decision { // Don’t show the locations of our UAV assets. row.getColumnByName("LOCATION").getCellData().setValue("0,0,0") } }:1; Example SPL Policy: Obligation

10. N5 N5 N7 N7 N4 N4 N6 N6 N8 N8 N3 N3 N9 N9 N10 N10 SQL Queries SQL Query N2 N2 N0 N0 N1 N1 N11 N11 Information Federation: GaianDB • A distributed, federated database approach • Follows the ‘Store Locally-Query Anywhere’ paradigm • Queries are routed to all of the nodes • flood query, retrieving only the data required to satisfy a query • Network of GaianDB nodes established using autonomic discovery of neighbours • configuration only required for data sources

11. PFG PFG PFG Design of PFG Client Query ResultSet Policy-enabled Federated Gateway Node Derby Engine: SQL Parsing, Compilation, Execution Policy Decision Point PEP / Result Filter Query ResultSet propagate GaianTable VTI - In-memory tables Policy Repository Federated Data Sources RDBMS MQ(tt) Flat files

12. Each PFG node instantiates a PEP and a PDP In current implementation, the set of policies is retrieved upon arrival of a new query Cached for every subsequent evaluation of rows of same query Policy repository can be centralized or distributed Can use GaianDB itself as policy repository Client application uses the standard Derby JDBC driver to connect to the PFG node Design Features of PFG

13. Performance of Policy Evaluation

14. Individual Query Time Scalability 485.1 431.2 377.3 323.4 269.5 Query Time (ms) 215.6 161.7 Average Query Time 107.8 Log. (Average Query Time) 53.9 0.0 0 200 400 600 800 1000 1200 Number of Nodes Evaluation: Avg. Query Time

15. Controlling information flows is a key capability for interoperation and federation of coalition operations Policies provide an expressive way for performing data filtering and transformation Policy-enabled Federated Gateways bring together federation and policy-based data filtering and transformation functionality Conclusions

16. Thank You! Questions?

17. An Example GaianDB Network

18. //// { //// "name" : "Allow access to UGV asset information", //// "type" : "AUTHORIZATION", //// "description" : “Allow access to the UGV assets", //// } Import Class com.ibm.watson.pml.policy.types.IAuthorizer:authorizer; Import Class com.ibm.watson.pml.pfg.schema.IRow:row; Strategy Execute_All_Applicable; Policy { Condition { // Make sure the query has a TYPE column row.hasColumn("TYPE") == true && // Check if the TYPE column has the desired value (UGV) row.getColumnByName("TYPE").getCellData().getString() == "UGV" } Decision { // Allow this result set to be returned. authorizer.allow() } }:1; Example Policy: Authorization

19. DB-based federation technologies Information sharing through DB “views” (static) Re-writing of SQL queries XML-based data integration Based on X-Query language Healthcare databases: XACML or X-GTRBAC JDBC proxies: C-JDBC, Sequoia, etc. Primarily used for load-balancing, reliability Related Work

20. Plugin Code Snippet (w/o error handling) public void setLogicalTable(String logicalTableName, ResultSetMetaData logicalTableResultSetMetaData) { // 1. Instantiate an authorizer/obligator PEP twoStagePEP = new StrictTwoStagePEP("pfg-pep", false); // 2. Obtain the schema to be filtered by policies this.logicalTableRSMD = logicalTableResultSetMetaData; this.logicalTableColumnCount = logicalTableRSMD.getColumnCount(); } public boolean filterRow(DataValueDescriptor[] row) { rowCount++; // Set the data of the queried columns in the row that will be evaluated if (filterRowObject != null) filterRowObject.setRowData(row); // Build the set of instance data for policy evaluation boolean decision = false; ArrayList<Object> oa = createObjectArray(); if (filterRowObject != null) oa.add(filterRowObject); // 2-step policy evaluation: authorization -> obligation decision = twoStagePEP.evaluate(oa.toArray()); return decision; }