izar
Proposal: isHardened should not be a property on its own
Considering the example you provide in the readme, and thinking logically about what hardening of a system means, "is not hardened" should be a threat on its own, with conditions that indicate the hardening state (which could be none, partial, or "complete"). This would also require/allow hardening detection for individual object types (e.g. web server vs database server). Consider something like this condition for a web server being not hardened:
condition : "target.RunsAsRoot is True and target.exposesHTTP is True" (obviously psuedo-conditions)
What would be a proper dictionary of properties and their values? For example,
runsAs = (Root, Administrator, User, Nobody) exposes = (HTTP, HTTPS, ...) ?
I believe this might be more extensible than a ton of on/off switches, thoughts?
Is the OS patched is another property to look at. I guess to answer the list of properties required, we need to look at when exactly we think a system is considered hardened? What are the criteria or things to look for at minimum?
There are definitions for hardening - from sources like DISA and CIS, to individual component vendors. Patching is a part of hardening, add covers more than the OS. We should do what everyone does and summarize what hardening "means" and run with that for first pass; besides it is the only thing possible at design time. We can't know at design time if the components will be patched, we can know if insecure protocols are to be used (as a couple of examples).
But do we have to go itemized? Or could we get away with something that refers to the process, as in
isHardened = ("No", "Planned", "Yes")
At the end of the day I believe we want developers to be able to write the description code on the fly, and should strive to have only as much detail as necessary, to avoid having to go to documentation, etc. Perhaps we should have objects self-check for completeness at runtime, suggesting fields that need more information before running the threats?
I moved the current attributes into Python "@property". We need to decide if we want to leave everything open or if we want to use enumerations for certain values. I'm inclined to follow MSFT in the choices, but only up to the point where we get 1::1 functionality with their tool, and then we start opening up further and going farther. Ideas?
Got some feedback from potential users - the issue of granularity is important. I suppose it would be great if we could come up with threats that happen at many levels, as in "is it hardened? yes/no" leading to a "it should be hardened" threat, but then smaller granularity questions like "is it patched" and "does it have more services than needed" (just throwing it out there....) lead to "it is not hardened" that then leads to "it should be hardened".
Have been thinking about derived properties for an incubation effort. Will look to mock something up.