search

mal-lang / coreLang

A probabilistic attack simulation language for the (abstract) IT domain
https://mal-lang.org/coreLang/
Other
10 stars 12 forks source link

Rework data in transit #41

Closed andrewbwm closed 3 years ago

andrewbwm commented 3 years ago

Data in transit should only be written from an Application if the data are sent via a Network that has a outgoing ConnectionRule associated with the Application.

Data in transit can be read if accessible either the Network or any Applications through which they transits. If accessed over a Network they can be written as well. However, if they accessed through an Application they should only be written if they are sent from that Application, not received. The current implementation on master created scenarios where access on the Application receiving the Data were able to trigger a write on them.

In addition to this some attack steps on Data in transit were triggered where they should not have been. This led to all Data in transit associated with the same Application to be compromised if any of the Network assets they were connected to were compromised.

andrewbwm commented 3 years ago

I would like to create some unit tests that check for this behaviour in the future.

andrewbwm commented 3 years ago

I have reviewed the code and it seems okay. My only comment is that you have defined attack steps with the same name in two different assets, like the writeDataInTransit and the denyDataInTransit attack steps (one in the Data asset and one in the ConnectionRule asset) which might be a little bit confusing.

I agree, I got confused when I was debugging the new implementation too. I will change the names to something distinct before I merge the change in.

Implemented in f7452ab.

Thank you!