search

mal-lang / coreLang

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

Defence bypasses #78

Closed andrewbwm closed 2 years ago

andrewbwm commented 2 years ago

Implement bypass attack steps for the defences can be bypassed given additional effort by the attacker.

The defences for which bypasses were implemented can be found in #76 in the list in the comments flagged as requiring an automatic bypass. The probability distributions on the bypass attack steps need to be researched more since they were chosen to be broadly reasonable in magnitude, but without any significant consideration.

The design pattern generally used for these bypasses is as follows:

| attempt
-> successful,
   bypassDefence

& successful
-> impact

| impact
-> <actual disruption>

#defence
-> defenceBypassed

| bypassDefence
-> defenceBypassed

| defenceBypassed
-> successful

Some simpler attack steps omit the successful step and simply have an & impact. Perhaps in the future these should all be refactored for legibility and uniformity purposes. This pull request also contains some changes that made it so that some of the existing attack steps were updated to the attempt -> successful -> impact pattern.

In addition, there is a commit that renamed some of the attack steps related to the unsafe user activity as a result of an attacker's social engineering efforts on the Application asset to make them slightly less confusing to understand.

PhysicalAccess on the Network asset was also reworked to work with the new bypass system and lead to another bypass vector.

andrewbwm commented 2 years ago

I have done a thorough code review and everything seems okay (and easier to understand) to me (until of course we detect a bug, which I wish away). I also really like that for once we follow a pattern throughout a language!

I agree, but I've also not fully propagated that pattern, we may do so when we do our final version 1.0 code review(#77).