391
Total Pages
285
Linux-Friendly Pages
106
Pages with Bias
27.1%
Bias Rate

Bias Trend Over Time

Pages with Bias Issues

488 issues found
Showing 176-200 of 488 flagged pages
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/sentinel-hunting-rules-creation.md ...n/articles/sentinel/sentinel-hunting-rules-creation.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
🔧 Windows Tools Powershell Heavy Windows First Missing Linux Example
Summary
The documentation page demonstrates Windows bias primarily in the section describing how to generate a GUID for the 'id' attribute. It explicitly references the PowerShell New-GUID cmdlet and links to its documentation, without mentioning or providing equivalent Linux/macOS methods (such as uuidgen or Python). No Linux tools or examples are provided, and the Windows/PowerShell method is presented first and exclusively.
Recommendations
  • Include Linux/macOS equivalents for generating GUIDs, such as the uuidgen command or Python's uuid module.
  • Present cross-platform options together, or list them in parallel, rather than Windows/PowerShell first.
  • Add example commands for Linux/macOS alongside the PowerShell example (e.g., 'uuidgen' or 'python -c "import uuid; print(uuid.uuid4())"').
  • Review other tooling or process references to ensure Linux parity and avoid Windows-first presentation.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/ueba-reference.md ...ure-docs/blob/main/articles/sentinel/ueba-reference.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation page exhibits a Windows bias in several areas. Windows-specific event sources (e.g., Windows Security Events, Windows Forwarded Events) are listed prominently, with no mention of equivalent Linux log sources (such as syslog, auditd, or Linux authentication logs). Device-related enrichments and examples focus on Windows (e.g., 'Device family: Windows', 'Operating system: Windows 10'), and there are no Linux device or OS examples. The documentation does not provide Linux-specific event categories, connectors, or sample values, nor does it mention Linux authentication or logon events. This creates an impression that UEBA is primarily oriented toward Windows environments, with limited guidance for Linux users.
Recommendations
  • Add Linux-specific data sources to the UEBA data sources table, such as syslog, auditd, or Linux authentication logs, and describe their connectors and analyzed event categories.
  • Include Linux device and OS examples in the DevicesInsights enrichment fields (e.g., 'Device family: Linux', 'Operating system: Ubuntu 22.04').
  • Provide sample enrichment values and scenarios for Linux users, such as SSH logins, sudo usage, or Linux group membership changes.
  • Clarify whether and how UEBA supports Linux endpoints, and if not, explicitly state limitations and roadmap.
  • Ensure parity in documentation by listing Linux event sources and tools alongside Windows, rather than focusing exclusively or first on Windows.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/anomalies-reference.md ...ocs/blob/main/articles/sentinel/anomalies-reference.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First Missing Linux Example 🔧 Windows Tools Powershell Heavy
Summary
The documentation page demonstrates a significant Windows bias. Most anomaly detection examples and machine learning models are based on Windows Security logs (e.g., Event IDs 4624 and 4625) and Windows-specific account activities. There is frequent mention of Windows tools and patterns (such as PowerShell and Windows Security logs), with no equivalent Linux or Unix log sources (e.g., syslog, auth.log, auditd) or examples. Linux-specific account creation, authentication, or brute force detection scenarios are missing, and there are no references to Linux command interpreters (e.g., Bash, sh) in code execution anomalies. The documentation assumes a Windows-centric environment for local account and authentication anomalies, and does not provide parity for Linux environments.
Recommendations
  • Add equivalent Linux/Unix anomaly detection examples, such as monitoring /var/log/auth.log, /var/log/secure, or auditd logs for account creation, deletion, and authentication anomalies.
  • Include Linux command and script interpreter sub-techniques (e.g., Bash, sh, Python) in code execution anomaly descriptions.
  • Provide details on how Sentinel can ingest and analyze Linux security logs for brute force, privilege escalation, and suspicious login anomalies.
  • Reference Linux-specific MITRE ATT&CK techniques and sub-techniques where applicable.
  • Ensure that examples and descriptions do not prioritize Windows tools and logs over Linux equivalents, and present both platforms equally where possible.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/best-practices-data.md ...ocs/blob/main/articles/sentinel/best-practices-data.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Powershell Heavy Missing Linux Example
