Homogenise Defence Behaviour

[andrewbwm]

We should come up with a way of handling how defences behave that is homogeneous and consistent. This conversation cropped up due to the fact that some defences have explicit bypass attack steps.

After a conversation between @skatsikeas and myself we've decided the following:

• Classify the various defences according to their expected behaviour
• Figure out if we want to adhere to one particular type of behaviour, speculative defences or innately imperfect defences, or blend the two
• Determine if we wish to separate every defence into two components, a speculative and a non-speculative one
• Determine if we wish to split off some of the defences that currently encompass discordant categories

Speculative defences imply the following:

• No unconditional bypass attack steps
• Bernoulli distributions
• Modeller's responsibility

Innately imperfect defence imply the following:

• Unconditional bypass attack steps
• Not tied to Bernoulli, but we still don't have researched default values in place
• The values would be static and the language's responsibility, maybe attacker profiles could be used to vary them according to different environments

[andrewbwm]

Here is a sketch cataloguing of the current state of defences in the language. SoftwareVulnerability and HardwareVulnerability defences were omitted because of their specialised purpose in depicting CVSS scores.

---

Legend: imperfect - some sort of innate bypass is possible speculative - used to speculate about potential attack vectors

- description E existing implementation + suggested addition \? uncertain classification/suggestion

---

Hardware
    # supplyChainAuditing
        - imperfect
        + innately bypassable

    # hardwareModifications
        - imperfect
        E bypassable via supplyChainAttack

Application
    # disabled
        - speculative

    # supplyChainAuditing
        - imperfect
        + innately bypassable

IDPS
    # effectiveness
        - imperfect
        - speculative
        E bypassable via fullAccess
        + innately bypassable

Data
    # dataNotPresent
        - speculative

IAMObject
    # disabled
        - speculative

Credentials
    # notDisclosed
        ? speculative

    # notGuessable
        ? technically imperfect, but not worth worrying about most likely

    # unique

    # notPhishable
        ? maybe a little imperfect, since you can steal digitised
          biometrics/key cards, but probably does not apply

User
    # noPasswordReuse

    # securityAwareness
        - imperfect
        ? speculative
        + innately bypassable

Network
    # networkAccessControl
        - imperfect
        E bypassable via physicalAccess
        + innately bypassable

    # eavesdropDefense
        - imperfect
        E innately bypassable

    # manInTheMiddleDefense
        - imperfect
        E innately bypassable

ConnectionRule
    # restricted
        - speculative
        - imperfect
        + innately bypassable

    # payloadInspection
        - imperfect
        + innately bypassable

Vulnerability
    # remove
        - speculative

[andrewbwm]

Conclusions after the coreLang weekly meeting on the 4th of May.

We will keep both non-bypassable and bypassable defences. Classify defences as default/regular and explain that a subset of them are bypassable. Pick reasonable probabilities for the bypasses.

Do not separate defences into two components, bypassable and non-bypassable, but mention explicitly that the bypass attack steps can be changed by the modeller by tuning the probability distributions associated with them.

We have yet to decided whether or not we wish to split some of the existing defences that are cognitively overloaded or not.

[andrewbwm]

Updated and simplified cataloging for the defences.

Unconditionally bypassable defences require an automatic bypass that allows the attack step to trigger even when the defence is enabled.

Legend:

- description E existing implementation + suggested addition \? uncertain classification/suggestion

---

Hardware
    # supplyChainAuditing
        + automatic bypass

    # hardwareModifications
        E bypassable via supplyChainAttack
        + automatic bypass

Application
    # disabled

    # supplyChainAuditing
        + automatic bypass

IDPS
    # effectiveness
        E bypassable via fullAccess
        + automatic bypass

Data
    # dataNotPresent

IAMObject
    # disabled

Credentials
    # notDisclosed

    # notGuessable
        ? technically unconditionally bypassable, but not worth worrying about most likely

    # unique

    # notPhishable
        ? maybe a little unconditionally bypassable, since you can steal digitised
          biometrics/key cards, but probably does not apply

User
    # noPasswordReuse

    # securityAwareness
        + automatic bypass

Network
    # networkAccessControl
        E bypassable via physicalAccess
        + automatic bypass

    # eavesdropDefense
        - automatic bypass

    # manInTheMiddleDefense
        - automatic bypass

ConnectionRule
    # restricted
        + automatic bypass

    # payloadInspection
        + automatic bypass

Vulnerability
    # remove

[andrewbwm]

We have yet to decided whether or not we wish to split some of the existing defences that are cognitively overloaded or not.

After the May 18th meeting we've decided to not split the polysemantic defences(effectiveness on IDPS and restricted on ConnectionRule). Since the modeller is expected to tune the values of the bypass attack steps they can also adjust it to fit the way they wish to use the defence.