Fix path finding #192
Fix path finding #192
Conversation
| for curr_node in path: | ||
| if curr_node.type == 'or' and curr_node not in visited: | ||
| assert any(p in visited for p in curr_node.parents), ( | ||
| f"Node {curr_node} was reached before any of its parents were" |
There was a problem hiding this comment.
@sandorstormen the test fails on this line. Is some validation missing in the greedy a star so this can happen or am i using it the wrong way?
The language used is a bit weird, but there are definitely paths that are correct, and the greedy a star suggests a path which is impossible. please check also if this loop that validates the path looks sane.
There was a problem hiding this comment.
The attack graph has to be pruned as a first step. Otherwise the logic of the attack graph works in a different way.
There was a problem hiding this comment.
Then we have a bit of a problem.
- Viability and necessity is not stored as AttackGraphNode properties anymore but instead in the simulator since:
- It can differ depending on how you run the simulations after defense step ttcs were introduced, so it could not be stored in the nodes any more.
- It also got rid of the deepcopy of the attack graph on each reset in the simulator, since no destructive actions are performed on the graph anymore
- Pruning is not performed in the simulator.
- unviable and unnecessary steps are ignored by default instead, this can be turned off with settings.
Necessity/viability is calculated the same way as before (based on defense/existence steps status and the structure of the graph). Pruning can still be performed with a function, but I don't see why it would be used (ignoring them instead of deleting/pruning the nodes means the same logic applies and we don't have to perform the destructive act of pruning the graph which often means we need to keep a deepcopy of it).
The ideal case from my point of view would be that the path finding algorithm either takes in a simulator (which contains viability and necessity information) or that it takes in viability and necessity as separate data structures and ignores nodes that are unviable or unnecessary when doing the path finding.
The non ideal case would be to run pruning before doing the path finding, which I will do in the meantime just to test the path finding.
Any thoughts about what I wrote?
There was a problem hiding this comment.
All of this seems fine to me. What I have done is to follow the patterns that Andrei has set out earlier for the MAL simulator. I included the the pruning because of the particular way the defense steps work. If a defense is de-activated in coreLang, sometimes, the effect is as if you have compromised a step by default.
Examine the attack graph below:
NOTE: This is only an example, you would have to talk to @andrewbwm for the details here. Please try understand without getting hung up on the semantics.
The attacker enters and exists at the | ...-steps. If the !E someAsset-step is active, then the attacker cannot perform attack step & Y. If it is not active, then the attacker should be able to perform & Y. Therefore we either prune the attack step or put it as an entrypoint. Remember that defenses invert OR-steps.
For a path planning algorithm, we need to pre-compute the attack graph and can't do checks in the middle of selecting nodes. (| X if it's dangling. It's a case of me adapting to how the MAL simulator was doing things.
the path finding algorithm either takes in a simulator
Using the MAL simulator for path algorithms sounds tricky, since you can't backtrack. It would be better to just input them as separate data structures.
No description provided.