Summary
The documentation demonstrates a moderate Windows bias. Windows-specific tools and patterns (e.g., Windows Event Forwarding, PowerShell, .NET) are mentioned frequently and sometimes before Linux equivalents. Several examples and solutions are Windows-centric, with Linux alternatives listed separately and sometimes less thoroughly. PowerShell is referenced for custom log collection, while Linux scripting alternatives are not. Some sections (e.g., endpoint solutions) mention only Windows methods, omitting Linux-focused approaches.
Recommendations
  • Ensure Linux examples are provided alongside Windows ones, especially for custom log collection (e.g., mention Bash, Python scripts for Linux where PowerShell is suggested for Windows).
  • List Linux and Windows solutions together, rather than in separate tables, to avoid implicit prioritization.
  • Include Linux-native tools (e.g., auditd, journald) where relevant, not just Syslog/Rsyslog.
  • When referencing agent installation issues, provide parity in troubleshooting steps for both platforms.
  • For endpoint solutions, mention Linux EDR/logging options (e.g., auditd, osquery) and how to integrate them.
  • Review examples and recommendations to ensure Linux is not an afterthought and receives equal coverage.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-microsoft-365-defender.md ...in/articles/sentinel/connect-microsoft-365-defender.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
🔧 Windows Tools Windows First Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by focusing exclusively on Microsoft Defender products and their integration with Microsoft Sentinel, which are inherently Windows-centric. All event tables and examples reference Windows-specific concepts (e.g., registry, DLL loading, Windows Defender Antivirus), and there is no mention of Linux endpoints, Linux-specific event types, or how to stream data from Linux systems. There are no examples or guidance for Linux-based security tools, nor is there any parity in instructions for Linux environments.
Recommendations
  • Include guidance and examples for integrating Linux endpoints with Microsoft Sentinel, such as using the Microsoft Sentinel Linux agent or syslog connector.
  • Add event table references and hunting queries relevant to Linux systems (e.g., syslog, auditd, SSH logins, Linux process events).
  • Provide explicit instructions for streaming data from Linux-based security solutions (e.g., Defender for Endpoint on Linux, or third-party Linux EDRs) into Sentinel.
  • Ensure that documentation sections referencing endpoint data or security events clarify applicability to both Windows and Linux, or provide parallel instructions/examples.
  • Mention Linux prerequisites and configuration steps where relevant, such as agent installation or permissions.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/billing-reduce-costs.md ...cs/blob/main/articles/sentinel/billing-reduce-costs.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates a Windows bias primarily in the 'Use data collection rules for your Windows Security Events' section, where only Windows Server and the Windows Security Events connector are discussed. There are no equivalent examples or guidance for collecting Linux security events, nor are Linux-specific connectors or data collection rules mentioned. The focus on Windows tools and connectors, without Linux parity, may lead Linux users to feel unsupported or unclear about cost optimization strategies for their environments.
Recommendations
  • Add a section detailing cost optimization for Linux security event collection, including relevant connectors (e.g., Syslog, CEF) and data collection rules for Linux agents.
  • Provide examples and guidance for configuring data collection rules for Linux servers, similar to the Windows example.
  • Mention Linux equivalents alongside Windows tools/connectors, ensuring both platforms are addressed in parallel.
  • Include references to documentation on optimizing costs for Linux data sources in Microsoft Sentinel.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-dns-ama.md ...re-docs/blob/main/articles/sentinel/connect-dns-ama.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First Missing Linux Example 🔧 Windows Tools
