Securing Workflows Using Microservices and Metagraphs^†

Round 1

Reviewer 1 Report

Not so clear what happens if something goes wrong in the workflow. For example refferring to Fig. 2/3 Do you manage the workflow status/history?or if not all the phases goes in the correct way you have to start again from the Owner?

Perhaps the chapter on related works could be a support to the work done if placed before the definition of your model.

Author Response

Dear Reviewer,

Thank you very much for your review, please find our response to it below.
You can also find this information in the revised version which you should also receive.

We have considered cases where there is a conception error in the workflow. However, this is out of the scope of the paper. Our work with the infrastructure mainly deals with making the workflow possible securely in a multi-party scenario. Therefore, we assume that any disputes or errors can be discussed between those parties, and then the policy updated to reflect the resolution of the conflict. Since the main purpose of this part of the work was to address how to deploy a workflow securely using microservices, we felt addressing this issue was not necessary.

Thank you again for your review!

Reviewer 2 Report

Review for the paper titled: Securing Workflows Using Microservices and Metagraphs

 

The paper is an extended version of an IEEE published conference paper. This provides the reviewer confidence that the work presented is of a certain quality but the question is how original is the work presented on this paper? I hope it becomes clear when further reading the paper.

 

Abstract: 

-The Abstract is very well-structured and informative. It clearly states the problem (how to secure data on a workflow), the approach of the authors (infrastructure deployment and verification method) and the results (“overall, this infrastructure….”) -although the authors could be more specific on the findings of the paper… the last sentence is generic “the methods helps us” … in what way?

 

-Also a minor comment: There is an extensive first-person use throughout the Abstract (and maybe the whole paper) “We implement… we verify… we find….”. Try to change some sentences to third person… e.g. the authors, this paper, this work…

 

Introduction

-The Introduction provides a smooth entry on the problem by explaining the difference between data breaches and data leaks, and where the focus of the paper is. But then the narrative breaks and it is a blend of what the authors aim to do, what is mentioned in the literature and again the contributions of the paper.

 

-In more detail: (line 40) very early in the Introduction the authors reveal their aim but soon again (line 46) they revert back to explaining basic concepts, then (line 55) provide a description of the problem in general, (line 64) brief update on current research and from there on (line 75) the focus of their paper.

 

-My suggestion for the Introduction is that it needs a clear restructuring. Given the content please organise it in three distinct parts (maybe sub-sections?): (a) Problem statement (e.g. lines 18-39), (b) Basic concepts, existing approaches, current work -NOT your intentions or line of work, (c) brief description of your approach and expected contributions of your work.

 

-Maybe (c) can be a separate section altogether where you describe your comprehensive approach on a high-level, state the research methodology (that is absent from this work) and then state your contributions (lines 91-109) ... how these contributions emerged? What are the research questions? What are they significant to be investigated?

 

Threat and security model

-The section starts by describing a workflow as an example… is the example taken from literature? Is it imaginary? It makes sense as an example (it clearly communicates the problem, i.e. data leakage) but it need to be grounded so that the solution has any value and can be generalized or applied elsewhere.

 

Infrastructure and Proof of concept

-The Policy store is located  only on the Owner and informs the policy boxes everywhere? I can understand it from the text (lines 181-182) and figure 3 caption but it is not clear on the figure. Maybe make the dotted line more explicit.

 

-(lines 197-206) is this an original contribution? Or have you taken inspiration from elsewhere?

 

-sections 2, 3 and 4 are short and it seems that they are taken “as-is” from the IEEE paper…. If this is the case please expand them and elaborate more.

 

Proof of concept

-(lines 223-224) it is very important that the data and code are publicly available… well done!

 

(section 6) Metagraphs

Very interesting that the paper not only covers the technical aspects but also the higher-level specification. Good choice for implementing meta-graphs but again there is no ground for your original example (perhaps too high-level for depicting with meta-graphs?)

 

