Sentinel
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 226-250 of 488 flagged pages
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/use-matching-analytics-to-detect-threats.md
...s/sentinel/use-matching-analytics-to-detect-threats.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by listing Windows-specific tools (Windows DNS, Windows Firewall) and connectors before or more prominently than Linux equivalents. Examples and solution links focus on Windows components, with no explicit Linux or cross-platform command-line examples (e.g., bash, Linux DNS, Linux firewall). Syslog is mentioned, but not elaborated with Linux-centric instructions or examples. There is a lack of parity in showing how Linux users would configure or triage incidents, and Windows terminology and tools are foregrounded throughout.
Recommendations
- Add explicit Linux-focused examples, such as configuring Syslog or Linux DNS connectors, and show how to ingest Linux firewall logs.
- Include screenshots and walkthroughs from Linux environments (e.g., Ubuntu, CentOS) to balance the visual representation.
- Mention and link to Linux-native tools (e.g., iptables, firewalld, BIND for DNS) and describe how their logs can be integrated.
- Ensure that connector tables and solution lists include Linux equivalents and are not Windows-first in ordering.
- Provide sample queries and triage steps using Linux-generated data to demonstrate parity.
Create Pull Request
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/skill-up-resources.md
...docs/blob/main/articles/sentinel/skill-up-resources.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Missing Linux Example
Summary
The documentation page for Microsoft Sentinel skill-up training demonstrates a moderate Windows bias. Windows and Microsoft-centric tools, services, and terminology are consistently mentioned first or exclusively (e.g., 'Connect to Azure, Windows, Microsoft, and Amazon services'), and PowerShell is highlighted as an alternative to API usage. Linux-specific tools, examples, and patterns are rarely mentioned, and when present (e.g., Sysmon for Linux, Heartbeat table for Linux and Windows), they appear as add-ons or afterthoughts rather than first-class citizens. There are few, if any, explicit Linux command-line or integration examples, and generic cross-platform patterns are not emphasized.
Recommendations
- Provide Linux-specific examples and walkthroughs alongside Windows ones, especially for data collection, agent health monitoring, and automation.
- Mention Linux tools and patterns (e.g., Bash, systemd, cron, Linux syslog, auditd) explicitly and equally in relevant sections.
- Include Linux-first or cross-platform examples in API usage, automation, and integration modules, not just PowerShell.
- Ensure documentation for agent health, log management, and data connectors highlights Linux support and configuration steps.
- Where Windows is referenced first (e.g., 'Connect to Azure, Windows, Microsoft, and Amazon services'), rephrase to be platform-neutral or alternate order.
- Add Linux-focused troubleshooting, best practices, and operational guidance for SOC teams using Linux infrastructure.
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 →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation page shows a Windows bias primarily by referencing Windows agents and tools first (or exclusively) in several connector descriptions, especially for Microsoft Exchange and Security Events. Windows-specific terminology (e.g., 'Windows agent', 'Windows machines') is used without equivalent Linux context in multiple places. In contrast, Linux (Syslog) is mentioned only once, and there are no Linux-specific setup or troubleshooting examples for connectors that could apply to both platforms. There is also a lack of parity in prerequisites and instructions for Linux environments.
Recommendations
- For connectors that mention 'Windows agent' or 'Windows machines', add equivalent references and instructions for Linux agents/machines where applicable.
- Provide Linux-specific setup, configuration, and troubleshooting examples alongside Windows examples for all relevant connectors.
- Where prerequisites or permissions are listed for Windows (e.g., PowerShell, Windows agent), include corresponding Linux commands, tools, or agent instructions.
- Avoid using Windows-centric language (e.g., 'Windows agent') as the default; instead, use cross-platform terms or explicitly mention both Windows and Linux.
- Ensure that all connectors which can be used on Linux have clear documentation for Linux environments, including links to Linux agent installation and configuration guides.
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 →
Detected Bias Types
Powershell Heavy
Windows Tools
Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by referencing PowerShell deployment scripts as the mechanism for custom deployment options, without mentioning or providing alternatives for Linux environments (such as Bash or cross-platform scripting). There are no Linux-specific examples or guidance, and the only scripting tool referenced is PowerShell, which is traditionally associated with Windows. No mention is made of running these workflows or scripts in a Linux environment, nor are any Linux-native tools or shell examples provided.
Recommendations
- Explicitly state whether the PowerShell deployment script is cross-platform (e.g., works with PowerShell Core on Linux/macOS) or provide equivalent Bash scripts/examples for Linux users.
- Include Linux-specific instructions or examples for customizing deployments, such as using Bash or other common Linux automation tools.
- Clarify any platform requirements or limitations for running deployment scripts, and provide guidance for Linux users where necessary.
- Where possible, use neutral, cross-platform terminology (e.g., 'script' instead of 'PowerShell script') and provide both Windows and Linux command-line examples.
- Add a section or note addressing Linux/macOS users, outlining any differences or additional steps required.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/microsoft-purview-record-types-activities.md
.../sentinel/microsoft-purview-record-types-activities.md
High Priority
View Details →
Detected Bias Types
Powershell Heavy
Missing Linux Example
Windows Tools
Summary
The documentation references the use of a PowerShell cmdlet (Unlock-SPOSensitivityLabelEncryptedFile) as the only example of a command-line tool for managing sensitivity labels, with no mention of Linux or cross-platform alternatives. No Linux-specific tools, commands, or usage patterns are provided, and the documentation implicitly assumes a Windows/PowerShell environment for administrative tasks.
Recommendations
- Include equivalent command-line examples for Linux environments, such as using Microsoft Graph API via curl or other cross-platform tools.
- Explicitly state whether the administrative tasks (e.g., unlocking sensitivity label encrypted files) can be performed on Linux, and provide guidance or alternatives if available.
- Where PowerShell cmdlets are mentioned, add notes or links to REST API documentation or CLI tools that can be used on non-Windows platforms.
- Review all examples and references to ensure Linux and macOS users are not excluded from administrative guidance.
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 →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Summary
The documentation demonstrates a mild Windows bias. In the 'InstallAgent' section, Windows-related link types ('InstallAgentOnWindowsVirtualMachine', 'InstallAgentOnWindowsNonAzure') are listed before their Linux equivalents, and the only detailed example link provided is to a Windows DNS connector. There is also a lack of Linux-specific examples or references, and the only connector example referenced is for Windows. No PowerShell or Windows command-line examples are present, but the overall pattern and example selection favor Windows environments.
Recommendations
- Add Linux-focused examples and references, such as linking to a Linux data connector template (e.g., Syslog or Linux agent).
- When listing options (such as link types), alternate or randomize the order, or list Linux and Windows together to avoid 'Windows first' ordering.
- Provide at least one detailed example or screenshot for a Linux-based connector alongside the Windows DNS connector.
- Explicitly mention parity and support for both Windows and Linux environments in the introduction and relevant sections.
- If referencing external documentation or templates, ensure Linux connectors are equally represented.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/automation/playbook-recommendations.md
...ticles/sentinel/automation/playbook-recommendations.md
High Priority
View Details →
Detected Bias Types
Windows Tools
Missing Linux Example
Windows First
Summary
The documentation page demonstrates a bias toward Windows and Microsoft-centric tools and workflows. All playbook examples and templates focus on Microsoft products (e.g., Microsoft Teams, Outlook, Defender for Endpoint, Entra ID, Azure Firewall) with no mention of Linux-native tools, open-source alternatives, or Linux-specific workflows. There are no examples of integrating with Linux firewalls (like iptables or nftables), Linux user management, or Linux-based notification/email systems. The documentation assumes a Microsoft ecosystem and does not provide parity for Linux environments.
Recommendations
- Include examples of playbooks that interact with Linux-based firewalls (e.g., iptables, nftables) for blocking IP addresses.
- Provide templates or guidance for disabling Linux user accounts (e.g., using usermod or passwd commands) as part of incident response.
- Add notification examples using Linux-native tools (e.g., sendmail, mailx, or integration with open-source chat platforms like Mattermost or Rocket.Chat).
- Mention and demonstrate integration with open-source ticketing systems (e.g., OTRS, RT) alongside ServiceNow.
- Balance the order of examples so that Linux/open-source options are presented alongside or before Microsoft/Windows-specific tools where applicable.
- Explicitly state that playbooks can be extended to Linux environments and provide links or references to relevant connectors or scripts.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/ama-migrate.md
.../azure-docs/blob/main/articles/sentinel/ama-migrate.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation page demonstrates a Windows bias by focusing migration steps and examples on Windows systems, such as referencing the 'Windows Security Events' solution, 'Windows Security Event connector', and 'Windows agent-based connections' without providing equivalent Linux examples or guidance. Linux-specific features are only briefly mentioned (e.g., Linux multi-homing) and not elaborated upon. There are no step-by-step instructions or connectors highlighted for Linux systems, and the documentation does not mention Linux tools or patterns for migration.
Recommendations
- Add parallel Linux-focused migration steps, including references to Linux-specific connectors and solutions (e.g., 'Linux Security Events via AMA').
- Provide examples and screenshots for Linux agent installation, configuration, and validation, similar to the Windows examples.
- Include guidance on uninstalling the legacy agent from Linux systems, referencing relevant commands and documentation.
- Mention Linux tools and patterns (such as syslog, auditd, or Linux-specific data connectors) alongside Windows tools.
- Ensure that Linux and Windows instructions are presented with equal prominence, or provide a clear structure separating guidance for each platform.
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 →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation page demonstrates a Windows bias primarily in the 'Use data collection rules for your Windows Security Events' section, which exclusively discusses Windows Server and the Windows Security Events connector. There are no equivalent examples or guidance for collecting security events from Linux systems, nor are Linux-specific connectors or data collection rules mentioned. The focus on Windows tools and lack of Linux parity may leave Linux administrators without clear guidance for cost optimization.
Recommendations
- Add a section or examples for collecting and optimizing security event ingestion from Linux servers, including relevant connectors (e.g., Syslog, CEF) and data collection rules.
- Mention Linux data sources and how to use data collection rules or agents (such as the Azure Monitor Agent on Linux) to filter and optimize log ingestion.
- Ensure that references to connectors and data collection are platform-neutral where possible, or provide parallel guidance for both Windows and Linux environments.
- Review the documentation for other areas where only Windows-centric tools or workflows are described, and add Linux equivalents or cross-platform instructions.
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 →
Detected Bias Types
Powershell Heavy
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation demonstrates a Windows bias by prioritizing PowerShell and Windows-centric deployment methods. The manual deployment section provides detailed PowerShell instructions before Python, and the PowerShell example assumes use of the Azure portal and PowerShell Core, both of which are more familiar to Windows users. There is no mention of Linux shell (e.g., Bash) or CLI-based deployment options, and no explicit Linux or cross-platform examples are provided. The Python deployment requires Visual Studio Code, which, while cross-platform, is not the default editor on Linux systems. There are no examples using Azure CLI, Bash, or Linux-native tools.
Recommendations
- Add explicit Linux/Bash shell deployment instructions, including examples using Azure CLI and Bash scripts.
- Present deployment options in a neutral order (e.g., ARM template, Python, PowerShell) or clarify that all are equally supported.
- Include notes or examples for Linux users, such as using the Azure CLI in Bash to deploy and configure Function Apps.
- Highlight cross-platform tooling (e.g., Azure CLI, VS Code) and provide alternatives for users who may not use PowerShell or Windows.
- Ensure that references to workspace keys and configuration steps are not Windows-specific (e.g., avoid linking only to Windows agent documentation).
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 →
Detected Bias Types
Windows First
Windows Terms
Windows Examples
Summary
The documentation shows a mild Windows bias. Windows-specific terms (such as 'NTDomain', 'DeviceNtDomain', 'DestinationNTDomain', 'SourceNTDomain') are present as field names and descriptions. In several field descriptions, Windows is mentioned explicitly (e.g., 'The Windows domain of the device address'). File path examples consistently list the Windows path first (e.g., 'C:\ProgramFiles\WindowsNT\Accessories\wordpad.exe' before '/usr/bin/zip'). There are no PowerShell-specific examples or exclusive use of Windows tools, but Windows terminology and examples are more prominent or appear before Linux equivalents.
Recommendations
- Alternate the order of Windows and Linux/Unix examples in file paths, or list Linux examples first in some cases.
- Where possible, generalize field descriptions to avoid Windows-centric language (e.g., say 'domain name' instead of 'Windows domain name'), or provide both Windows and Linux/Unix context.
- Add clarifying notes for fields that are Windows-specific, and provide equivalent Linux/Unix fields or note when not applicable.
- Ensure that examples and terminology are balanced between Windows and Linux/Unix systems throughout the documentation.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-logstash-data-connection-rules.md
...les/sentinel/connect-logstash-data-connection-rules.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation demonstrates a mild Windows bias: file path examples consistently show Windows paths (e.g., c:\temp) before Linux equivalents (e.g., /tmp), and in some cases, only the Windows path is shown in code snippets. In configuration examples, the sample_file_path is set to a Windows path by default. There are no PowerShell-specific commands or Windows-only tools, but the ordering and emphasis of examples favor Windows. Linux-specific troubleshooting is only briefly mentioned in the Docker/Ubuntu section, and Linux file path conventions are not given equal prominence throughout.
Recommendations
- Present Linux and Windows file path examples side-by-side or alternate their order to avoid always listing Windows first.
- In code snippets, use placeholder paths (e.g., <path-to-temp-dir>) and provide both Windows and Linux examples in comments.
- Ensure that all instructions and examples are equally applicable to both Linux and Windows environments.
- Add explicit Linux shell command examples where relevant (e.g., for file creation, permissions, or service management).
- Highlight any OS-specific considerations (such as file permissions or service management) in dedicated callout sections.
- Review all code and configuration blocks to ensure Linux parity and avoid defaulting to Windows-centric paths or conventions.
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 →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation is heavily focused on Windows environments, specifically Windows DNS servers, and does not mention or provide guidance for Linux-based DNS servers or cross-platform scenarios. All examples, prerequisites, and instructions are tailored exclusively for Windows Server, with no Linux equivalents or alternatives discussed. The tools and terminology (e.g., Windows DNS Events, Windows Server DNS, Windows event logs) are Windows-specific, and there is no indication of parity or support for Linux DNS logging or ingestion.
Recommendations
- Add a section clarifying whether Linux-based DNS servers (such as BIND or dnsmasq) are supported, and if not, explicitly state this limitation.
- If Linux DNS log ingestion is possible, provide equivalent instructions, prerequisites, and examples for popular Linux DNS servers.
- Include Linux-specific tools, log file paths, and configuration steps where relevant.
- Use more inclusive language in titles and throughout the documentation (e.g., 'Stream and filter DNS logs with the AMA connector' instead of 'Windows DNS logs').
- If the connector is Windows-only, suggest alternative solutions or connectors for Linux DNS log ingestion, or link to relevant documentation.
- Ensure that any API examples or schemas are annotated to indicate whether they are Windows-specific or cross-platform.
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 →
Detected Bias Types
Windows First
Powershell Heavy
Windows Tools
Missing Linux Example
Summary
The documentation page exhibits a Windows bias primarily by referencing Windows-centric tools and automation methods (notably PowerShell), mentioning them before or instead of cross-platform or Linux-native alternatives. The only automation scripting example given is PowerShell, and there is no mention of Linux command-line tools or scripting options. The documentation also references the Azure and Defender portals, which are web-based and cross-platform, but when it comes to automation and exporting, only Windows/PowerShell options are highlighted, with no Linux or CLI parity.
Recommendations
- Include examples of automating rule management using Azure CLI (az) or Bash scripts, not just PowerShell.
- Explicitly mention that API and PowerShell automation can be performed from Linux/macOS as well, and provide cross-platform instructions.
- Reference and provide examples for using REST API via curl or other Linux-native tools for rule management.
- Where PowerShell is mentioned, also provide equivalent commands or scripts using Azure CLI or generic REST API calls.
- Clarify that exporting/importing ARM templates can be done from any OS, and provide sample commands for Linux environments.
- If possible, add a section or callout for Linux users, summarizing the parity and any differences in workflow.
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 →
Detected Bias Types
Powershell Heavy
Windows Tools
Windows First
Summary
The documentation page demonstrates a Windows bias by referencing Windows-specific tools and technologies (such as PowerShell, Windows events, and Windows malware families) without providing equivalent Linux examples or mentioning Linux-specific attack patterns. PowerShell is highlighted in multiple detection scenarios, and Windows alerts are used as illustrative examples. There is no mention of Linux-based threats, tools, or detection patterns, nor are Linux command-line or log sources referenced.
Recommendations
- Include detection scenarios and examples that reference Linux-based attacks, such as suspicious Bash or shell activity, Linux-specific malware, or Linux log sources (e.g., syslog, auditd).
- Provide examples of multistage attacks that involve Linux endpoints or mixed-OS environments.
- Balance the use of Windows-specific tools (like PowerShell and Windows Event Logs) with Linux equivalents (such as Bash, systemd, or Linux audit logs).
- Add references to Linux security solutions (e.g., Microsoft Defender for Endpoint on Linux, or integration with Linux EDR tools) where appropriate.
- Ensure that tables and illustrative examples include both Windows and Linux alerts/incidents to demonstrate parity.
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 →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by prioritizing Windows-based data connectors and tooling. Windows-specific agents and event types (e.g., Windows agent, SecurityEvent, W3CIISLog) are mentioned explicitly, while Linux equivalents are only referenced in a single entry (Syslog via Legacy Agent) and not in parity with the Windows coverage. The documentation for Microsoft Exchange and Security Events focuses solely on Windows machines and agents, with no comparable Linux event collection examples or guidance. Additionally, links and instructions for agent installation reference Windows-centric tabs and tools, and Linux agent scenarios are not equally detailed.
Recommendations
- Provide Linux-based examples and instructions alongside Windows ones for all relevant connectors, especially for event and log collection.
- Ensure that agent installation documentation references both Windows and Linux agents equally, with clear parity in detail and guidance.
- Include Linux event types (such as auditd, auth.log, etc.) and their mapping to Log Analytics tables where applicable.
- Where Windows-specific tools or logs are mentioned (e.g., W3CIISLog, SecurityEvent), add Linux equivalents (e.g., Apache/Nginx logs, Syslog, audit logs) and describe their ingestion.
- Review all prerequisite and setup sections to ensure Linux users are not omitted and have clear, actionable steps.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/sentinel-summary-rules-creation.md
...n/articles/sentinel/sentinel-summary-rules-creation.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by exclusively referencing the PowerShell New-GUID cmdlet as an example for generating GUIDs, without mentioning Linux or cross-platform alternatives. No Linux or macOS command-line tools are suggested for this task, and the only explicit tooling example is Windows-specific. This may hinder Linux or cross-platform users from following the guidance seamlessly.
Recommendations
- When suggesting how to generate a GUID, include cross-platform and Linux-native options, such as 'uuidgen' (available on most Linux/macOS systems) or Python's uuid module.
- Rephrase the sentence to mention multiple platforms, e.g., 'Generate it by using any development tool, an online generator, the PowerShell New-GUID cmdlet (Windows), or the uuidgen command (Linux/macOS)'.
- Wherever command-line examples are given, provide both Windows (PowerShell/CMD) and Linux/macOS (bash/sh) equivalents.
- Audit the documentation for other places where Windows tools or patterns are referenced first or exclusively, and ensure Linux parity in examples and tool recommendations.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/sap/deploy-sap-btp-solution.md
.../main/articles/sentinel/sap/deploy-sap-btp-solution.md
High Priority
View Details →
Detected Bias Types
Powershell Heavy
Missing Linux Example
Windows Tools
Summary
The documentation provides a PowerShell script for automating the rotation of BTP client secrets, relying on Azure PowerShell modules and cmdlets. No equivalent Bash, Azure CLI, or cross-platform scripting example is provided. The automation guidance is thus Windows-centric, and Linux users are not given parity in automation instructions.
Recommendations
- Provide equivalent automation examples using Azure CLI and Bash scripts for Linux/macOS environments.
- Explicitly mention that the PowerShell script is intended for Windows users, and link to or include Linux-compatible alternatives.
- Where possible, use cross-platform tools (e.g., Azure CLI) in examples, or offer both PowerShell and Bash/CLI versions side by side.
- Review other automation or scripting sections for similar bias and ensure Linux users have clear, actionable guidance.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/migration-export-ingest.md
...blob/main/articles/sentinel/migration-export-ingest.md
High Priority
View Details →
Detected Bias Types
Windows Tools
Missing Linux Example
Windows First
Summary
The documentation demonstrates Windows bias by recommending and documenting tools (such as LightIngest) that are Windows-only, without providing Linux alternatives or guidance for non-Windows environments. There are no Linux-specific examples or instructions, and the documentation does not clarify cross-platform compatibility for other tools (such as AzCopy or the Custom Log Ingestion script). The order of presentation and lack of parity in tooling further reinforce a Windows-centric approach.
Recommendations
- Provide explicit instructions and examples for Linux environments, including installation and usage of ingestion tools on Linux.
- If a tool is Windows-only (e.g., LightIngest), recommend and document alternative ingestion methods for Linux (such as using Azure Data Explorer's ingestion REST API, Python SDK, or other cross-platform tools).
- Clarify the cross-platform compatibility of tools like AzCopy and the Custom Log Ingestion script, and include Linux/macOS installation and usage steps where applicable.
- Present platform-agnostic or Linux-first options alongside Windows instructions to ensure parity and inclusivity.
- Add a table or section summarizing supported platforms for each tool, with links to relevant documentation for each OS.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-schema-alert.md
...b/main/articles/sentinel/normalization-schema-alert.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation page demonstrates a Windows bias in several areas: file paths and process examples use Windows conventions (e.g., C:\Windows\explorer.exe, C:\Windows\System32\notepad.exe), registry fields reference Windows Registry exclusively, and user identity examples use Windows formats (e.g., Contoso\JSmith, SID). There are no Linux or cross-platform examples for file paths, process names, or user identities, and no mention of Linux equivalents for registry or process fields. No Linux-specific tools or patterns are referenced.
Recommendations
- Provide Linux/Unix examples alongside Windows examples for file paths (e.g., /usr/bin/bash), process names, and command lines.
- Include Linux user identity formats (e.g., UID, user@domain) in user field examples.
- Clarify that registry fields are Windows-specific and, if applicable, describe how similar data might be represented on Linux (e.g., configuration files, /etc).
- Add examples of alerts and schema usage from Linux-based systems to ensure parity.
- Where possible, use neutral or cross-platform examples (e.g., generic process names, file paths) to avoid platform-specific bias.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/sentinel-playbook-creation.md
...b/main/articles/sentinel/sentinel-playbook-creation.md
High Priority
View Details →
Detected Bias Types
Powershell Heavy
Windows Tools
Missing Linux Example
Windows First
Summary
The documentation demonstrates a clear Windows bias in the sections describing how to generate and sanitize ARM templates for playbooks. The only automation script provided is a PowerShell script, and instructions reference running it in Visual Studio Code, Windows PowerShell, or PowerShell Core. There are no examples or guidance for performing these tasks on Linux or macOS, nor are alternative tools or shell commands mentioned. The documentation assumes the user is on a Windows environment, both in tool recommendations and in the order of presentation.
Recommendations
- Provide equivalent instructions for Linux and macOS users, including how to run the PowerShell script using PowerShell Core on those platforms.
- Explicitly state that PowerShell Core is cross-platform and provide installation links for Linux/macOS.
- Offer alternative methods for extracting and sanitizing ARM templates using Azure CLI, Bash, or other cross-platform tools.
- Include example commands and screenshots from Linux/macOS terminals where appropriate.
- Avoid assuming Visual Studio Code or Windows PowerShell as the default environment; mention cross-platform editors and shells.
- Add a section or note clarifying platform compatibility for all scripts and tools referenced.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-content.md
...s/blob/main/articles/sentinel/normalization-content.md
High Priority
View Details →
Detected Bias Types
Windows Tools
Powershell Heavy
Missing Linux Example
Windows First
Summary
The documentation page demonstrates a Windows bias by focusing heavily on Windows-specific tools, commands, and attack techniques (such as rundll32.exe, PowerShell, Certutil, Exchange PowerShell Snapin, and Windows System Shutdown/Reboot). Many hunting queries and analytic rules reference Windows-centric binaries and behaviors, with little to no mention of Linux or cross-platform equivalents. There are no explicit Linux examples or references to Linux-specific threats, tools, or command-line patterns. This may leave Linux users without clear guidance or parity in threat detection and hunting.
Recommendations
- Add Linux-specific examples and hunting queries, such as detections for common Linux persistence or privilege escalation techniques (e.g., cron jobs, systemd service abuse, SSH key misuse).
- Include analytic rules and hunting queries that reference Linux-native tools and binaries (e.g., bash, systemctl, sudo, /etc/passwd modifications).
- Balance the documentation by providing both Windows and Linux perspectives for each content area (process, file, registry, network, etc.), or explicitly state if a given rule is Windows-only.
- Highlight cross-platform detection strategies where possible, and clarify which rules are applicable to Linux, macOS, or other operating systems.
- Consider adding a section or table summarizing OS coverage for each analytic rule and hunting query.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-schema-user-management.md
...icles/sentinel/normalization-schema-user-management.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Windows Heavy Examples
Summary
The documentation exhibits a moderate Windows bias. Windows-specific identifiers (e.g., SID, Windows domain\username format) are consistently listed before Linux equivalents (e.g., UID, simple username). Examples and field priorities often use Windows-centric formats, and Windows terminology (such as SIDs, domain\username, and C:\Windows\System32\svchost.exe) is more prominent and detailed than Linux references. Linux is mentioned, but usually after Windows, and with less detail or fewer examples.
Recommendations
- Alternate the order of Windows and Linux examples throughout the documentation, or present them side-by-side to ensure parity.
- Provide Linux-specific examples (e.g., UID, /usr/bin/processname) wherever Windows examples are given (such as for ActorUserId, GroupId, ActingAppName).
- Expand on Linux username and group formats (e.g., user@host, /etc/passwd entries) in the same detail as Windows formats.
- Include Linux-specific terminology and normalization recommendations (e.g., mention GID for groups, typical Linux username conventions, and process paths).
- Ensure that field type recommendations and normalization guidelines are equally detailed for both Windows and Linux systems.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-schema-process-event.md
...rticles/sentinel/normalization-schema-process-event.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Windows Examples
Missing Linux Example
Summary
The documentation demonstrates a Windows bias through the exclusive use of Windows-style file paths (e.g., C:\Windows\explorer.exe), Windows-specific concepts (such as integrity levels and UAC), and examples referencing Windows tools and formats. While some fields mention Linux, there are no Linux-specific examples, terminology, or parity in explanations. Windows terminology and references are consistently presented first or exclusively, with little to no Linux context.
Recommendations
- Provide Linux-specific examples alongside Windows examples, such as using /usr/bin/bash or /usr/bin/sshd in process name/path fields.
- When describing fields like integrity levels or session IDs, include Linux equivalents or clarify how these concepts map (or do not map) to Linux systems.
- Balance the use of Windows and Linux terminology in field descriptions and examples, ensuring both platforms are represented.
- Add explicit notes or tables indicating differences in field population or semantics between Windows and Linux sources.
- Where Windows tools or concepts are referenced (e.g., UAC, Win32 integrity levels), provide Linux analogs or state when no direct equivalent exists.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/notebooks-msticpy-advanced.md
...b/main/articles/sentinel/notebooks-msticpy-advanced.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Missing Linux Example
Summary
The documentation provides both Windows and Linux instructions for setting environment variables, but Windows instructions are presented first, and Windows-specific tools (such as the System Properties dialog) are described in more detail. The Linux section is less detailed and assumes more user familiarity with the command line. There are also references to Windows environment variable syntax (e.g., %userprofile%) before Linux equivalents (~), and the Windows workflow is described in a more step-by-step, GUI-oriented manner, while Linux instructions are more condensed and terminal-focused. There are no PowerShell-specific commands, but the overall pattern prioritizes Windows tools and workflows.
Recommendations
- Present Linux and Windows instructions in parallel or in the same level of detail, rather than always listing Windows first.
- Provide equally detailed, step-by-step instructions for Linux users, including screenshots or explicit command examples for common tasks (e.g., editing .bashrc with nano or vim).
- When referencing environment variable paths, list both Windows (%userprofile%) and Linux (~) syntaxes together, or default to platform-agnostic language.
- Ensure that all examples and workflows are provided for both platforms, with clear parity in explanation and troubleshooting steps.
- Consider including PowerShell and Bash equivalents for any command-line instructions, and avoid assuming GUI access for Windows users only.