Summary
The documentation is heavily focused on Windows DNS servers, with all instructions, examples, and prerequisites exclusively referencing Windows Server environments. There are no examples, guidance, or mentions of Linux-based DNS servers or their log collection. Windows tools and patterns (such as enabling Windows DNS analytical logs, using Windows-specific event fields, and configuring Windows-specific connectors) are referenced throughout, with no Linux parity or alternatives provided.
Recommendations
  • Add equivalent instructions and examples for collecting and filtering DNS logs from Linux-based DNS servers (e.g., BIND, Unbound, dnsmasq).
  • Document how to use the AMA connector (or other Azure Monitor mechanisms) with Linux DNS servers, including prerequisites, configuration steps, and supported log formats.
  • Provide API and portal configuration examples for Linux DNS log sources, ensuring field mappings and normalization guidance are included.
  • Clarify in the introduction and prerequisites whether Linux DNS servers are supported, and if not, provide guidance or links to alternative solutions for Linux environments.
  • Include references to Linux tools and patterns (such as syslog, journald, or native DNS log files) and how they can be integrated into Microsoft Sentinel.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-aws.md .../azure-docs/blob/main/articles/sentinel/connect-aws.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Powershell Heavy Windows First Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by recommending PowerShell for the automatic setup and providing only PowerShell-based instructions and examples. There are no Linux shell (bash) or macOS terminal examples, nor any mention of how to run the setup scripts or AWS CLI commands on non-Windows platforms. The prerequisites and step-by-step instructions assume the user is on Windows, with no guidance for Linux users.
Recommendations
  • Provide equivalent bash shell instructions for Linux and macOS users, including how to run the setup script and configure the AWS CLI.
  • Clarify that the AWS CLI and setup scripts can be run on Linux/macOS, and provide platform-specific notes where necessary.
  • Offer alternative script examples (e.g., bash or Python) for users who do not use PowerShell.
  • Explicitly mention cross-platform compatibility in the prerequisites and setup steps.
  • Include screenshots or terminal output examples from Linux/macOS environments alongside Windows/PowerShell examples.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/cef-name-mapping.md ...e-docs/blob/main/articles/sentinel/cef-name-mapping.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First Windows Terms Windows Examples
Summary
The documentation exhibits mild Windows bias, primarily through the use of Windows-centric terminology (e.g., NTDomain, Windows domain), and by listing Windows examples before Linux equivalents in file path fields. Several field descriptions reference Windows-specific concepts, such as 'DeviceNtDomain', 'DestinationNTDomain', and provide Windows-style file paths before Linux ones. However, Linux/UNIX references are present, and the documentation does not exclusively focus on Windows or PowerShell.
Recommendations
  • Ensure Linux/UNIX examples are presented alongside or before Windows examples, especially in fields like filePath and oldFilePath.
  • Balance terminology by including Linux/UNIX domain concepts (e.g., LDAP, Kerberos realms) where NTDomain/Windows domain is mentioned.
  • Clarify that fields such as process names and file paths are platform-agnostic, and provide equal examples for both Windows and Linux/UNIX.
  • Add explicit notes or examples for Linux/UNIX environments in field descriptions where only Windows terms are currently used.
  • Review enrichment and custom field sections to ensure no implicit Windows-first assumptions are made.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/ci-cd-custom-content.md ...cs/blob/main/articles/sentinel/ci-cd-custom-content.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Powershell Heavy 🔧 Windows Tools Missing Linux Example Windows First
