False positives (DKIM, DMARC, SPF) due unset clearance level

[jordy-kennisnet]

Describe the bug Findings (DMARC, DKIM, SPF) on domain when clearance is L0.

To Reproduce

1. Add a domain, one of which MX record points to third-party domain, such as protection.outlook.com
2. Scan the domain for DNSrecords
3. Do not set clearance for DNSzone outlook.com

Expected behavior I don't expect any findings on domains where no clearance has been given. Finding that I can expect is that there is a domain related to your own environment and has no clearance, so you have blind spot.

And otherwise, I would expect the related domain is get a standard L1 clearance level.

Screenshots

Findings

Objects

OpenKAT version V1.7rc3

[underdarknl]

These probably exists on the domains because we do not cascade to outlook.com from its subdomain. Maybe we should? (but don't cascade into the tld)

[jordy-kennisnet]

Your solution ensures that the false positives are gone, but the question is whether that is the right solution. SPF, DKIM and DMARC are only relevant for your own domain names/SaaS platform you are using, as they protect against phishing and email integrity. For the domain outlook.com, but also protection.outlook.com this is not relevant to your own environment.

[noamblitz]

Might be a more suitable solution to set findings as "irrelevant" then?

[underdarknl]

A few solutions might be possible:

• Inherit the declaration also to the parent zone (this might include too much zones, and should at least exclude the tld)
• For certain protocols, decide in the boefje that we will also query the parent zone, disregarding that it does not have a indemnification. Various protocols are stacked from top to bottom, and if only a lower zone is indemnified, we cannot conclude on all the details. (eg, spf, CAA, hsts)
• Allow Bits to know the indemnification of the objects they act on, so they can fine-tune the message from 'its broken' into 'its not vissible and might be broken'

[zcrt]

I agree with @jordy-kennisnet; mail related findings are only relevant if the domain of interested can or will be used by the organisation subject to scanning for mail related activities. If it is not possible to automate this logic then I agree with @noamblitz that it should be possible to set mail findings as irrelevant/hide them for a specific domain (unless it is somehow actively used to spoof e-mail from the domain of interest course).

[underdarknl]

There is still a difference between collecting this information, and showing this information. If outlook is used somewhere because its your MX-server, it should be included. If its the MX-server for a Javascript hosting url, then not so much. This comes down to smarter querying I'd say. Traverse some paths (eg, trough the direct MX-record), but not trough asset links on the website, when looking for these classes of findings.

[noamblitz]

Fully agree with @underdarknl that this is a reporting problem and not an octopoes problem

[dekkers]

I don't agree this is only a reporting problem. We should not create these findings in the first place. If the clearance level is zero, we will never fetch DNS records and currently we will always create false positive findings that these records don't exist. I don't think it's a good design to just fill the database with nonsense findings and then try to exclude these findings everywhere. That will be very hard to get right, because it is not just reporting, it's also things like aggregation in dashboards where we will probably want to show things as the total number of findings over time in an organisation.

Also in general even if we have the clearance level to run the DNS record boefjes/normalizer as far as I know we will generate a false positive if the bit runs before the boefje/normalizer. I think that is also something that should be fixed.

[noamblitz]

Problem is that you do not know whether these objects should be L0. So it might be better to create a feedback loop with the user: this object might be configured improperly but we do not know whether it is part of your organization, do you want to mark these findings as irrelevant?

[dekkers]

I think this ticket show multiple issues we should look into:

• Some objects might not inherent the desired clearance level because doing it automatically for all such objects might not be correct. We might want to make the user aware of such objects so that the user can decide to increase the clearance level.
• Just having a single level for an object might not be granular enough to indicate relevance. For example when javascript/css/fonts/etc. is hosted on a third party CDN e-mail issues are not relevant, but it is relevant if the CDN webserver is vulnerable or if it serving javascript with malware.
• When an object is L0 we should not create findings when certain data is not in the graph because with L0 we will never fetch this data.
• A related issue to this is that bits should not create false positive findings that certain data is absent before the necessary boefjes/normalizers have run.
• There is another potential issue with for example DMARC and subdomains. If a subdomain is L1 but the domain is L0, will we fetch the DMARC record of the domain? Because if the subdomain doesn't have a DMARC record the DMARC record of the domain is used. This means that we need to fetch that record before we can decide whether to create a DMARC finding.

[TwistMeister]

Should be fixed after merge of https://github.com/minvws/nl-kat-coordination/issues/614