Do we want to create an IDPS asset?

[andrewbwm]

Some of the mitigations in the MITRE list suggest that mechanisms should exist that directly restrict the likelihood of an exploit from succeeding.

Right now the suggested implementation for those mitigations is to use the "Remove" defence on each impacted vulnerability manually. However, we may wish to create an asset that can be associated with Applications that limits the probability that all the vulnerabilities that target it can be successfully exploited.

This may complicate the design for the time being and we may wish to introduce it post version 1.0.

[andrewbwm]

This conversation also relates to how we want to represent protocol based(Filter Network Traffic) versus payload based(Network Intrusion Prevention) filtering.

@mathiasekstedt expressed some concerns regarding the "Filtered" defence name. It can be a bit confusing that the payload filtering is done by the "Filtered" defence and protocol based filtering is done by the "Disabled" defence.

[mathiasekstedt]

Perhaps they can be renamed to what you say: "Payload filtered” and "Protocol filtered”?

They way I think about it is also that the % value essentially represent the effectiveness of the NIPS? If true, this could preferably be explained in the info section.

On 20 Aug 2021, at 11:40, Andrew B @.***> wrote:

This conversation also relates to how we want to represent protocol based(Filter Network Traffic https://attack.mitre.org/mitigations/M1037/) versus payload based(Network Intrusion Prevention https://attack.mitre.org/mitigations/M1031/) filtering.

@mathiasekstedt https://github.com/mathiasekstedt expressed some concerns regarding the "Filtered" defence name. It can be a bit confusing that the payload filtering is done by the "Filtered" defence and protocol base filtering is done by the "Disabled" defence.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mal-lang/coreLang/issues/47#issuecomment-902569976, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSROOBU4HQEWRCUPZWW4IDT5YPHRANCNFSM5AZX2YKQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email.

[andrewbwm]

Perhaps they can be renamed to what you say: "Payload filtered” and "Protocol filtered”? They way I think about it is also that the % value essentially represent the effectiveness of the NIPS? If true, this could preferably be explained in the info section.

This issue has been addressed in #46.

Disabled has been renamed to Restricted and the info text has been adapted to better describe its dual purpose. This may still not be perfect. Filtered has been renamed to PayloadInspection.

This does not mean that the IDPS issue has been resolved since it could still be relevant for an Application asset, but the needed for it has been somewhat assuaged, which may make it more palatable to push it to v1.1 conversations rather than a v1.0 one.

[andrewbwm]

Because of the issues with payload insepction(https://github.com/mal-lang/coreLang/issues/45#issuecomment-926641456) we may wish to introduce the IDPS asset to better account for host based payload inspection.

[andrewbwm]

First implementation of an IDPS asset can be found in #64.

[andrewbwm]

Implemented in #64 and #65.