Summary
The documentation page demonstrates a bias toward Windows environments by referencing PowerShell deployment scripts as the primary method for customizing deployments, without mentioning Linux-native alternatives (such as Bash or shell scripts). There are no examples or guidance for Linux users, and Windows-centric tools and patterns (PowerShell, ARM/Bicep templates) are referenced exclusively or first. The lack of parity in examples and tooling may hinder Linux users from fully utilizing the feature.
Recommendations
  • Provide equivalent Linux/bash script examples for deployment customization alongside PowerShell examples.
  • Explicitly mention cross-platform compatibility for deployment scripts and workflows, and clarify any OS-specific requirements.
  • Reference or link to Linux-native tools (e.g., Azure CLI, Bash) where possible, and provide sample workflows using these tools.
  • Ensure that documentation sections mentioning PowerShell also include alternatives for Linux/macOS users.
  • Add notes or guidance for users running CI/CD pipelines on Linux agents, including any differences in setup or execution.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-azure-functions-template.md .../articles/sentinel/connect-azure-functions-template.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First Powershell Heavy 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by prioritizing PowerShell-based deployment instructions, referencing Windows-specific tools and patterns, and omitting explicit Linux or cross-platform CLI examples. PowerShell is presented as the default manual deployment method, while Python deployment requires Visual Studio Code, a tool more commonly associated with Windows environments. There is no mention of Bash, Azure CLI, or Linux-native workflows, nor are there instructions for deploying from Linux terminals or using Linux-friendly editors.
Recommendations
  • Add explicit instructions for deploying Azure Functions-based connectors using Bash or Azure CLI, suitable for Linux environments.
  • Include examples for manual deployment using Linux-native tools (e.g., terminal commands, editors like Vim or nano) alongside PowerShell.
  • Clarify that PowerShell Core is cross-platform, but also provide guidance for Linux users on installation and usage.
  • Offer parity in tooling by describing how to deploy using VS Code on Linux and Mac, and mention alternatives for those who do not use VS Code.
  • Ensure that references to workspace keys and other configuration steps include both Windows and Linux agent documentation.
  • Present deployment options in a neutral order (e.g., ARM template, CLI, PowerShell, Python) rather than prioritizing Windows-centric methods.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-custom-logs-ama.md ...blob/main/articles/sentinel/connect-custom-logs-ama.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First Powershell Heavy 🔧 Windows Tools Missing Linux Example
Summary
The documentation claims support for both Windows and Linux, but several sections exhibit Windows bias. Windows tools and patterns (such as PowerShell and Windows Event Log) are mentioned before Linux equivalents, and installation instructions often reference PowerShell before Azure CLI (which is more cross-platform). Linux-specific details are present but less emphasized, and there are no explicit Linux command-line examples for installing the Azure Monitor Agent or configuring the data connector. Screenshots and UI references are generic, but the step-by-step instructions and links tend to prioritize Windows approaches.
Recommendations
  • Provide explicit Linux command-line examples for installing and configuring the Azure Monitor Agent (e.g., using Azure CLI, shell commands).
  • Mention Linux tools (e.g., syslog, rsyslog, syslog-ng) alongside Windows Event Log in introductory sections, not only in log forwarder context.
  • Ensure that instructions for both platforms are presented in parallel or with equal prominence (e.g., tabs for Windows and Linux throughout setup steps).
  • Include troubleshooting and configuration notes specific to Linux environments, such as SELinux, file permissions, and service management.
  • Add screenshots or UI references for Linux VM selection and agent installation, not just generic VM lists.
  • Review and balance the order of presenting Windows and Linux instructions/examples so neither is consistently prioritized.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/data-connector-ui-definitions-reference.md ...es/sentinel/data-connector-ui-definitions-reference.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation demonstrates a mild Windows bias. Windows-related connector examples and references (such as the Windows DNS connector and InstallAgentOnWindows* link types) are mentioned before or more prominently than their Linux equivalents. The only detailed connector example provided is for Windows DNS, and there is no equivalent Linux connector example or explicit parity in sample links or walkthroughs. While Linux options (InstallAgentOnLinux*) are listed, they are not illustrated or referenced with the same prominence or detail as Windows options.
Recommendations
  • Add explicit Linux connector examples, such as a walkthrough or configuration JSON for a Linux data connector (e.g., Linux Syslog or Linux custom logs).
  • Reference Linux connectors (e.g., Linux Syslog, Linux custom logs) alongside Windows connectors in all example lists and sample links.
  • Ensure that InstallAgentOnLinux* link types are illustrated with screenshots and sample JSON, similar to the Windows examples.
  • Provide parity in sample queries and instruction steps for both Windows and Linux environments.
  • Where Windows connectors are referenced (such as the Windows DNS connector), provide a corresponding Linux connector reference (such as Linux Syslog or Linux DNS) in the same section.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/datalake/sentinel-lake-onboarding.md ...articles/sentinel/datalake/sentinel-lake-onboarding.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
🔧 Windows Tools Missing Linux Example Windows First
Summary
The documentation page demonstrates a Windows bias by exclusively referencing Microsoft Defender, Microsoft Sentinel, and Azure portals—all Windows-centric tools and interfaces. There are no examples or instructions for onboarding or interacting with the data lake and graph from Linux environments, nor is there mention of Linux command-line tools, APIs, or cross-platform CLI usage. The documentation assumes use of the Defender portal and other Microsoft GUIs, which are most commonly accessed from Windows. Additionally, the order and focus of the documentation prioritize Windows tools and workflows, with no parity for Linux or open-source alternatives.
Recommendations
  • Include onboarding instructions using Azure CLI and REST APIs, which are cross-platform and usable from Linux.
  • Provide examples for interacting with the data lake and graph from Linux environments, such as using curl, az CLI, or PowerShell Core (which runs on Linux).
  • Mention compatibility and access methods for non-Windows users, including browser support and remote access options.
  • Add troubleshooting and configuration steps relevant to Linux administrators, such as service principal authentication or scripting.
  • Explicitly state that the onboarding process can be performed from Linux and macOS, and link to relevant cross-platform documentation.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/create-analytics-rules.md .../blob/main/articles/sentinel/create-analytics-rules.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Powershell Heavy 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates a bias toward Windows environments by referencing PowerShell and Windows-centric automation patterns (such as ARM templates and PowerShell modules) for rule management and automation. There are no Linux or cross-platform CLI examples, and Linux-native tools or scripting methods are not mentioned. The only automation examples provided are via PowerShell or REST API, both of which are more familiar to Windows users. No Bash, Azure CLI, or Linux scripting guidance is offered.
Recommendations
  • Provide equivalent examples using Azure CLI for rule management and automation, alongside PowerShell.
  • Explicitly mention that REST API and ARM templates can be used from any OS, and provide Bash/cURL examples for Linux users.
  • Include references or links to cross-platform tools and scripting approaches (e.g., Bash, Python SDK) for managing Sentinel analytics rules.
  • Clarify that PowerShell is available on Linux, but also offer native Linux shell examples for parity.
  • Ensure that automation and export/import scenarios demonstrate both Windows and Linux workflows.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/create-analytics-rule-from-template.md ...ticles/sentinel/create-analytics-rule-from-template.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Powershell Heavy 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates a bias towards Windows environments by exclusively mentioning PowerShell as the scripting/automation method for pushing rules to Microsoft Sentinel, without referencing Linux-native tools or CLI alternatives. There are no examples or instructions for Linux users, such as using Bash, Azure CLI, or REST API via curl. The only automation tool mentioned is PowerShell, which is traditionally associated with Windows, and there is no guidance for Linux users on how to perform equivalent tasks.
Recommendations
  • Include examples for Linux users, such as using Azure CLI or curl for REST API calls to push rules.
  • Explicitly mention cross-platform options for automation, clarifying that PowerShell Core is available on Linux and macOS, or provide Bash script equivalents.
  • Add a section or note on how to export and enable rules using Linux-native tools, ensuring parity for non-Windows environments.
  • Where PowerShell is referenced, provide alternative commands for Linux users, or link to documentation covering those alternatives.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/datalake/auditing-lake-activities.md ...articles/sentinel/datalake/auditing-lake-activities.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Powershell Heavy 🔧 Windows Tools Missing Linux Example Windows First
