Consider modifying technical impact to include aspects of (or rename to) Security Posture Change

[ahouseholder]

Goal is to address the insecure by design issue in areas like ICS. If I can upload new firmware without authentication or code signing verification, do I really care about any patches? There is a huge percentage of assets in ICS where access = complete compromise regardless of vulns. Possible decision values are trivial / minor / major or trivial / partial / total.
(Note: I pasted this from an internal list of suggested changes. Although I'm the opener of this issue, it's not my idea.)

[j---]

Arguments against doing this are that #35 and #5 might be everything that is necessary to support #14 , and supporting #14 would be the main point of this change.

[ahouseholder]

I don't really understand what the suggestion here even is. Is it that fixing the vul would require a security posture change? Is it that the status quo security posture is such a big hole that an adversary gains little by exploiting the vul? Is it that the response to the vul would be a security posture change (as opposed to a mitigation or fix)? Whose security posture -- a deployer? a supplier/vendor? both?

If we can't come up with something specific to do for this one beyond what #35 and #5 are already doing, this should be closed as either a duplicate or wontfix.

[j---]

It is as recommended by https://dale-peterson.com/wp-content/uploads/2020/10/ICS-Patch-0_1.pdf.

Many, if not most, ICS cyber assets are in a highly insecure state prior to a security patch being evaluated. This could be due to the insecure by design nature of the cyber asset or the ICS protocols in use.It also could be due to a large amount of missing security patches in the operating system, application, libraries, protocol stacks, and other third party software,due to lack of vendor approval for applying security patches.If applying the security patch being evaluated will not make it more difficult for an attacker to achieve their goal, then the risk reduction value of applying the security patch is minimal.This consideration is addressed in the Security Posture Change decision point.

That work has technical impact also. My observation is that security posture change takes technical impact and decides the relative technical impact based on the maintenance state of the device.
On reflection, it's probably not relevant for the supplier to know or have access to security posture change. But the deployer may want to consider this decision point. Currently, we do not have the deployer considering technical impact at all. Security posture change would be a consideration for how the deployer might more legitimately consider the relative technical impact.

Personally, I think this is part of #35, as you mentioned. But I don't think it's exactly a duplicate of #35.

[j---]

In #35 :

SSVC recommends a priority with which to act. This priority approximates the cost/risk of not acting, i.e., higher priority ~= higher cost/risk to not acting, i.e., you are more likely to be attacked and incur/cause losses.

If this is the case, then I think "security posture change" is a viable suggestion, and we should make a decision about it. It is possible that the risk of not acting should take into account prior inaction.

I am still very nervous about enabling a negative feedback loop where failure to act incentivizes future failure to act.

[j---]

I took this off the SSVCv2 project. Although the Dale Peterson piece makes a sensible argument for this change, I think we can safely de-prioritize this issue as something to consider later.

[ahouseholder]

Moved this from an issue to a discussion as there's still no clear action item after 2.5 years.