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 251-275 of 488 flagged pages
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-develop-parsers.md
...ain/articles/sentinel/normalization-develop-parsers.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Summary
The documentation demonstrates a Windows bias by referencing Windows-specific event sources (e.g., 'Microsoft-Windows-Sysmon'), using Windows-centric terminology and examples (such as EventID, ProcessName, and the Event table), and prioritizing Windows/PowerShell tools for deployment and management (e.g., recommending PowerShell scripts for deleting functions, and referencing Azure portal and PowerShell for ARM template deployment). There is a lack of explicit Linux or cross-platform deployment/testing instructions, and examples focus on Windows event sources or generic KQL, without showing Linux-specific log sources or command-line tools.
Recommendations
- Include Linux-specific examples, such as parsing logs from common Linux sources (e.g., auth.log, messages, or Linux audit logs) and show how to map these to ASIM schemas.
- Provide deployment and management instructions using cross-platform tools such as Azure CLI and/or REST API, not just PowerShell and Azure Portal.
- When referencing event sources or tables, include both Windows and Linux examples (e.g., show Syslog and Windows Event Log side by side).
- Explicitly mention and provide examples for Linux-based environments in sections discussing log collection, parser development, and testing.
- If recommending scripts or tools, ensure that Linux-compatible alternatives (e.g., Bash scripts, Azure CLI) are documented alongside PowerShell.
- Review terminology to ensure it is inclusive of both Windows and Linux environments, avoiding Windows-centric language where possible.
Create Pull Request
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/unified-connector-custom-device.md
...n/articles/sentinel/unified-connector-custom-device.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Missing Linux Example
Summary
The documentation generally provides both Windows and Linux examples for most applications, but there are several instances of Windows bias. In many cases, Windows file paths are listed before Linux equivalents ('windows_first'). Some applications (e.g., Apache Tomcat, NGINX, SecurityBridge) only provide Linux examples, omitting Windows instructions ('missing_linux_example'). There is a tendency to mention Windows tools and file paths, and the documentation refers to Windows-specific configuration files and patterns ('windows_tools'). While PowerShell commands are not explicitly shown, the overall structure and ordering favor Windows environments.
Recommendations
- For all application sections, ensure both Windows and Linux examples are provided, or explicitly state if a platform is not supported.
- When listing file paths or configuration steps, alternate the order (sometimes Linux first), or present both together to avoid 'windows_first' bias.
- Where only Linux examples are given (e.g., Apache Tomcat, NGINX, SecurityBridge), clarify if Windows is unsupported or provide equivalent Windows instructions if possible.
- If referencing Windows tools or configuration files, provide Linux equivalents or note platform-specific differences.
- Review general instructions and introductory sections to ensure parity in mentioning both platforms and avoid implicit prioritization of Windows.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/migration-splunk-historical-data.md
.../articles/sentinel/migration-splunk-historical-data.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation page demonstrates Windows bias by providing only a Windows-style file path (c:/data.csv) in the CLI example, omitting equivalent Linux/macOS examples. There is no mention of Linux/Unix file paths or shell environments, and the examples assume a Windows context for file output. No PowerShell-specific commands are present, but the lack of Linux parity and the use of Windows file path conventions indicate a bias.
Recommendations
- Provide equivalent Linux/macOS CLI examples using Unix-style file paths (e.g., /tmp/data.csv).
- Mention that the CLI commands work across platforms and clarify any OS-specific differences.
- Add notes or examples for running the commands in Linux/Unix shells (bash, zsh) as well as Windows Command Prompt or PowerShell.
- Use platform-neutral file paths in examples, or provide both Windows and Linux/macOS variants side by side.
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 demonstrates a Windows-first bias by focusing migration steps and examples almost exclusively on Windows systems and tools. It references Windows-specific connectors and solutions (e.g., 'Windows Security Events'), and does not provide equivalent Linux migration examples or mention Linux-specific connectors or tools. Linux is only briefly mentioned as a feature (multi-homing), with no concrete guidance or parity in migration steps.
Recommendations
- Include explicit migration steps and examples for Linux systems, such as connecting Linux machines to Microsoft Sentinel using AMA.
- Reference and link to Linux-specific connectors or solutions (e.g., 'Linux Security Events via AMA'), if available.
- Provide sample configurations or screenshots for Linux environments, similar to those given for Windows.
- Ensure that prerequisites and troubleshooting sections address both Windows and Linux environments equally.
- Mention Linux tools and commands for agent management and uninstallation, not just Windows tools.
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
Windows First
Missing Linux Example
Summary
The documentation page demonstrates a bias toward Windows and Microsoft-centric tools and workflows. All example playbooks, templates, and integrations focus on Microsoft products (Teams, Outlook, Entra, Defender for Endpoint, Azure Firewall) and ServiceNow, with no mention of Linux-native tools, open-source alternatives, or cross-platform command-line examples. There are no references to Linux firewalls (e.g., iptables, nftables), Linux user management, or Linux-based notification/email systems. The examples and screenshots are all oriented around Microsoft and Windows-centric environments, with no Linux parity.
Recommendations
- Include examples of playbooks that interact with Linux-based systems, such as blocking an IP using iptables/nftables or disabling a Linux user account.
- Provide notification playbook templates that use Linux-friendly tools (e.g., sendmail, postfix, or integration with open-source chat platforms like Mattermost or Rocket.Chat).
- Add cross-platform examples or note how to adapt playbooks for non-Microsoft environments.
- Mention and provide sample connectors or actions for popular Linux-based security and infrastructure tools (e.g., syslog, fail2ban, Linux firewalls, LDAP).
- Ensure that Linux and open-source options are presented alongside Microsoft/Windows tools, not just as an afterthought.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/configure-connector-login-detection.md
...ticles/sentinel/configure-connector-login-detection.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 referencing Windows Security Events, Windows event IDs, and Windows-centric connectors. There are no examples or mentions of equivalent Linux audit logs, connectors, or event IDs for RDP or remote login detection. The instructions and prerequisites are exclusively tailored to Windows, with no guidance for Linux systems.
Recommendations
- Include information on how to collect and analyze remote login events from Linux systems (e.g., using syslog, auditd, or SSH logs).
- Provide equivalent event IDs or log types for Linux (such as SSH login events) and describe how to configure connectors for these sources.
- Add Linux-specific examples and configuration steps alongside Windows instructions.
- Clarify whether the anomalous login detection feature supports non-Windows platforms, and if not, note this limitation explicitly.
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 →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Missing Linux Example
Summary
The documentation demonstrates a Windows-first bias in several ways. Windows log collection is discussed before Linux, with more detailed and varied solutions (e.g., Windows Event Forwarding, PowerShell, ARM templates) and specific references to Windows tools and patterns. Some solutions (like PowerShell and Windows Event Forwarding) are mentioned without Linux equivalents or are presented as default approaches. Linux solutions are grouped together and sometimes lack the same level of detail or practical examples. In some cases, Windows-specific tools (e.g., PowerShell) are suggested without mentioning Linux alternatives, and the documentation often lists Windows methods before Linux ones, even in cross-platform sections.
Recommendations
- Ensure Linux and Windows sections are given equal prominence and detail, possibly by interleaving examples or providing parallel solution tables.
- When mentioning Windows-specific tools (e.g., PowerShell, Windows Event Forwarding), also mention Linux equivalents (e.g., Bash scripts, Syslog forwarding) in the same context.
- Provide Linux command-line examples (e.g., Bash, systemd, rsyslog configuration) wherever PowerShell or Windows commands are given.
- Avoid presenting Windows solutions first by default; alternate the order or present both platforms together where possible.
- Expand Linux solution details to match the depth provided for Windows, including practical configuration steps and considerations.
- Review endpoint and cloud platform sections to ensure Linux-native tools and patterns are included and described with parity.
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 in the section 'Use data collection rules for your Windows Security Events', where only Windows-specific data collection (Windows Security Events connector) is discussed in detail. There are no equivalent examples or guidance for Linux data collection, connectors, or cost optimization strategies, despite Linux being a common platform in cloud environments. The focus on Windows tools and the absence of Linux parity in examples and recommendations may leave Linux users underserved.
Recommendations
- Add a parallel section describing data collection rules and connectors for Linux security events, such as using the Linux Syslog connector or the Azure Monitor Agent on Linux.
- Provide examples and cost optimization tips for Linux data sources, including how to filter or reduce ingestion from Linux logs.
- Mention Linux alongside Windows in relevant sections to ensure parity and inclusivity.
- Link to documentation on configuring data collection for Linux systems in Microsoft Sentinel.
- Review other sections for implicit Windows-first assumptions and ensure cross-platform guidance is provided where applicable.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/bring-your-own-ml.md
...-docs/blob/main/articles/sentinel/bring-your-own-ml.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation demonstrates a Windows bias by focusing on Windows-specific data sources (e.g., Windows file share access logs), referencing Windows Security Events, and omitting equivalent Linux log sources or examples. The only log example provided is for Windows (Event ID 5140), and there are no instructions or templates for Linux audit logs or other non-Windows environments. Additionally, the documentation does not mention or provide examples for exporting or processing Linux-based logs, nor does it discuss Linux-specific tools or patterns.
Recommendations
- Add examples and templates for Linux log sources, such as auditd or syslog, alongside the existing Windows examples.
- Include instructions for exporting Linux logs to Azure Blob Storage or Event Hub, possibly using common Linux tools (e.g., rsyslog, logrotate, or custom scripts).
- Provide sample data formats and notebooks for Linux-based security events, ensuring parity with the Windows-focused Anomalous Resource Access example.
- Mention both Windows and Linux log types in introductory and walkthrough sections to make it clear that the platform supports both.
- Where possible, generalize language to refer to 'operating system logs' or 'security events' rather than only Windows-specific terms.
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 bias toward Windows environments by referencing PowerShell deployment scripts as the mechanism for custom deployment options, without mentioning or providing alternatives for Linux or cross-platform scripting. There are no examples or guidance for using Bash, shell scripts, or other Linux-native tools. The documentation assumes the use of PowerShell in automation pipelines, which may not be suitable for Linux-first or cross-platform teams.
Recommendations
- Provide equivalent Bash or shell script examples for deployment customization, alongside PowerShell.
- Explicitly mention that deployment scripts can be implemented in other languages or shells, and provide guidance or references for Linux users.
- Clarify whether the provided PowerShell scripts are compatible with PowerShell Core (pwsh) on Linux/macOS, and if not, offer alternatives.
- Include notes or sections on running repository deployment workflows in Linux-based CI/CD environments (e.g., GitHub Actions runners on Ubuntu, Azure Pipelines with Linux agents).
- Avoid assuming PowerShell as the default automation tool; instead, present it as one option among several cross-platform choices.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-azure-virtual-desktop.md
...ain/articles/sentinel/connect-azure-virtual-desktop.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation page demonstrates a Windows bias by exclusively referencing Windows event logs, Windows endpoints, and Windows-specific tools (such as the Azure Monitor Agent for Windows). There are no examples or instructions for Linux-based Azure Virtual Desktop environments, nor are Linux equivalents or cross-platform considerations mentioned.
Recommendations
- Include guidance for monitoring Linux-based virtual desktops if supported, or explicitly state if only Windows is supported.
- Provide examples or references for collecting logs and security data from Linux environments, using Linux-compatible agents or tools.
- Mention cross-platform capabilities and limitations where applicable, to clarify the scope for users on non-Windows platforms.
- If Linux is not supported for Azure Virtual Desktop, add a clear note to inform users and avoid ambiguity.
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 exhibits mild Windows bias, primarily through the use of Windows-centric terminology (e.g., 'NTDomain', 'Windows domain'), and by listing Windows-style file paths (e.g., 'C:\ProgramFiles\WindowsNT\Accessories\wordpad.exe') before Linux equivalents in examples. Several field descriptions reference Windows-specific concepts before or instead of Linux/UNIX equivalents, though some UNIX references are present. There are no PowerShell-specific examples or exclusive Windows tool mentions, but the ordering and terminology favor Windows environments.
Recommendations
- When providing examples (such as file paths), alternate the order or give Linux/UNIX examples first in some cases to balance representation.
- For fields like 'deviceNtDomain' and 'dntdom', clarify that these are Windows-specific and, where possible, mention the Linux/UNIX equivalent or note when not applicable.
- In field descriptions, ensure that both Windows and Linux/UNIX terminology are used equally (e.g., for process names, domains, and file paths).
- Consider adding a brief section or note explaining how the mapping applies to both Windows and Linux/UNIX sources, and highlight any differences.
- Review all examples and field descriptions to ensure Linux/UNIX environments are equally represented and not treated as secondary.
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-based deployment instructions, referencing Windows-centric tools and patterns (such as PowerShell and ARM templates), and omitting explicit Linux or cross-platform CLI examples. The Python deployment instructions require Visual Studio Code, which, while cross-platform, is not the default or most common development environment on Linux. There are no examples using Azure CLI, Bash, or other Linux-native tools, and the PowerShell manual deployment is described before the Python method.
Recommendations
- Add explicit Linux/Bash/Azure CLI examples for deploying and managing Azure Functions-based connectors.
- Include instructions for deploying Python-based connectors using the Azure CLI or other Linux-native tools, not just Visual Studio Code.
- Present deployment options in a neutral order or explicitly state that all methods are cross-platform where applicable.
- Reference cross-platform tools (e.g., Azure CLI, REST API) alongside or before Windows/PowerShell-specific tools.
- Clarify that PowerShell Core is cross-platform, but provide equivalent Bash or shell script examples for Linux users.
- Add a section or callout for Linux/macOS users to ensure parity and inclusivity.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/configure-data-connector.md
...lob/main/articles/sentinel/configure-data-connector.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 and Microsoft-centric services and tools in examples and references. It specifically highlights connecting to Azure, Windows, Microsoft, and Amazon services, but does not mention Linux or non-Windows data sources or provide Linux-specific configuration examples. There are no references to Linux tools, syslog, or Linux-based data connector scenarios, and all screenshots and navigation paths are focused on Microsoft portals.
Recommendations
- Include explicit examples and instructions for connecting Linux-based data sources (e.g., syslog, Linux servers, or open-source security tools) to Microsoft Sentinel.
- Add references and links to documentation for Linux data connectors, such as those for Syslog, CEF, or custom log ingestion from Linux systems.
- Balance the mention of Windows and Linux by providing parallel configuration steps or navigation paths for both environments.
- In the 'Connect Microsoft Sentinel to...' section, mention Linux and open-source services alongside Windows and Microsoft services.
- Add screenshots or command-line examples relevant to Linux environments, such as using Bash or SSH, where appropriate.
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 →
Detected Bias Types
Powershell Heavy
Windows Tools
Missing Linux Example
Summary
The documentation references PowerShell as the only CLI automation method for pushing rules to Microsoft Sentinel, with no mention of Linux-compatible alternatives (such as Azure CLI, Bash, or cross-platform scripting). There are no examples or instructions for Linux users, and the only automation tool explicitly mentioned is PowerShell, which is traditionally associated with Windows environments.
Recommendations
- Include examples using Azure CLI or REST API with curl to demonstrate cross-platform automation.
- Explicitly mention that PowerShell Core is available on Linux and provide Linux-specific usage notes if PowerShell is required.
- Add Bash or shell script examples for exporting/enabling rules, or clarify if such workflows are not supported.
- Ensure that all automation and scripting guidance is platform-neutral or provides parity for both Windows and Linux users.
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 →
Detected Bias Types
Powershell Heavy
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation exhibits a Windows bias by recommending and providing only PowerShell-based automation for setup, requiring PowerShell installation even for cross-platform tasks, and not mentioning or providing equivalent instructions or scripts for Linux or macOS users. All command-line examples and automation are centered on PowerShell, with no Bash, shell, or Linux-native alternatives. The prerequisite section lists PowerShell before AWS CLI, and the automation script is described as being run from a PowerShell command line, with no mention of Linux shells or terminals.
Recommendations
- Provide Bash or shell script equivalents for the PowerShell automation, or clarify if the provided PowerShell scripts are cross-platform (PowerShell Core) and can be run on Linux/macOS.
- Explicitly mention Linux and macOS support in the prerequisites and setup instructions, including installation links for PowerShell Core on those platforms if required.
- Include command-line examples for Linux/macOS users, or at least clarify the steps for running the automation scripts in those environments.
- If the automation script is Windows-only, provide a manual or alternative automated setup path for Linux/macOS users.
- Reorder prerequisites and instructions to avoid always listing Windows/PowerShell first; consider a platform-neutral or parallel structure.
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 →
Detected Bias Types
Windows First
Powershell Heavy
Missing Linux Example
Summary
While the documentation claims support for both Windows and Linux, there is a subtle Windows bias. Windows terminology (e.g., PowerShell) is often mentioned first, and explicit step-by-step examples or scripts for Windows (such as PowerShell installation) are referenced, while equivalent Linux command-line examples are less prominent or missing. The Linux-specific setup is mostly relegated to the log forwarder scenario, and there are no detailed Linux installation or configuration walkthroughs for the agent itself. In several places, Windows tools or patterns are mentioned before Linux equivalents.
Recommendations
- Provide explicit Linux command-line examples (e.g., shell commands for installing the Azure Monitor Agent on Linux, not just PowerShell for Windows).
- Ensure that for every Windows example or tool mentioned (such as PowerShell), an equivalent Linux example (such as Bash or shell commands) is provided and given equal prominence.
- In lists or instructions, alternate the order or present both Windows and Linux options side by side, rather than defaulting to Windows-first.
- Add screenshots or walkthroughs of the Linux experience where applicable (e.g., installing the agent, configuring data collection rules via CLI on Linux).
- Clarify in each section whether the instructions apply to both Windows and Linux, and avoid assuming Windows as the default environment.
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. All examples, prerequisites, and configuration steps are tailored exclusively to Windows Server, with no mention of Linux-based DNS servers or how to achieve similar functionality on Linux. Windows tools, logs, and event types are referenced throughout, and there are no Linux equivalents or cross-platform guidance provided.
Recommendations
- Add equivalent instructions and examples for collecting and filtering DNS logs from Linux-based DNS servers (e.g., BIND, Unbound, dnsmasq).
- Include prerequisites and setup steps for Linux environments, such as supported distributions, required packages, and log file locations.
- Provide API and portal configuration examples that reference Linux data sources and illustrate how to normalize and ingest Linux DNS logs.
- Reference Linux tools and logging patterns (e.g., systemd-journald, syslog, logrotate) alongside Windows event logs.
- 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.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/customize-entity-activities.md
.../main/articles/sentinel/customize-entity-activities.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation page demonstrates a Windows bias by providing examples and descriptions that are specific to Windows environments (e.g., referencing Windows event IDs, Active Directory, and NTDomain identifiers) without offering equivalent Linux or cross-platform examples. The entity identifiers and sample queries are tailored to Windows-centric data sources, and there is no mention of Linux audit logs, syslog, or Linux user/group management events. The documentation assumes a Windows/Active Directory environment as the default context for customization, omitting guidance for organizations using Linux-based infrastructure.
Recommendations
- Include Linux-specific examples, such as detecting user group changes via Linux audit logs (e.g., /var/log/audit/audit.log) or syslog.
- Provide sample KQL queries for common Linux security events (e.g., sudo usage, user creation, group membership changes) alongside Windows examples.
- Expand the list of entity identifiers to include Linux-relevant fields, such as UID, GID, or Linux hostnames.
- Mention Linux data sources (e.g., Syslog, Linux auditd) in the activity template and configuration sections.
- Balance the documentation by presenting both Windows and Linux scenarios, or explicitly state if the feature is currently Windows-only.
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
Powershell Heavy
Windows Tools
Missing Linux Example
Summary
The documentation page is largely platform-neutral in its core instructions, focusing on the Microsoft Sentinel UI in the Azure and Defender portals. However, in the 'Next steps' section, automation and scripting are only referenced via PowerShell and API, with no mention of Linux-native tools or CLI alternatives. There are no Linux shell (bash/CLI/az CLI) examples or references, and PowerShell is the only scripting tool explicitly linked. This creates a subtle Windows bias, especially for users seeking automation or scripting guidance from Linux environments.
Recommendations
- Provide equivalent automation instructions and examples using Azure CLI (az) and/or bash scripts, not just PowerShell.
- When referencing scripting or automation, mention both PowerShell and cross-platform tools (e.g., az CLI, REST API with curl, Python SDK).
- Include explicit notes or examples for Linux/macOS users, especially in sections about exporting/importing rules, automation, and scripting.
- Where possible, link to documentation or guides for using Microsoft Sentinel with Linux-native tools.
- Avoid implying PowerShell is the only or primary automation method; present it alongside other cross-platform options.
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
Powershell Heavy
Summary
The documentation demonstrates a mild Windows bias. File path examples consistently mention Windows paths (e.g., 'c:\temp') before Linux equivalents ('/tmp'), and the sample output file names use Windows-style paths as the primary example. Configuration examples and instructions often default to Windows conventions. There is also a reference to retrieving tenant IDs via the Microsoft Entra ID portal, which is a GUI-centric (and often Windows-used) approach, with no mention of CLI alternatives. However, Linux is not entirely neglected: Linux paths and commands (such as logger) are included, and there is a troubleshooting note for Ubuntu Docker images. There are no PowerShell-specific commands, but the overall pattern is to mention Windows first and more prominently.
Recommendations
- Present Linux and Windows examples side by side, or alternate which OS is presented first in examples.
- When giving file path examples, use both Windows and Linux formats together (e.g., 'c:\temp' (Windows) and '/tmp' (Linux)), or use OS-agnostic placeholders.
- For instructions that reference the Azure portal for information retrieval, also provide CLI-based alternatives (e.g., using Azure CLI or Bash commands) to support headless and Linux-first workflows.
- Ensure that all code snippets and configuration examples are equally applicable to both Windows and Linux environments, and explicitly state any OS-specific differences.
- Add a section or callout summarizing cross-platform compatibility and any known OS-specific caveats.
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 →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation is exclusively focused on Windows DNS servers and the Windows DNS Events via AMA connector. All examples, field mappings, and descriptions refer only to Windows environments and tools, with no mention of Linux-based DNS servers, Linux logging mechanisms, or cross-platform applicability. The documentation assumes a Windows context throughout, omitting Linux equivalents or guidance.
Recommendations
- Add sections or notes describing support (or lack thereof) for Linux DNS servers and clarify if the AMA connector can be used with Linux-based DNS logs.
- Provide equivalent field mapping tables and filtering examples for common Linux DNS servers (e.g., BIND, Unbound, dnsmasq) if supported.
- If Linux is not supported, explicitly state this early in the documentation to set user expectations.
- Include references or links to documentation covering DNS log ingestion from Linux servers, if available.
- Ensure future updates consider parity between Windows and Linux environments, especially for cross-platform products like Microsoft Sentinel.
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 →
Detected Bias Types
Powershell Heavy
Windows Tools
Windows First
Missing Linux Example
Summary
The documentation demonstrates a Windows bias by focusing on Windows-specific tools and technologies such as PowerShell and WMI, referencing them in detection scenarios without mentioning Linux or cross-platform equivalents. Examples and threat detections are described in terms of Windows-centric activities (e.g., PowerShell command execution, WMI, Microsoft Defender for Endpoint), and there are no Linux-specific examples or references to Linux-native tools or attack patterns. The documentation assumes a Windows environment for endpoint detection and response, with no guidance for Linux-based systems.
Recommendations
- Include examples and detection scenarios that reference Linux-based attack techniques and tools (e.g., bash scripts, cron jobs, SSH abuse, Linux credential dumping tools like 'gsecdump' or 'LaZagne').
- When describing suspicious command execution, provide Linux equivalents alongside PowerShell and WMI (e.g., bash, python, perl, systemd misuse).
- Reference cross-platform endpoint detection tools and data sources, such as Microsoft Defender for Endpoint for Linux, and clarify how these scenarios apply to Linux systems.
- Add detection scenarios for Linux-specific threats (e.g., rootkit installation, unauthorized use of sudo, suspicious use of system binaries).
- Balance the order of presentation so that Windows and Linux examples are given equal prominence, or explicitly state when a scenario is Windows-only.
- Where possible, generalize descriptions of suspicious activity (e.g., 'suspicious script execution') and then provide both Windows and Linux examples.
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 demonstrates a moderate Windows bias. Several detection scenarios and examples reference Windows-specific tools and technologies, such as PowerShell and Windows event logs, without providing Linux or cross-platform equivalents. The ransomware detection example lists only Windows malware and Windows event sources. Scenario descriptions highlight PowerShell and WMI (both Windows-centric) as suspicious activity vectors, and 'Windows Error and Warning Events' are used as an example alert source. There are no explicit Linux or Unix examples, nor are Linux-specific tools or attack patterns discussed. While the documentation is focused on Microsoft Sentinel (which is itself a Microsoft/Azure product), the lack of Linux parity in examples and scenario coverage may limit its usefulness for organizations with heterogeneous environments.
Recommendations
- Include Linux-specific detection scenarios, such as suspicious Bash or shell script execution, anomalous sudo activity, or Linux-specific malware/ransomware alerts.
- Provide examples of alerts generated from Linux event sources (e.g., syslog, auditd, or Linux security logs) alongside Windows event examples.
- When referencing suspicious command-line activity, include both PowerShell (Windows) and Bash (Linux) examples.
- Highlight support for cross-platform data connectors and analytics rules, and clarify how Fusion handles signals from Linux-based systems.
- In scenario tables and examples, balance Windows and Linux sources/tools to reflect real-world, mixed-environment deployments.
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 agents and tools in several connector descriptions, particularly for Microsoft Exchange and Security Events connectors, where only Windows machines and agents are mentioned explicitly. Linux equivalents are either omitted or only briefly referenced (e.g., Syslog via Legacy Agent is listed, but not cross-referenced in Windows-centric sections). There is a lack of Linux-specific examples or parity in prerequisites and instructions, especially for connectors that could apply to both platforms.
Recommendations
- For connectors that mention Windows agents or tools (e.g., Microsoft Exchange Logs and Events, Security Events via Legacy Agent), explicitly state if Linux equivalents exist and provide parallel instructions/examples for Linux where applicable.
- Where agent installation is discussed, include both Windows and Linux agent installation procedures and links, not just Windows or PowerShell-focused tabs.
- Cross-reference the Syslog (Linux) connector in sections that discuss Windows event collection to highlight Linux support.
- Ensure that all prerequisites and setup steps are platform-neutral or provide both Windows and Linux variants where possible.
- Review all connector documentation for implicit Windows-first language and update to reflect equal support for Linux where available.