Summary
The documentation page demonstrates a Windows bias by providing only PowerShell examples for searching the audit log, referencing Windows-centric tools and roles (Exchange Online, Office 365), and omitting equivalent Linux or cross-platform command-line instructions. The workflow assumes use of Microsoft portals and PowerShell, which are native to Windows environments, without mentioning or prioritizing Linux-compatible alternatives.
Recommendations
  • Include CLI examples using cross-platform tools such as Azure CLI, Microsoft Graph API via curl, or Python scripts that can run on Linux and macOS.
  • Explicitly mention how Linux users can access audit logs, including any REST API endpoints or SDKs.
  • Provide parity in step-by-step instructions for searching and exporting audit logs using Linux-compatible methods.
  • Reference cross-platform authentication and session management approaches (e.g., OAuth2 tokens for API access) instead of only PowerShell/Windows credential management.
  • Add notes or sections highlighting platform-agnostic best practices for SOC analysts working outside Windows environments.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/dns-ama-fields.md ...ure-docs/blob/main/articles/sentinel/dns-ama-fields.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First Missing Linux Example 🔧 Windows Tools
Summary
The documentation is heavily focused on Windows DNS servers and the Windows DNS Events via AMA connector. All examples, field mappings, and instructions reference Windows-specific tools and patterns, with no mention of Linux equivalents or how to handle DNS logs from Linux servers. The normalization schema and filtering guidance are tailored exclusively to Windows DNS event fields, and there is no guidance for Linux-based DNS servers or connectors.
Recommendations
  • Add equivalent instructions and examples for collecting and normalizing DNS logs from Linux-based DNS servers (e.g., BIND, Unbound, dnsmasq).
  • Document how to use the AMA connector (or other connectors) with Linux DNS servers, including setup, supported fields, and normalization schema.
  • Provide a comparative table showing both Windows and Linux DNS field mappings to the normalized schema.
  • Include cross-platform guidance for filtering and monitoring DNS events, ensuring parity in documentation for both Windows and Linux environments.
  • Mention and link to any Linux-specific connectors or extensions available for Microsoft Sentinel.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/entities-reference.md ...docs/blob/main/articles/sentinel/entities-reference.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Powershell Heavy Missing Linux Example
Summary
The documentation exhibits a Windows bias in several ways: Windows-specific concepts (NTDomain, NetBiosName, SID, RegistryKey/Hive, WindowsSecurityZoneType) are consistently mentioned and defined, often before or instead of Linux equivalents. Many identifiers and schema fields reference Windows-centric technologies (Active Directory, NTFS, Windows Registry, Windows Security Zones) with no mention of Linux alternatives (e.g., Linux user/group IDs, /etc/passwd, Linux file attributes, Linux process details). The OSFamily enum lists Linux, but no Linux-specific fields or examples are provided. There are no Linux-specific identifier patterns, and examples are almost exclusively Windows-oriented.
Recommendations
  • Add Linux-specific identifiers and examples for Account, Host, File, and Process entities (e.g., UID/GID, /etc/passwd, /etc/group, Linux file paths, Linux process attributes).
  • Include Linux registry/file system equivalents or clarify how Linux systems are represented (e.g., mention that RegistryKey/Hive is Windows-only, and describe Linux configuration file mapping).
  • Provide Linux-centric examples alongside Windows ones, such as Linux domain names, hostnames, and process details.
  • Clarify in each schema field which identifiers are Windows-specific and which are applicable to Linux, and add Linux-specific documentation where possible.
  • Expand the OSFamily and OSVersion sections to provide Linux-specific details and examples, such as common distributions and versioning schemes.
  • Where Windows tools or concepts are referenced (e.g., NTFS, Active Directory, WindowsSecurityZoneType), provide Linux alternatives or note their absence.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/fusion-scenario-reference.md ...ob/main/articles/sentinel/fusion-scenario-reference.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Powershell Heavy 🔧 Windows Tools Windows First Missing Linux Example
