-
Notifications
You must be signed in to change notification settings - Fork 36
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
Comments
Would this be functionally a new System Exposure decision point with four or five options, rather than a totally new decision point? |
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 This gives the combinations:
|
Can we have some examples of stakeholders that productively use (or should use) this info to change behavior? |
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.
The text was updated successfully, but these errors were encountered: