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 276-300 of 488 flagged pages
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 →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation exhibits a Windows bias in several areas. Many connectors and examples, especially those related to Microsoft Exchange, Active Directory, IIS, and DNS, are described exclusively in the context of Windows servers and Windows agents. Instructions and prerequisites often reference 'Windows machines', 'Windows agent', or 'Windows Event logs' without mentioning Linux equivalents or providing parallel Linux instructions. In some cases, only Windows-specific tools or logging mechanisms (e.g., Windows Firewall, Windows Event Forwarding) are discussed, and Linux alternatives (such as Syslog or Linux firewalls) are either omitted or only briefly mentioned. This creates an impression that Windows is the primary or default platform for these integrations, with Linux support being secondary or absent.
Recommendations
- For every connector or example that references Windows-specific tools (e.g., Windows Event logs, Windows Firewall, IIS), provide equivalent Linux examples (e.g., Syslog, iptables/ufw, Apache/Nginx logs) where applicable.
- Where instructions mention 'Windows machines' or 'Windows agent', clarify if and how Linux machines are supported, and provide explicit Linux setup steps if available.
- For connectors that support both Windows and Linux (such as 'Custom logs via AMA' or 'Syslog via AMA'), ensure that Linux is mentioned equally and that Linux-specific guidance is as detailed as the Windows guidance.
- If certain features are Windows-only, explicitly state this and, if possible, suggest alternative approaches for Linux users.
- Review the ordering of examples and documentation sections to avoid always listing Windows first; alternate or group by platform where appropriate.
- Encourage contributors to include Linux prerequisites, commands, and troubleshooting steps alongside Windows content.
Create Pull Request
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/includes/sap-agentless-prerequisites.md
...icles/sentinel/includes/sap-agentless-prerequisites.md
High Priority
View Details →
Detected Bias Types
Powershell Heavy
Missing Linux Example
Windows Tools
Windows First
Summary
The documentation provides only a PowerShell script example for running the prerequisite checker, which is specific to Windows environments. There are no equivalent examples or instructions for Linux or cross-platform command-line tools (such as Bash, curl, or Python). The exclusive use of PowerShell and Windows-centric tooling may hinder users on Linux or macOS from following the instructions directly.
Recommendations
- Provide equivalent Bash or shell script examples using curl or wget for Linux/macOS users.
- Explicitly mention that the PowerShell script is for Windows and offer alternative instructions for other platforms.
- Where possible, use cross-platform tools or languages (e.g., Python, curl) in examples.
- Add a section or note clarifying platform compatibility and linking to platform-specific guidance if available.
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
Windows Tools
Missing Linux Example
Summary
The documentation references a PowerShell cmdlet (Unlock-SPOSensitivityLabelEncryptedFile) as the only command-line tool for interacting with sensitivity labels, without providing equivalent Linux or cross-platform alternatives. There are no Linux shell or CLI examples, and the documentation implicitly assumes a Windows/PowerShell environment for administrative tasks.
Recommendations
- Provide equivalent CLI examples using cross-platform tools such as Azure CLI, Microsoft Graph API, or REST API calls that can be executed from Linux/macOS environments.
- Explicitly mention whether the referenced PowerShell cmdlet is available via PowerShell Core (pwsh) on Linux/macOS, or provide guidance for Linux users.
- Add a section or note addressing how Linux or non-Windows users can perform the same operations, or clarify if certain actions are Windows-only.
- Where possible, use platform-agnostic language and tools in examples to ensure parity for all users.
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 a Windows bias by recommending tools (LightIngest) that are Windows-only, not providing Linux alternatives or examples, and generally assuming a Windows environment for ingestion tasks. While AzCopy is cross-platform, the documentation does not clarify or provide Linux-specific usage instructions. There are no Linux command-line examples or explicit mentions of Linux-compatible ingestion workflows.
Recommendations
- For LightIngest, explicitly state that it is Windows-only and suggest alternative ingestion methods for Linux environments, such as using Azure Data Explorer's ingestion REST API, Azure CLI, or Python SDK.
- For AzCopy, include explicit Linux installation and usage instructions, with example commands for Linux shells.
- Wherever scripts or tools are referenced, clarify their OS compatibility and provide parallel instructions or links for both Windows and Linux users.
- Add a section or callout addressing Linux users, summarizing supported ingestion tools and methods for non-Windows environments.
- Ensure that all code snippets and instructions are provided for both PowerShell/Windows CMD and Bash/Linux shells where applicable.
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 →
Detected Bias Types
Powershell Heavy
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation demonstrates a Windows bias in several areas: PowerShell scripts are the primary or only example given for Azure Monitor ingestion, and the SIEM data migration accelerator deploys a Windows VM by default. While some tools (like AzCopy and Logstash) are cross-platform, the documentation emphasizes Windows-centric tools and patterns, often mentioning Windows or PowerShell before Linux alternatives. There is a lack of explicit Linux/bash examples or guidance, especially for key migration scenarios.
Recommendations
- Provide equivalent bash or shell script examples for ingestion tasks, especially for Azure Monitor custom log ingestion.
- Explicitly mention and demonstrate how to use cross-platform tools (like AzCopy, Logstash) on Linux, including installation and usage examples.
- For the SIEM data migration accelerator, offer an option to deploy a Linux VM or container, or clarify how to run the migration tools on Linux.
- Avoid defaulting to PowerShell in examples; where PowerShell is shown, also provide a Linux-compatible alternative (e.g., Python, bash, or REST API via curl).
- In tool tables and descriptions, indicate OS compatibility and avoid listing Windows tools first unless there is a technical reason.
- Highlight any limitations or differences in tool behavior between Windows and Linux, and provide workarounds if necessary.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/migration-arcsight-detection-rules.md
...rticles/sentinel/migration-arcsight-detection-rules.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by exclusively using Windows-centric data sources (e.g., SecurityEvent table, which is populated by Windows Security Events), focusing on Windows event IDs, and not providing equivalent Linux or cross-platform examples. All KQL examples reference Windows-specific logs and fields, and there is no mention of Linux data sources, event types, or how to migrate Linux-based ArcSight rules. The documentation assumes the use of the Azure Monitoring Agent (AMA) for Windows Security Events and does not address Linux log collection or rule migration scenarios.
Recommendations
- Include examples using Linux data sources, such as Syslog, CommonSecurityLog, or custom tables populated from Linux servers.
- Provide KQL queries that demonstrate how to migrate ArcSight rules for Linux event types (e.g., authentication, sudo, SSH, process creation).
- Mention and link to documentation on connecting Linux data sources to Microsoft Sentinel, including configuration steps for the AMA or Log Analytics agent on Linux.
- Balance the presentation order by alternating or pairing Windows and Linux examples, or by providing a cross-platform example where possible.
- Clarify in the introduction that the guidance applies to both Windows and Linux environments, and explicitly call out any differences or additional steps required for Linux.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-about-schemas.md
.../main/articles/sentinel/normalization-about-schemas.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation demonstrates a Windows bias by providing detailed normalization examples and mappings exclusively for Windows event 4624, referencing Windows-specific concepts (such as SIDs and Windows usernames) before or instead of Linux equivalents. While Linux user IDs (UID) are mentioned in field type tables, there are no concrete Linux event examples or mappings, and Windows-centric terminology and tools (e.g., Windows event fields, SIDs, Windows domain\username format) are prioritized throughout. Linux tools, event types, or normalization scenarios are not given parity in examples or guidance.
Recommendations
- Add parallel Linux event normalization examples (e.g., mapping a Linux authentication log event to ASIM fields) alongside the Windows event 4624 example.
- Include Linux-specific field mapping tables and sample values (e.g., mapping /var/log/auth.log fields, Linux UIDs, and usernames).
- Reference Linux event types and tools (such as auditd, syslog, or journald) in schema mapping and normalization guidance.
- Ensure that field type tables and entity descriptions provide Linux examples with equal prominence to Windows examples.
- Where possible, provide cross-platform comparison tables or diagrams to illustrate normalization from both Windows and Linux sources.
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
Powershell Heavy
Windows Tools
Windows First
Summary
The documentation page demonstrates a Windows bias in several ways: many of the analytic rules and hunting queries focus on Windows-specific tools, processes, and attack techniques (e.g., rundll32.exe, PowerShell, Certutil, Exchange PowerShell Snapin, Windows System Shutdown/Reboot). There is a notable emphasis on PowerShell-based attacks and Windows-native binaries (LOLBins), with little to no mention of Linux-specific equivalents or examples. The process activity and hunting queries sections are particularly Windows-centric, and Linux tools, commands, or attack patterns are not represented. This creates an impression that the content is primarily relevant to Windows environments.
Recommendations
- Add Linux-specific analytic rules and hunting queries, such as detection for common Linux persistence techniques, suspicious use of bash, cron jobs, or systemd services.
- Include examples of Linux-native attack tools (e.g., bash scripts, python reverse shells, netcat, SSH abuse) alongside Windows tools.
- Balance the coverage of Windows and Linux by providing parity in detection rules for both platforms (e.g., detect suspicious sudo usage, unauthorized changes to /etc/passwd, or Linux-specific malware).
- Explicitly mention cross-platform applicability where possible, and clarify if a rule is Windows-only.
- Add hunting queries and analytic rules for Linux process activity, file activity, and network events, not just Windows-centric ones.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-common-fields.md
.../main/articles/sentinel/normalization-common-fields.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by providing examples and references that prioritize Windows concepts and tools. For instance, the only concrete event table example is 'WindowsEvent', and original event type/subtype examples are Windows-specific (e.g., Windows event ID 4624, Windows logon type 2). The FQDN example uses the Windows domain\hostname format, and the device hostname example is 'ContosoDc', a typical Windows naming convention. While Linux is mentioned in the vendor/product list, there are no Linux-specific field examples or event references, and Windows-related fields and formats are described first or exclusively.
Recommendations
- Add Linux-specific examples alongside Windows ones, such as Linux event IDs, syslog formats, or Linux hostnames.
- When describing fields like EventOriginalType or EventOriginalSubType, include Linux-originated event examples (e.g., auditd event types, sudo event IDs).
- In FQDN and hostname examples, provide both Windows and Linux naming conventions (e.g., 'host.example.com' for Linux/Unix).
- For device fields, use a mix of Windows and Linux hostnames (e.g., 'ContosoDc' and 'webserver01').
- Ensure that Linux tools and event sources are referenced with equal prominence to Windows equivalents throughout the documentation.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-parsers-list.md
...b/main/articles/sentinel/normalization-parsers-list.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Missing Linux Example
Summary
The documentation demonstrates a Windows bias by consistently listing Windows sources, tools, and event types first or in greater detail compared to Linux equivalents. Windows-specific connectors, event IDs, and collection methods are described in depth, while Linux sources are mentioned less frequently and often lack equivalent detail or examples. Windows event collection patterns (e.g., Security Events, Sysmon, WEF) and Microsoft-centric tooling are emphasized, with Linux and cross-platform alternatives sometimes only briefly referenced or omitted.
Recommendations
- Ensure Linux and cross-platform sources are given equal prominence in tables and lists, not always after Windows sources.
- Provide detailed examples and collection patterns for Linux (e.g., Syslog, auditd, Linux Sysmon) equivalent to those given for Windows (event IDs, connectors, etc.).
- Include Linux-specific event IDs, log types, and connectors in all relevant sections, not just as afterthoughts.
- Where Windows tools (e.g., WEF, Event Viewer, Security Events) are mentioned, also mention and explain Linux tools (e.g., journalctl, auditd, syslog-ng) and how they integrate with Sentinel.
- Add explicit Linux usage and deployment examples, including sample log lines, configuration steps, and troubleshooting tips.
- Review all parser lists to ensure Linux and other non-Windows platforms are represented wherever possible, and not just under generic or Microsoft-centric headings.
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 ways: field examples and descriptions frequently use Windows-centric paths, tools, and concepts (e.g., C:\Windows\explorer.exe, Registry keys, PsExec), and there are no Linux or cross-platform examples provided. Windows terminology and artifacts are referenced exclusively, and Linux equivalents are not mentioned or illustrated.
Recommendations
- Add Linux-based examples alongside Windows ones for fields such as FilePath (e.g., /usr/bin/sshd), ProcessName, and Registry (or note the absence of a Linux equivalent).
- Include cross-platform or Linux-specific tools (e.g., SSH, systemd, auditd) in rule and threat examples, not just Windows tools like PsExec.
- Clarify in field descriptions when a concept is Windows-specific (e.g., Registry fields), and suggest how to handle or map similar data from Linux or macOS systems.
- Provide at least one end-to-end example for a Linux-originating alert event, showing how fields would be populated.
- Review enumerated values and examples for user and process fields to ensure they are not solely Windows-centric (e.g., include Linux username formats, UIDs, and process paths).
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-schema-authentication.md
...ticles/sentinel/normalization-schema-authentication.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation page exhibits a mild Windows bias. Windows is the only OS mentioned explicitly in introductory and example contexts (e.g., 'Windows sends several authentication events', 'C:\Windows\System32\svchost.exe', 'Windows 10'). Device and field examples use Windows-centric naming conventions (e.g., 'DESKTOP-1282V4D', 'Contoso\DESKTOP-1282V4D'), and protocols like NTLM are referenced without Linux/Unix equivalents. There are no Linux or Unix-specific examples, tools, or field values, and no mention of Linux authentication protocols (e.g., PAM, Kerberos as used in Linux, SSH logins, etc.).
Recommendations
- Include Linux/Unix-specific examples alongside Windows ones, such as sample hostnames (e.g., 'ubuntu-server', 'centos7'), file paths (e.g., '/usr/bin/sshd'), and OS names (e.g., 'Ubuntu 22.04').
- Mention Linux/Unix authentication protocols (e.g., PAM, SSH, Kerberos as used in Linux) in the relevant fields (LogonProtocol, LogonMethod) and provide example values.
- Balance field value examples to include both Windows and Linux/Unix conventions (e.g., show both 'DOMAIN\user' and 'user@domain' or just 'user').
- Explicitly state that the schema is intended to normalize authentication events from both Windows and Linux/Unix systems, and provide guidance or links for Linux data sources.
- Where device types or OS fields are discussed, include Linux/Unix as example values (e.g., 'Windows 10', 'Ubuntu 22.04', 'Red Hat Enterprise Linux 8').
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-schema-dhcp.md
...ob/main/articles/sentinel/normalization-schema-dhcp.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Windows Heavy Examples
Summary
The documentation demonstrates a Windows bias by prioritizing Windows terminology, formats, and examples throughout the schema reference. Windows-specific formats (such as domain\hostname, SID, and Windows DHCP server log quirks) are mentioned before or more prominently than their Linux or open-source equivalents. Several fields and examples focus on Windows environments, and guidance is often tailored to Windows server behavior, with Linux or non-Windows systems only briefly referenced or omitted.
Recommendations
- Provide Linux/Unix-specific examples alongside Windows examples for fields like SrcHostname, SrcUserId, and SrcUsername.
- Discuss Linux DHCP server logging formats and any normalization considerations, not just Windows-specific quirks (e.g., MAC address formatting).
- When listing possible values or formats (e.g., for SrcDomainType, SrcUsernameType), present Linux/Unix and open-source conventions first or equally, rather than always leading with Windows.
- Include guidance for parsing and normalizing data from common Linux DHCP servers (such as ISC DHCP, Kea) in addition to Windows DHCP.
- Balance the documentation by referencing both Windows and Linux tools, patterns, and environments, ensuring parity in detail and prominence.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-schema-registry-event.md
...ticles/sentinel/normalization-schema-registry-event.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation is heavily Windows-centric, focusing exclusively on Windows Registry events, terminology, and examples. All field descriptions, examples, and references are specific to Windows (e.g., HKEY_LOCAL_MACHINE, C:\Windows paths, Windows SIDs), with no mention of Linux or cross-platform registry/event equivalents. There are no Linux examples, nor is there discussion of how (or if) similar concepts might apply on Linux or other platforms.
Recommendations
- Explicitly state that the schema is Windows-specific, and clarify if there is or is not a Linux equivalent for registry event normalization.
- If cross-platform support is planned or possible, provide guidance or mapping for Linux (or macOS) equivalents, or explain why such mapping is not applicable.
- Where possible, include examples or notes about how similar monitoring or normalization would work on Linux systems (e.g., monitoring configuration file changes, dconf/gsettings, or other OS-specific registries).
- If the schema is intended to be extensible, provide a section on how to handle non-Windows systems or how to extend the schema for other platforms.
- Avoid assuming Windows-only context in field descriptions (e.g., process paths, SIDs) and clarify when a field is only relevant to Windows.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-schema-v1.md
...blob/main/articles/sentinel/normalization-schema-v1.md
High Priority
View Details →
Detected Bias Types
Windows Tools
Windows Examples
Windows First
Summary
The documentation demonstrates a subtle Windows bias, primarily through the use of Windows-centric terminology, examples, and field values. Several example values and field names reference Windows-specific constructs (such as SIDs, 'C:\' file paths, 'WORKGROUP', 'DESKTOP', and 'Microsoft Hyper-V Network Adapter'), and HTTP user agent strings reference Windows OS versions. There is little to no mention of Linux or Unix equivalents, and Windows patterns are presented as the default or only example.
Recommendations
- Include Linux/Unix-specific examples alongside Windows ones, such as file paths ('/var/log/syslog'), device names ('eth0'), and user/group identifiers (UID/GID).
- When referencing fields like User SID or domain names, clarify applicability to non-Windows environments (e.g., mention UIDs for Linux).
- Provide sample values for fields like device names, file paths, and domains that reflect both Windows and Linux conventions.
- Avoid using only Windows-specific terms (e.g., 'WORKGROUP', 'DESKTOP', 'C:\') as examples; alternate or supplement with Linux/Unix equivalents.
- In the 'Data types and formats' and 'Network sessions table schema' sections, explicitly note cross-platform considerations and differences.
- For fields such as 'DvcOutboundInterface', which uses 'Ethernet adapter Ethernet 4' as an example, add a Linux-style example like 'eth1' or 'enp0s3'.
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 demonstrates a Windows-first bias in several areas. In field descriptions and examples, Windows formats (such as SID, domain\username, and Windows session IDs) are consistently listed before Linux or other equivalents. Windows-specific terminology and examples (e.g., C:\Windows\System32\svchost.exe, Contoso\johndow) are prevalent, while Linux examples are present but less prominent and rarely first. Some field descriptions provide detailed guidance for Windows (such as session ID conversion) without equivalent Linux-specific notes. There are no PowerShell command examples or explicit omission of Linux tools, but the overall pattern prioritizes Windows concepts and formats.
Recommendations
- Alternate the order of Windows and Linux examples and formats in field descriptions and tables, or list them alphabetically to avoid implicit prioritization.
- Provide Linux-specific guidance and notes where Windows-specific advice is given (e.g., for session IDs or process paths).
- Include more Linux-centric examples (e.g., /usr/bin/sshd for ActingAppName, Linux UIDs and group names) alongside Windows examples.
- Where normalization is discussed, explicitly mention both Windows and Linux normalization patterns and field names.
- Ensure that all field types and enumerations include Linux and cross-platform values with equal prominence.
- Consider adding a section or examples that show how the schema applies to Linux-only environments.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization.md
...zure-docs/blob/main/articles/sentinel/normalization.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation demonstrates a subtle Windows bias by referencing Windows-specific tools and data sources (e.g., Windows Events, Sysmon, Microsoft Defender for Endpoint) as primary examples when discussing normalized data and analytics. There are no explicit Linux or cross-platform examples, nor are Linux-native tools or event sources mentioned, which may give the impression that ASIM is primarily for Windows environments.
Recommendations
- Include explicit examples of Linux event sources (e.g., auditd, syslog, journald) alongside Windows examples when discussing supported data sources and schemas.
- Mention Linux-native tools and logs (such as Linux audit logs, syslog, or cloud-native sources) in lists and examples to demonstrate cross-platform applicability.
- Provide sample queries or use cases that involve Linux data sources to illustrate parity.
- Ensure that when listing supported sources or schemas, both Windows and Linux examples are presented, ideally alternating or grouping by platform rather than defaulting to Windows-first.
- Add a section or note clarifying ASIM's support for Linux and other non-Windows platforms, including any limitations or special considerations.
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 generally maintains parity between Windows and Linux, especially in the section on setting environment variables, where both platforms are given dedicated tabs and step-by-step instructions. However, there are subtle signs of Windows bias: Windows instructions are presented first, and Windows-specific tools (like the System Properties dialog) are described in more detail and with more UI guidance than their Linux equivalents. The Linux instructions assume more technical familiarity (e.g., editing .bashrc with vim/nano), and there is less explanation of the rationale or context for Linux users. In other sections, Windows-style paths (%userprofile%) are mentioned alongside Linux (~), but Windows terminology and patterns (such as referencing the System Properties dialog) are more prominent. There are no PowerShell-specific code examples, but the overall tone and ordering suggest a slight preference for Windows environments.
Recommendations
- Alternate the order of Windows and Linux instructions in tabbed sections, or present Linux first in some cases to balance exposure.
- Provide equal detail and context for Linux instructions, including screenshots or step-by-step UI guidance where appropriate (e.g., using graphical editors or file managers).
- When mentioning file paths, always provide both Windows and Linux equivalents together, and clarify which is which.
- Include PowerShell and Bash equivalents for any command-line instructions, or clarify when a command is platform-specific.
- Add a brief rationale or context for both Windows and Linux users about why certain steps are necessary, not just for Windows.
- Where possible, use cross-platform language and avoid assuming the user is more familiar with Windows tools or UI.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/powerbi.md
...Docs/azure-docs/blob/main/articles/sentinel/powerbi.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation assumes the use of Power BI Desktop, which is only available for Windows, and does not mention or provide alternatives for Linux or macOS users. All instructions and screenshots are based on the Windows version of Power BI Desktop, and there is no discussion of cross-platform options or workarounds. The prerequisite to install Power BI Desktop from the Microsoft Store further reinforces a Windows-only workflow.
Recommendations
- Acknowledge that Power BI Desktop is only available for Windows and explicitly state this in the prerequisites.
- Provide guidance or links for Linux/macOS users, such as using Power BI service (web) for report creation where possible, or running Power BI Desktop in a Windows VM or via Wine.
- If feasible, include steps for exporting data from Microsoft Sentinel and importing it into Power BI using cross-platform tools (e.g., CSV export and import).
- Mention any limitations or alternative workflows for non-Windows users, and direct them to relevant Microsoft documentation or community solutions.
- Consider including a table comparing platform support for each step, so users on Linux/macOS can quickly see what is and isn't possible.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/notebook-get-started.md
...cs/blob/main/articles/sentinel/notebook-get-started.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by focusing primarily on Microsoft Sentinel usage within Azure and Microsoft Defender portals, both of which are Windows-centric environments. There is a lack of explicit Linux or cross-platform setup instructions or examples, and references to tools and workflows are oriented toward the Microsoft ecosystem. While Linux is mentioned in passing (e.g., 'Linux or Windows hosts'), there are no concrete Linux-specific instructions, examples, or troubleshooting tips. The documentation assumes usage of Azure Machine Learning and does not address local or non-Windows Jupyter environments in detail.
Recommendations
- Add explicit instructions and examples for running the notebook in local Jupyter environments on Linux, including installation steps and troubleshooting tips.
- Provide Linux-specific examples or screenshots where relevant, such as setting up Python environments or configuring MSTICPy on Linux systems.
- Include parity in tool recommendations (e.g., mention Linux package managers like apt or yum for Python installation alongside Anaconda).
- Ensure that references to portals or environments clarify cross-platform compatibility and, where possible, provide alternatives for Linux users.
- Highlight any differences or additional steps required for Linux users, such as file path conventions or permissions.
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
Missing Linux Example
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 and the Event table), and recommending PowerShell and Azure Portal for deployment and management tasks. There are no explicit Linux or cross-platform deployment/test examples, and Linux-specific tools or workflows are not mentioned, even though Microsoft Sentinel supports ingesting logs from Linux sources (e.g., Syslog).
Recommendations
- Provide equivalent Linux-based examples alongside Windows examples, such as using Linux Syslog event types and fields in KQL queries.
- Include instructions for deploying and managing parsers using Linux-native tools (e.g., Azure CLI, Bash scripts) in addition to PowerShell.
- Mention and demonstrate cross-platform or Linux-specific log sources and how to map their fields to ASIM schemas.
- Clarify that the guidance applies to both Windows and Linux data sources, and highlight any differences or additional steps required for Linux environments.
- Add sample parser development and deployment workflows for Linux users, including exporting logs, running tests, and submitting contributions from Linux systems.
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 the BTP client secret, but does not offer equivalent examples for Linux environments (e.g., Bash, Azure CLI, or Python). The script relies on PowerShell and Az modules, which are native to Windows and require extra setup on Linux. No alternative Linux-native automation or command-line instructions are provided, and there is no mention of cross-platform compatibility or guidance for Linux users.
Recommendations
- Provide equivalent automation examples using Bash and Azure CLI, which are commonly used in Linux environments.
- Mention cross-platform options for running the automation, such as using Azure CLI or Python scripts, and provide links or references.
- Clarify whether the PowerShell script can be run on PowerShell Core (pwsh) on Linux, and provide installation/setup instructions if so.
- Wherever scripts or command-line instructions are given, include both Windows (PowerShell) and Linux (Bash/Azure CLI) variants.
- Explicitly state the platform requirements for any provided scripts or tools.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/sap/prerequisites-for-deploying-sap-continuous-threat-monitoring.md
...uisites-for-deploying-sap-continuous-threat-monitoring.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation demonstrates some Windows bias, notably by referencing Windows-specific documentation (such as 'Install Log Analytics agent on Windows computers') and omitting equivalent Linux instructions or links in certain sections. While the main deployment method is Linux-centric (Docker containers on Linux), there are places where Windows is mentioned first or exclusively, and Linux alternatives are not always provided. Additionally, some tool references and navigation instructions assume a Windows environment.
Recommendations
- Where Windows-specific links or instructions are given (e.g., 'Install Log Analytics agent on Windows computers'), provide equivalent Linux links or instructions, or clarify if not applicable.
- Ensure that all navigation paths and examples are platform-neutral or include both Windows and Linux variants.
- If referencing tools or utilities, mention cross-platform or Linux-native alternatives where appropriate.
- Review all sections for implicit Windows-first ordering and adjust to either present Linux first (when more relevant, as in this case) or present both equally.
- Explicitly state when a step or tool is only relevant to Windows, and offer guidance for Linux users.
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 →
Detected Bias Types
Windows First
Powershell Heavy
Missing Linux Example
Summary
The documentation exhibits a subtle Windows bias by referencing the PowerShell New-GUID cmdlet as the primary example for generating GUIDs, without mentioning Linux or cross-platform alternatives. No Linux or cross-platform command-line tools (such as uuidgen) are suggested, and the only explicit tool reference is Windows-specific. There are no examples or instructions tailored for Linux users.
Recommendations
- When suggesting how to generate a GUID, include cross-platform and Linux-native tools (e.g., 'uuidgen' for Linux/macOS, or online generators) alongside PowerShell.
- Rephrase the sentence to mention non-Windows options first or equally (e.g., 'Generate it using uuidgen (Linux/macOS), PowerShell New-GUID (Windows), or any online generator').
- Audit the documentation for other tool or command references to ensure Linux parity and provide equivalent instructions/examples for both platforms.
- Consider adding a short section or note on cross-platform compatibility for any command-line or scripting steps.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/scheduled-rules-overview.md
...lob/main/articles/sentinel/scheduled-rules-overview.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Missing Linux Example
Summary
The documentation page for Microsoft Sentinel scheduled analytics rules demonstrates a Windows bias primarily by referencing PowerShell as the only scripting/automation interface for enabling rules via command line, and by mentioning PowerShell before API in the 'Next steps' section. There are no Linux or cross-platform CLI examples (such as Azure CLI or Bash), and no mention of Linux-native tools or workflows. This may give the impression that only Windows or PowerShell users can automate or script rule management, omitting equivalent Linux-friendly approaches.
Recommendations
- Include Azure CLI examples for exporting, importing, and enabling analytics rules, alongside or before PowerShell examples.
- Explicitly mention that APIs and automation can be accessed from any platform, not just Windows.
- Provide Bash or shell script snippets for common tasks, or reference cross-platform tools.
- Add a note clarifying that PowerShell Core is available cross-platform, or provide links to relevant Linux installation guides.
- Ensure that any automation or scripting guidance is platform-neutral or includes both Windows and Linux options.