-have you considered using BPMN to model your process and then a particular workflow (process instance)?

 

-is Figure 13 original? Is it your contribution? It seems to be out-of-context with the core of the paper… transformation from YAWL to a metagraph…. 

 

(section 8) Related works

-I know it is a trend to move the Related work towards the end of the paper but it makes no sense to me…. Optional suggestion to move section 8 and help with the section 1 restructuring….

**Overall** 

Although the paper started consistently in the end it is like reading two merged works: (a) on on the technical aspect and (b) one on the workflow aspect of the process. I am not convinced of how there are related, connected and provide a joint contribution. This explain the “list” of contributions in section 1 without  further justification of how there where produced, what is the rationale and in which order.

 

I think the paper is ‘busy’ … the work is done but it needs a better narrative on how the technical and higher level requirements are handled under a common framework. Maybe consider breaking the paper into two more consistent works. Nevertheless it need to have a more research-oriented scientific narrative and less of just a description of the work carried out and its basic concepts (meta-graphs, YAWL, etc.).

Author Response

Dear Reviewer,

Thank you very much for your review, please find our response to it below.
You can also find this information in the revised version which you should also receive.

Concerning the abstract, reviewer 2 indicates we should be more specific about the findings of the paper.
This has been addressed by reformulating the last sentence and being more explicit about the findings.
Reviewer 2 also suggested we should vary our use of the first-person in the abstract.
This has also been addressed.

Concerning the introduction needing restructuring, we grouped relevant information in the subsections that were proposed by reviewer 2, and added/modified some sentences to make the text easier to follow.
Reviewer two was also wondering about the example described in the threat and security model.
This is an example evolved from concepts in the literature, although simplified for the sake of the example.
This was made clear by adding a sentence in this section.

Reviewer 2 pointed out that Figure 3 was not clear on whether the policy store was located only on the Owner and informed the policy boxes everywhere.
We changed the figure to make it more explicit.
We also want to reassure reviewer 2 that the paragraph starting with ``Once a service has completed...'' in the Infrastructure and Proof of Concept section is a benefit we gain from using a service mesh.
This is not included in the paper, but we indeed verified ourselves that the whole key distribution process is secure.

Sections 2 (now 3) was extended to give more information about the model.

Concerning the metagraphs section, we made clear that our workflow example was coming from the YAWL Foundation website, which was realized in collaboration with the Australian Film Television and Radio School (AFTRS), with the help of domain experts.
We have considered using BPMN (and others, UML, BPEL), but ultimately decided to use YAWL as it has formal semantics and stronger support for workflow patterns, but is also simpler than alternatives\footnote{http://www.yawlfoundation.org/pages/support/faq.html}.
Figure 13 is original and our own contribution.
It illustrates how we started from the YAWL file (which is basically XML), and transformed the elements possibly found in YAWL to a metagraph.
To be specific, there are no figures which are not original and our own contribution, with the exception of Figure 10 which represents the workflow from the YAWL Foundation website\footnote{http://yawlfoundation.org/pages/casestudies/yawl4film.html}.
This was made explicitly clear in the paper.

Finally, reviewer 2 expresses that the paper reads like two merged works, and that's because it is the case.
We were asked to merge those two works for the extended version.
The first one was on using the microservices architecture to deploy workflows securely.
The second was on using metagraphs for policy verification.
However, the work on metagraphs comes as a support to the deployment of a workflow using the infrastructure described in the first work.
In other words, the first paper is about the secure deployment of the workflow, and the second work is about the continuous verification of the security of the deployment of the workflow.
The workflow would therefore be deployed using the infrastructure, and its implemented policy would be tested to see if it is correctly enforced.
Moreover, the implemented policy is also verified against the specification before deployment to make sure it corresponds to the will of the policy administrator.

Thank you again for your review!

Round 2

Reviewer 2 Report

All my comments have been sufficiently addressed