Summary
The documentation page demonstrates a Windows bias in several ways: it frequently references Windows-specific tools and technologies (such as PowerShell and WMI), and focuses on Microsoft Defender for Endpoint, which is primarily a Windows-centric solution. Examples of suspicious activity are almost exclusively described in terms of Windows tools (PowerShell, WMI) and Microsoft cloud services, with no mention of Linux equivalents (such as Bash, SSH, systemd, or Linux-native credential theft tools). There are no examples or scenarios that reference Linux-specific attack patterns, tools, or detection methods, and the documentation does not provide parity for Linux environments in its threat descriptions or incident scenarios.
Recommendations
  • Include Linux-specific scenarios, such as suspicious Bash or SSH activity, or use of Linux-native credential theft tools (e.g., LaZagne, John the Ripper).
  • Add examples of attacks leveraging Linux system utilities (e.g., cron jobs, systemd services, sudo misuse) and describe how these would be detected by Sentinel Fusion.
  • Reference Microsoft Defender for Endpoint's Linux capabilities and clarify how incidents are detected on Linux hosts.
  • Provide parity in incident descriptions by including Linux and macOS attack vectors and detection methods alongside Windows examples.
  • Expand the scope of suspicious command execution scenarios to include Linux shells and scripting environments (e.g., suspicious Bash scripts, Python execution).
  • Mention Linux-specific MITRE ATT&CK techniques and how Sentinel Fusion correlates signals from Linux endpoints.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/fusion.md ...tDocs/azure-docs/blob/main/articles/sentinel/fusion.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
🔧 Windows Tools Powershell Heavy Windows First Missing Linux Example
Summary
The documentation page exhibits a Windows bias by referencing Windows-specific tools (such as PowerShell, Windows Error and Warning Events, and Windows malware/ransomware examples) and providing examples that focus on Windows environments. There are multiple mentions of PowerShell as an attack vector, and Windows alerts are used in ransomware detection scenarios. There is no mention of Linux-specific tools, attack patterns, or equivalent examples for Linux environments, nor are Linux logs or commands referenced.
Recommendations
  • Include Linux-specific attack scenarios and detection examples, such as suspicious Bash commands, Linux malware, or SSH brute-force attempts.
  • Reference Linux system logs (e.g., /var/log/auth.log, /var/log/syslog) in detection tables and examples alongside Windows Event logs.
  • Provide parity in examples by showing how multistage attacks might be detected on Linux endpoints (e.g., suspicious sudo activity, cron job modifications, or use of Linux-native credential theft tools).
  • Mention Linux data connectors and ensure that analytics rules and entity mapping examples include Linux signals.
  • Balance references to PowerShell with equivalent Linux shell (Bash, sh) or scripting activity in attack detection scenarios.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/includes/deprecated-connectors.md ...in/articles/sentinel/includes/deprecated-connectors.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Powershell Heavy Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by frequently referencing Windows-specific agents, tools, and patterns before or instead of Linux equivalents. Examples and instructions for Windows (such as the Windows agent and PowerShell) are provided in detail, while Linux instructions are minimal or only mentioned in passing. Windows connectors and prerequisites are described with more context, and links to installation guides default to Windows/PowerShell tabs. Linux connectors, such as Syslog, receive less explanation and lack parity in example depth.
Recommendations
  • Provide Linux-specific examples and instructions alongside Windows ones for each connector, especially for installation and configuration.
  • Ensure documentation links and tabs default to cross-platform or include both Windows and Linux options equally.
  • Describe Linux agent prerequisites and setup steps in detail, matching the depth provided for Windows.
  • Include parity in troubleshooting, usage scenarios, and advanced configuration for Linux connectors.
  • Avoid referencing Windows tools (e.g., PowerShell) exclusively or before Linux equivalents; mention Bash/CLI or Linux-native tools where appropriate.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/microsoft-365-defender-sentinel-integration.md ...entinel/microsoft-365-defender-sentinel-integration.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First Missing Linux Example 🔧 Windows Tools
