Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider a "Depth of Defenses" decision point #715

Open
ahouseholder opened this issue Feb 21, 2025 · 3 comments
Open

Consider a "Depth of Defenses" decision point #715

ahouseholder opened this issue Feb 21, 2025 · 3 comments
Labels
enhancement New feature or request

Comments

@ahouseholder
Copy link
Contributor

Is your feature request related to a problem? Please describe.

Some organizations consider the nature of their monitoring and defenses as a factor in their vulnerability management processes. Salient features seem to include things like what kind of systems are capable of detecting exploitation attempts, or how many such mechanisms are in place. SSVC currently has System Exposure, and while that indirectly touches on the "how many" aspect of network defensive layers, it is not quite the same concept. Examples of the "what kind" aspect include endpoint security, IDS, IPS, WAF, network firewalls, etc.

Describe the solution you'd like

It's not clear that differentiation by kind of defense would be pragmatic for a decision point to be constructed. But the how many aspect could be easily chunked into 0, 1, many or something similar to keep it from turning into a hard question to answer.

Additional context

As with #714, this is probably more useful for larger enterprises than small organizations, but we already know it's a dimension that some deployer vulnerability responders are paying attention to.

@ahouseholder ahouseholder added the enhancement New feature or request label Feb 21, 2025
@j---
Copy link
Collaborator

j--- commented Mar 5, 2025

Would this be functionally a new System Exposure decision point with four or five options, rather than a totally new decision point?
System Exposure is already effectively chunked into "none" "some" and "many" as far as an answer to this question. I think System Exposure is agnostic as to what kind of defense means "exposed" so that it can generalize across vulnerability types. Would this proposal lead to different kinds of decision values for different kinds of vuls?

@ahouseholder
Copy link
Contributor Author

ahouseholder commented Mar 7, 2025

Maybe it is the same as or a refinement of System Exposure. I had been thinking of System Exposure as more about the network constrictions between the Internet and the system in question. But that doesn't say much about the instrumentation and monitoring. For me, I think the distinction is that exposed is not the same as uninstrumented. If you have to be exposed, then it's better to be instrumented than not.

So let's hypothesize a Defense Depth decision point that has maybe none, few, many as value options. (No, I don't recommend those exact terms, this is just for conversation purposes.)

This gives the combinations:

System Exposure Defense Depth
Small Many
Small Few
Small None
Controlled Many
Controlled Few
Controlled None
Open Many
Open Few
Open None

Open, None feels different to me than Open, Many, as does Small, None vs Small, Many. Seems like there's probably something in either a NIST document, CRR, or RMM that could help us refine the concept. Could even be something that is more of an "organizational context" than "system focus" --- monitoring posture, maybe? I don't know, further refinement needed.

@j---
Copy link
Collaborator

j--- commented Mar 11, 2025

Can we have some examples of stakeholders that productively use (or should use) this info to change behavior?
I tend to just ask this question to hedge against https://en.wikipedia.org/wiki/Information_bias_(psychology). This one is not intuitive to me where it helps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants