Repository navigation
Introduce reverse matches on cascading rules to enforce scope #761
Description
➹ New Feature implementation request
Is your feature request related to a problem?
As a pentester, I want to gain confidence in letting run secureCodeBox cascading rules unattended, so that I have assurance that secureCodeBox will only scan in-scope targets given the engagement.
Currently, cascading rules are triggered based on whether a static value exists in the finding.
spec:
matches:
anyOf:
- category: "Subdomain"
osi_layer: "NETWORK"
scanSpec:
scanType: "nmap"
parameters:
# Target Port of the finding
- "{{location}}"It is however not possible to verify whether the matched subdomain is present in the given scope.
A practical example engagement scope:
example.comsubdomain.example.com12.34.56.78/24
A pentester would like to investigate whether more subdomains exist so runs AMASS, it returns example.com, subdomain.example.com, and subdomain2.example.com. Nmap is triggered on all of them, while subdomain2.example.com was out-of-scope. Furthermore, it should have been verified whether example.com and subdomain.example.com even resolve to an IP in 12.34.56.78/12.
Describe the solution you'd like
In the cascading rule spec, we can introduce a field allowing rule developers to do reverse matching on scan labels.
metadata:
labels:
"engagement.scope/domains": "example.com,subdomain.example.com"
"engagement.scope/cidr": "12.34.56.78/24"Then in cascading rule yaml:
spec:
matches:
scanSelector:
allOf:
- key: "engagement.scope/domains"
operator: Contains
value: {{attributes.host}}
- key: "engagement.scope/cidr"
operator: InCIDR
value: {{attributes.ip}}
anyOf:
- category: "Subdomain"
osi_layer: "NETWORK"
scanSpec:
scanType: "nmap"
parameters:
# Target Port of the finding
- "{{location}}"scanSelector would be a similar field to the Kubernetes-native labelSelector, but fully interpreted in the cascading scans hook. This also allows us to define special operators (like Contains or InCIDR).
allOf is used in the example above. Would anyOf or noneOf have any further use cases?
In any case, I'd like some feedback on the problem and potential solution 🤔 . What do you think?
Activity
malexmave commentedon Oct 29, 2021
I like the idea! A few points:
anyOf: Maybe a customer can say "in scope are this domain (whatever IP it resolves to) and anything inside the IP block A.B.C.D/24", so I think it should be supported. Alternatively, if we go away from the pure network setting and look at repo scanning, for example,anyOfcould be used to implement an allowlist of permissible GitHub / GitLab organizations that can be included.noneOf: "Feel free to scan all of our infrastructure and domains, but make sure not to hit this one specific host, because we know it is brittle and if it crashes it will take down our business for 24 hours, we're working on it already."Further operators similar to
inCIDRthat could be considered:subdomainOfhasSubstring(e.g., to filter a specific prefix of Git repos for Git-repo-scanner, "Never scan repositories in our GitLab for projects belonging to our customer Secura, they don't allow it")largerThan,smallerThan(for numeric parameters, "never operate on ports larger than 1024")I mean, if you really want to go nuts you could also have a mode where it calls out to a specified webhook, which gets the data and then returns a true or false to decide if the scan should proceed, but that seems a bit overkill (although it would allow you to also take additional things into considerations, like "I have found this domain name through a scanner, but the scanner did not provide me with a resolved IP, so I cannot match it against the IP allowlist and need to pull in extra data to decide").
J12934 commentedon Oct 29, 2021
Hi,
i like the idea 👍
Two things sprang to my mind while thinking about it:
engagement.scope/domains&engagement.scope/cidrwould probably have to be annoations as the values from the example will not be accepted by kubernetes as labels. If you try to apply a scan with the example labels the apiServer will complain that it doesn't match the regex. Annotations allow a far wider number of characters. Thats not a big deal but should maybe be reflected in the naming of the attribute. MaybescanAnnotationSelectorto make sure people don't get confused.scanSelector(OrscanAnnotationSelector) Maybe like this:EndPositive commentedon Nov 2, 2021
Thanks for the feedback @malexmave @J12934 😃 . In the coming weeks, I hope to create a draft PR.