Summary
The documentation page demonstrates a Windows bias by exclusively referencing Microsoft Defender XDR and Microsoft Sentinel, both of which are Microsoft-centric and typically associated with Windows environments. There are no examples or mentions of Linux-specific integration, tools, or patterns. The documentation assumes usage of Microsoft portals and services, which are primarily Windows-based, and does not provide parity for Linux users or environments. No PowerShell examples are present, but the overall approach and terminology are Windows-focused, with no mention of Linux equivalents or cross-platform considerations.
Recommendations
  • Include explicit instructions or examples for integrating Microsoft Sentinel and Defender XDR in Linux environments, such as using Linux agents or connectors.
  • Mention and provide guidance for using Linux-based tools (e.g., syslog, auditd, or other SIEM agents) to forward data to Microsoft Sentinel.
  • Add parity in documentation by referencing cross-platform compatibility, including any limitations or special considerations for Linux systems.
  • Provide examples of incident management and advanced hunting using Linux endpoints, including how alerts from Linux systems are handled and correlated.
  • Clarify whether all features (such as custom detections, advanced hunting, and incident synchronization) are available and supported for Linux endpoints.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/includes/connector-details.md ...b/main/articles/sentinel/includes/connector-details.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation page for Microsoft Sentinel data connectors demonstrates a Windows bias in several ways. Many connectors, especially those for Microsoft Exchange, Active Directory, IIS, and Windows Firewall, explicitly mention streaming logs from 'Windows machines' using the 'Windows agent' or Azure Monitor Agent, with no equivalent Linux instructions or examples. Windows-specific tools and terminology (e.g., Windows Event logs, Windows DNS, Windows Firewall) are referenced without mention of Linux alternatives. In some cases, connectors for generic log types (e.g., custom logs, syslog) do mention Linux, but Windows is often listed first or exclusively, and Linux-specific patterns or examples are missing or less detailed.
Recommendations
  • For connectors that currently mention only Windows agents or Windows Event logs, add equivalent instructions and examples for Linux systems, including supported Linux distributions and agent installation steps.
  • Where Windows tools (e.g., Windows Firewall, Windows DNS) are referenced, provide parity by mentioning Linux equivalents (e.g., iptables, nftables, BIND, Unbound) and how to collect their logs.
  • Ensure that generic log collection connectors (e.g., custom logs, syslog) provide balanced examples for both Windows and Linux, including troubleshooting tips for each platform.
  • Review the ordering and prominence of examples and instructions to avoid listing Windows first by default; alternate or group by OS where appropriate.
  • Where prerequisites or agent installation instructions are given, provide explicit Linux instructions alongside Windows, including command-line examples for Linux.
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/migration-ingestion-tool.md ...lob/main/articles/sentinel/migration-ingestion-tool.md
High Priority View Details →
Scanned: 2026-01-08 00:53
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Powershell Heavy Windows First Missing Linux Example 🔧 Windows Tools
Summary
The documentation page demonstrates a Windows bias in several ways: PowerShell scripts are presented as the primary method for custom log ingestion and API usage, with no Linux shell or cross-platform alternatives shown. The SIEM data migration accelerator deploys a Windows VM and downloads Windows-centric tools, with no mention of Linux-based automation or VMs. Examples and instructions often reference Windows tools or patterns first, and Linux alternatives are either omitted or mentioned only in passing (e.g., Logstash and AzCopy are noted as cross-platform, but no Linux-specific usage is described).
Recommendations
  • Provide equivalent Linux shell (bash) examples alongside PowerShell scripts for custom log ingestion and API usage.
  • Explicitly describe how to use ingestion tools (e.g., AzCopy, Logstash) on Linux, including installation and command-line usage.
  • Offer guidance for deploying the SIEM data migration accelerator on Linux VMs, or provide a Linux-compatible version.
  • List cross-platform tools and usage patterns before or alongside Windows-specific ones, ensuring parity in documentation structure.
  • Include references to Linux-native automation (e.g., cron jobs, shell scripts) for data migration tasks.
  • Clarify which tools are cross-platform and provide links to Linux/macOS documentation where available.