Attribution Explainability Ingrid Attribution Explainability provides detailed explanations for how infrastructure is attributed to an organization’s assets. The data fields give insights into domains and IP/CIDR. Domain Source Common Reason Codes Evidence for Domains Summary Explanation Step-by-Step Relationship Breakdown How to Interpret and Use the Evidence Domain Source The domain attribution process identifies why and how a domain is linked to the organization. It uses the Source and Attribution Reasons fields to provide transparency. Important Notes Historical domain data (prior to [release date]) may lack attribution reasons, so “No Source” is displayed in the Source field. Detailed attribution data is available on the Attribution tab of the Infrastructure page, but older records might not always be available in the Change Log. Source The Source field indicates the method used to associate the domain with the organization. It can have the following information: Customer-Provided Added upon request by the organization. DNS Domain Identified using DNS records. GIA Domain Attributed through the Bitsight Graph of Internet Assets (GIA) using machine learning and data correlation. Primary Domain The main domain representing the organization online. Registered Domain Derived from WHOIS registration information. Attribution Reasons The Attribution Reasons field explains why an asset (such as domain) is linked to and attributed to an organization. This can include: Evidence from domain registrations (e.g., WHOIS data). Correlations with other infrastructure attributed to the organization. Manual research or customer-provided data. Customer-Provided Company-provided assets. Slug Name: CUSTOMER-PROVIDED DNS The domain, attributed due to its DNS records. Slug Name: dns_domain GIA Domain The domain attributed to the organization using the Graph of Internet Assets (GIA). Slug Name: graph_domain Primary Domain The primary domain this organization uses as its internet presence. Slug Name: primary_domain Registered Domain The registered domain, attributed based on WHOIS registration information. Slug Name: registered_domain Secondary Domain A secondary domain attributed through manual research. It is used as a foundational point for attributing additional infrastructure, including other domains and IP addresses, from various data sources. Slug Name: secondary_domain Manual Domain The domain attributed through manual research. Slug Name:: manual_domain Common Reason Codes Reasons for attribution. Customer Confirmation Assets explicitly provided by the customer (company-provided assets). DNS Mapping Shows associations such as IPs to domains or domains to IPs (e.g., 104.22.74.242/32 mapped to example.com). Manual Assignment Attributions based on manual research. Observed Associations Identifies shared usage of infrastructure or other overlaps, such as domains and IPs seen in DNS traffic. Redirects To/From Indicates redirections between domains or URLs, such as example.com redirecting to www.example.com. Unique Identifiers Links based on artifacts such as email addresses, phone numbers, logos, or physical addresses. Examples Domain Attribution Redirects: example.com redirects to www.example.com. DNS Mapping: 104.22.74.242/32 maps to example.com. IP Attribution IPv4 Mapping: 192.168.1.1 attributed to a company via DNS records. IPv6 Mapping: 2001:db8::ff00:42:8329 linked through observed associations. Other Identifiers Email Address: Associated with the organization through WHOIS records. Logo: Identified in metadata or website records. Phone Number: Attributed via public or private records. Evidence for Domains The Evidence field describes why a particular asset is suggested. Refer to the Summary Explanation and Step-by-Step Relationship Breakdown, which describes how the asset is linked to the organization and how to interpret the data. Summary Explanation The Evidence field contains a series of summarized relationships between assets. Each summary indicates a potential connection, such as redirects, DNS mappings, certificates, or web page associations. Examples: professional.bu.edu to cpe.bu.edu suggests a redirect observed between two assets. xmail.bu.edu to newmail.bu.edu indicates DNS mappings leading to an asset association. Step-by-Step Relationship Breakdown Each step provides crucial context that explains how the connection was inferred, allowing users to validate the suggested assets. The context includes: From The starting asset or domain in the relationship. Last Seen The most recent date this relationship was observed, ensuring users can evaluate its relevance. Record The observed data source for the relationship. Relation The type of connection or linkage. See relations. To The resulting asset or domain in the relationship. Example Breakdown Summary: cpe.bu.edu to professional.bu.edu Steps: From: cpe.bu.edu Relation: is redirected from To: professional.bu.edu Record: REDIRECT Last Seen: 2024-09-13 This means that professional.bu.edu was observed redirecting traffic to cpe.bu.edu as of September 13, 2024 based on a recorded redirect. How to Interpret and Use the Evidence Evaluate Summaries: Use the summaries to get a quick overview of how the asset is linked to the organization. Validate Steps: Dive into the step-by-step relationships to verify the data against internal records. Check Relevance: Pay attention to the Last Seen date to ensure the data is current. Assess Data Sources: Consider the Record Type (e.g., DNS or certificate) to understand the strength of the evidence. March 25, 2025: Published. Related articles Attribution Explainability – March 25, 2025 Infrastructure Data Sources Finding Behavior TLS/SSL Finding Remediation & Remediation Verification Verifying That a Finding Is Remediated Feedback 0 comments Please sign in to leave a comment.