Leaks-when analyser has a a user-facing frontend application (part of SQL-privacy analyser) that allows to extend models by attaching SQL scripts to its elements. SQL queries are added to tasks and SQL database schemas are added to data objects. SQL scripts are attached by adding specific labels into the XML code of the model. The editor uses pleak-leaks-when-ast-transformation component as a communication provider between the editor and pleak-leaks-when-analysis tool to perform an analyze on the extended model to combine and present the results. Editor, connector component and analysis tool have separate codebases, but they are all required to use the full functionality of the analyser.
Leaks-when analyser is accessible through Actions menu (with burger-menu icon) under each model in own and shared models/folders lists of frontend - link “Open in SQL editor”.
Adding information to model elements for analysis
Clicking on tasks or data objects opens a menu on the right side of the page (in sidebar). You can add SQL scripts (in a form of stored procedures and queries) to tasks. Database information (in a form of database schemas) can be added to data objects.
Running the analysis
First select the data objects that are of interest (the analysis will show which inputs affect the chosen data objects and how). Clicking on LeaksWhen Report button opens analysis results panel (entitled Analysis results) on the right side of the page (in sidebar). There you can see analysis results for each selected data object (ordered as they are ordered on the model). Under each task you can expand the view to see all attributes in this table and open attribute specific result-graphs by clicking “View graph” links. Note that in case there is a conditional output then there may be many leaks-when graphs for one output field. For example one for the if and the other for the else branch.
SQL leaks-when output is a directed graph where the final node is a Filter. The first input (leaks) to the filter corresponds to the computation of the value that is given as output and the second input (when) corresponds to the conditions under which the computed value appears in the output. The other branches summarize the computations carried out by the workflow.
In general, the supported queries are SELECT queries with possible joins, various where statements and Group by as well as order by. The analyzer uses PostgreSQL.
create or replace function function_name( inputs) returns TABLE(definition ) as $$ select ... into ... From (join) where... Group by... Order by.. $$ language SQL IMMUTABLE returns NULL on NULL INPUT; select ... into ... From (join) where... Group by... Order by..;
The supported aggregations are SUM, MIN, MAX, COUNT, and AVG.
The supported operations are +, -, /, *, @ (geographical distance), ^, =, <, ⇐, >, >=.
The names of the used tables must match the inputs of this task on the model. INTO should specify the table that is used as the output of that task on the model.
The updated set of operations supported by the SQL leaks-when front-end can be seen in this file in the repository. The operations supported by the analyzer can be seen in this file in the analyzer code.
Sharing policies can be attached to the TODO
SQL leaks-when analysis supports BPMN collaboration models (models with pools and messages in between them). It supports start and and events, intermediate message receive events, parallel gateways.
Sending tasks should not contain SQL queries.
Joining PE-BPMN extended disclosure report with leaks-when gives rise to simplified leaks-when outputs.
The source code of the analysis tool is available at pleak-leaks-when-analysis repository. The user interface of the analysis tool consists of pleak-leaks-when-ast-transformation and pleak-sql-editor.
Our analysis has been implemented in OCaml, using the OCamlgraph library for certain transversals of summary dependency grahps (SDGs). The integration of the analysis into the tool is somewhat peculiar, but the chosen way makes the integration very simple. The analysis is applied to a workflow defined at compile time in the source file RAInput.ml of the analyzer. Hence the analyzed workflow is expressed as an OCaml expression belonging to a variant type.
In order to execute the analyzer on different workflows, the analysis tool performs the following steps:
source of our analyzer.
for RAInput.ml (and the topmost source file), and not for the parts of the analyzer that generate and simplify the SDG or read the result out of it. This takes very little time.
the folder is given as a command-line parameter.