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 101-125 of 488 flagged pages
Sentinel
The Advanced Security Information Model (ASIM) Authentication normalization schema reference | Microsoft Docs
...ticles/sentinel/normalization-schema-authentication.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation exhibits a Windows bias in several ways: Windows is mentioned first and most frequently as an example of authentication event sources; examples of application names and hostnames use Windows conventions (e.g., 'C:\Windows\System32\svchost.exe', 'DESKTOP-1282V4D', 'Contoso\DESKTOP-1282V4D'); protocols like NTLM are referenced without mention of Linux/Unix equivalents; and there are no explicit Linux or cross-platform examples provided for fields such as OS, application names, or hostnames. Linux authentication sources, tools, or patterns are not described or exemplified.
Recommendations
- Add explicit Linux and Unix examples alongside Windows ones for fields such as OS (e.g., 'Ubuntu 22.04', '/usr/bin/sshd'), application names (e.g., '/usr/sbin/sshd'), and hostnames (e.g., 'webserver01').
- Mention Linux/Unix authentication protocols (e.g., Kerberos, LDAP, PAM) in addition to NTLM.
- Include references to Linux authentication event sources (e.g., SSH servers, PAM logs, systemd journal) in introductory and example sections.
- Ensure that examples of domain and FQDN formats include Linux/Unix conventions (e.g., 'webserver01.example.com').
- Balance the introductory discussion to mention both Windows and Linux as common authentication event sources.
Create Pull Request
Sentinel
The Advanced Security Information Model (ASIM) DHCP normalization schema reference | Microsoft Docs
...ob/main/articles/sentinel/normalization-schema-dhcp.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 fields and formats (such as TransactionID for Windows DHCP server and Windows domain/hostname formats) and providing examples and notes that are Windows-centric (e.g., MAC address logging quirks in Windows DHCP server, domain type values like 'Windows'). There are no explicit Linux or cross-platform examples, nor are Linux tools or patterns mentioned. Windows terminology and formats are introduced before any mention of Linux or open standards, and Linux-specific guidance is absent.
Recommendations
- Add explicit examples and notes for Linux DHCP servers (such as ISC DHCP, Kea, or dnsmasq), including how fields like TransactionID, MAC address, and hostnames are logged and formatted.
- Include Linux-specific domain types and username formats in relevant fields (e.g., mention typical Linux FQDNs, UID/GID formats, etc.).
- Clarify any differences in field population or normalization between Windows and Linux DHCP servers.
- Provide guidance on parsing and normalizing logs from popular Linux DHCP servers, highlighting any differences from Windows.
- Ensure that examples alternate between Windows and Linux, or provide parallel examples for both platforms.
- Reference open-source Linux DHCP tools and documentation where relevant.
Sentinel
The Advanced Security Information Model (ASIM) Registry Event normalization schema reference | Microsoft Docs
...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 and their normalization. All examples, terminology, and references are specific to Windows (e.g., Registry keys, value types, process paths, user IDs). There are no Linux equivalents or examples, and Windows tools and patterns (such as Sysmon, EDR, and registry key formats) are mentioned exclusively. Even when process IDs are discussed, Linux is only briefly mentioned in a note, with no Linux-specific guidance or examples.
Recommendations
- Explicitly state that the schema is Windows-specific, and clarify its applicability (or lack thereof) to Linux and other platforms.
- If Linux registry-like activity is relevant (e.g., dconf, gsettings, etc.), provide equivalent normalization guidance or examples.
- Add a section comparing Windows Registry events to Linux configuration or system events, explaining differences and possible normalization approaches.
- Where process-related fields are discussed (e.g., process IDs, process names), provide Linux examples alongside Windows ones.
- If the schema is intended to be extended to other platforms, outline how to do so and what fields would differ.
Sentinel
Jupyter notebooks with Microsoft Sentinel hunting capabilities
...cs/azure-docs/blob/main/articles/sentinel/notebooks.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Missing Linux Example
Summary
The documentation page focuses on Jupyter notebooks within Microsoft Sentinel, which is inherently a cloud-based, cross-platform solution. However, there is evidence of Windows bias: PowerShell is mentioned as a management option before Linux alternatives, and there are no explicit Linux or bash examples or references. The documentation assumes use of Azure portal and tools, which are accessible from any OS, but does not provide parity in examples or instructions for Linux users (e.g., bash commands, Linux-specific setup, or troubleshooting).
Recommendations
- Add explicit Linux/bash command examples alongside PowerShell references, especially for role assignments and workspace management.
- Mention and demonstrate use of Linux tools (e.g., Azure CLI in bash, shell scripting) where appropriate.
- Clarify that all features are available cross-platform and provide troubleshooting or setup notes for Linux users.
- Ensure that instructions and examples do not assume a Windows environment by default (e.g., avoid only referencing PowerShell).
- Include links to Linux-specific documentation or community resources for using Jupyter notebooks and Azure tools on Linux.
Sentinel
Microsoft Sentinel user management normalization schema reference | Microsoft Docs
...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: Windows-specific identifiers (SID) and username formats are consistently listed before Linux equivalents (UID), and Windows domain formats are prioritized in examples and field descriptions. Windows tools and conventions (such as domain\username, SIDs, and session ID numeric requirements) are mentioned more frequently and with more detail than Linux equivalents. Linux formats are present but often secondary, with less explanation or example coverage.
Recommendations
- Present Linux and Windows identifiers and formats in parallel, alternating order or giving equal prominence (e.g., 'UID (Linux), SID (Windows)' rather than always 'SID (Windows), UID (Linux)').
- Provide Linux-specific examples for fields where only Windows examples are given (e.g., show a Linux UID and username format alongside Windows SIDs and domain\username).
- Expand explanations for Linux concepts (UID, group names, session IDs) to match the detail given for Windows.
- Where conversion or normalization is discussed (e.g., session IDs), include Linux-specific guidance and examples.
- Add explicit mention of Linux tools and patterns (e.g., reference /etc/passwd, getent, or id command for Linux user IDs) where Windows tools or conventions are described.
- Ensure that recommendations for field normalization and mapping include Linux-first or cross-platform scenarios, not just Windows-centric advice.
Sentinel
Microsoft Sentinel network normalization schema (Legacy version - Public preview)| Microsoft Docs
...blob/main/articles/sentinel/normalization-schema-v1.md
High Priority
View Details →
Detected Bias Types
Windows Tools
Windows First
Windows Examples
Summary
The documentation page exhibits mild Windows bias. Several example values and field names reference Windows-centric concepts, such as file paths (C:\Malicious\ImNotMalicious.exe), file extensions (.exe), user domains (WORKGROUP, DESKTOP), and device types (Ethernet adapter, Microsoft Hyper-V Network Adapter). The HTTP user agent example includes 'Windows NT 10.0', and user IDs reference SIDs, which are Windows-specific. There is little mention of Linux/Unix equivalents or diversity in examples, and Windows terminology appears first or exclusively in several places.
Recommendations
- Include Linux/Unix-centric examples alongside Windows ones, such as file paths (/var/log/malicious.sh), file extensions (.sh, .elf), and device names (eth0, wlan0).
- Provide examples of user domains and IDs relevant to Linux/Unix (e.g., UID, GID, local groups) in addition to Windows SIDs and domains.
- Balance references to Windows tools (e.g., Hyper-V, Ethernet adapter) with Linux/Unix equivalents (e.g., KVM, veth, tun/tap).
- Ensure that examples and terminology are platform-neutral or alternate between Windows and Linux/Unix, rather than defaulting to Windows-first.
- Clarify that the schema is intended for cross-platform use and explicitly mention support for Linux/Unix devices and logs.
Sentinel
Manage access to Microsoft Sentinel data by resource
...s/blob/main/articles/sentinel/resource-context-rbac.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 scenarios that prioritize Windows data and tools. Windows event data is mentioned as the primary example for resource-context RBAC, and Windows administrators are referenced in table-level RBAC scenarios. There is no mention of Linux-specific event types (e.g., Linux audit logs) or Linux administrator use cases. While Syslog and CEF are referenced, these are not presented with the same prominence or detail as Windows examples, and there are no explicit Linux command-line or tool examples.
Recommendations
- Include Linux-specific examples, such as granting access to Linux audit logs or other Linux-centric data sources.
- Provide scenarios for Linux administrators, similar to those given for Windows administrators.
- Add explicit Linux tool usage (e.g., Bash, Linux CLI, or Linux-native log forwarding agents) in configuration and collection examples.
- Ensure parity in example detail and prominence between Windows and Linux data sources and user roles.
- Reference Linux equivalents when mentioning Windows tools or patterns, and avoid presenting Windows examples first unless justified by usage statistics.
Sentinel
Sample Microsoft Sentinel workspace designs
...lob/main/articles/sentinel/sample-workspace-designs.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by consistently listing Windows Security Events and Windows Events as primary log sources, mentioning Windows tools (such as the Azure Monitoring Agent) with explicit reference to Windows VMs, and providing no explicit examples or instructions for Linux VMs or Linux-specific log collection. Syslog and CEF are mentioned, but only in passing and without parity in detail or tooling. There are no Linux-centric examples, nor are Linux collection patterns or agent configurations described.
Recommendations
- Add explicit examples and instructions for collecting logs from Linux VMs, including security and performance data.
- Mention Linux equivalents for log collection agents (e.g., AMA on Linux, OMS agent, or native syslog forwarding).
- Provide Linux-specific log source examples (e.g., /var/log/auth.log, /var/log/syslog) alongside Windows Event Log.
- Ensure that references to log collection tools and patterns are platform-neutral or include both Windows and Linux usage.
- Where agent configuration is discussed, show both Windows and Linux setup steps and considerations.
- List Linux log sources before or alongside Windows sources to avoid 'windows_first' ordering.
Sentinel
Deploy Microsoft Sentinel solution for SAP BTP
.../main/articles/sentinel/sap/deploy-sap-btp-solution.md
High Priority
View Details →
Detected Bias Types
Powershell Heavy
Windows Tools
Missing Linux Example
Windows First
Summary
The documentation page demonstrates a Windows bias by providing only PowerShell scripts for automation and secret rotation, referencing Azure PowerShell modules and commands exclusively, and omitting equivalent Linux/bash examples. The scripting and automation guidance assumes a Windows environment, and there is no mention of cross-platform alternatives or parity for Linux users. Windows-centric tools and patterns are presented without Linux equivalents, and the PowerShell example is given without any bash or CLI alternative.
Recommendations
- Provide equivalent bash or Azure CLI scripts for all PowerShell examples, especially for secret rotation and connector updates.
- Explicitly mention cross-platform compatibility and note which steps or tools work on Linux/macOS.
- Reference Azure CLI and REST API alternatives alongside PowerShell modules, ensuring Linux users have clear guidance.
- Add a section or callouts for Linux users, including installation and usage notes for required tools.
- Ensure screenshots and UI references are not Windows-specific, or provide Linux/macOS alternatives if relevant.
Sentinel
Microsoft Sentinel skill-up training
...docs/blob/main/articles/sentinel/skill-up-resources.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation demonstrates a moderate Windows bias. While it is generally cross-platform in describing Microsoft Sentinel's cloud-native features, there are several instances where Windows tools, terminology, or examples are mentioned before their Linux equivalents, or Linux is omitted. Windows-specific tools and monitoring (such as WEF, Windows Events, and Windows-only agent health solutions) are referenced more prominently, and Linux alternatives are sometimes only mentioned in passing or not at all. There is a lack of explicit Linux/POSIX command-line examples, and some sections (e.g., agent health monitoring) provide Windows solutions first or exclusively.
Recommendations
- Ensure that all examples, especially those involving data collection, agent health, and log ingestion, provide both Windows and Linux (or cross-platform) instructions and examples.
- When referencing tools or features (such as WEF, Sysmon, or agent health), explicitly mention Linux equivalents (e.g., Sysmon for Linux, auditd, rsyslog) and provide links to their documentation.
- Avoid listing Windows tools or procedures before Linux ones unless there is a clear reason; consider grouping by platform or presenting both in parallel.
- Where PowerShell or Windows-specific scripts are referenced, provide Bash or shell script equivalents for Linux users.
- In sections discussing monitoring, troubleshooting, or retention, ensure that Linux-specific guidance is as detailed and discoverable as Windows guidance.
- Review all linked resources and webinars to ensure they are not Windows-centric and, if they are, supplement with Linux-focused resources.
Sentinel
Connect your SAP system to Microsoft Sentinel | Microsoft Sentinel
.../sentinel/sap/deploy-data-connector-agent-container.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Azure Tools Heavy
Summary
The documentation page demonstrates a bias towards Azure and Windows-centric workflows. While the main VM creation example uses Ubuntu Linux, nearly all instructions and examples focus on Azure CLI, Azure Key Vault, and Microsoft Entra ID, with no mention of Linux-specific tools, patterns, or alternative credential management approaches outside Azure. There are no examples for deploying on non-Azure Linux environments (e.g., using native Linux tools or shell scripts), and the documentation assumes Azure as the default platform for identity and secrets management. Windows or Azure portal methods are described before any Linux-native alternatives, and there is no parity in examples for Linux-only environments or non-Azure clouds.
Recommendations
- Add explicit examples for deploying the connector agent on non-Azure Linux VMs, including steps for common Linux distributions (e.g., CentOS, RHEL, Debian) outside Azure.
- Provide credential management alternatives for Linux environments, such as using native Linux secret stores (e.g., HashiCorp Vault, Gnome Keyring, or environment variables) instead of Azure Key Vault.
- Include sample scripts and commands using bash, systemd, and other Linux-native tools for agent deployment and management.
- Offer guidance for integrating with non-Azure identity providers (e.g., LDAP, Kerberos) for authentication, especially for on-premises Linux deployments.
- Present Linux-specific troubleshooting steps and health checks, such as using journalctl, systemctl, and standard Linux networking tools.
- Ensure that Linux and non-Azure cloud deployment instructions are given equal prominence and detail as Azure/Windows-centric methods.
Sentinel
Create Hunting Queries for Microsoft Sentinel Solutions
...n/articles/sentinel/sentinel-hunting-rules-creation.md
High Priority
View Details →
Detected Bias Types
Powershell Heavy
Windows Tools
Windows First
Summary
The documentation page demonstrates Windows bias primarily in the section describing how to generate a GUID for the 'id' attribute. It explicitly references the PowerShell New-GUID cmdlet as a method, mentioning it before generic alternatives (development tools, online generators), and does not provide Linux-specific or cross-platform command-line examples (such as uuidgen for Linux/macOS). No Linux tools or patterns are mentioned for this step, and PowerShell is highlighted as the concrete example. The rest of the documentation is platform-neutral, focusing on KQL, YAML, and Microsoft Sentinel concepts.
Recommendations
- Provide Linux/macOS equivalents for GUID generation, such as the uuidgen command.
- List platform-agnostic methods first (e.g., 'any development tool or online generator'), then provide OS-specific examples for both Windows and Linux/macOS.
- Avoid referencing Windows tools (like PowerShell) exclusively; always offer parity with Linux alternatives.
- Consider adding a table or section with cross-platform command-line examples for common tasks (e.g., GUID generation, file editing).
Sentinel
Import threat intelligence with the upload API
...e-docs/blob/main/articles/sentinel/stix-objects-api.md
High Priority
View Details →
Detected Bias Types
Powershell Heavy
Missing Linux Example
Windows Tools
Summary
The documentation provides a detailed PowerShell sample for calling the upload API, relying on the MSAL.PS module and Windows certificate store paths. There are no equivalent examples or guidance for Linux or cross-platform command-line tools (such as curl, Python, or bash), nor is there mention of Linux-specific authentication or certificate handling. This creates a bias toward Windows environments and PowerShell users, potentially excluding Linux users or those using other scripting languages.
Recommendations
- Add equivalent sample code for Linux environments, such as using curl, Python (requests + MSAL), or bash scripts to acquire tokens and call the API.
- Provide guidance on certificate handling for Linux (e.g., using PEM files, OpenSSL, or environment variables) instead of only referencing the Windows certificate store.
- Mention cross-platform tools (curl, Python, etc.) alongside PowerShell, and clarify that the API can be called from any OS.
- Ensure that authentication steps and token acquisition are described in a platform-neutral way, or provide both Windows and Linux instructions.
- Consider including troubleshooting tips for common Linux-specific issues (e.g., certificate formats, file permissions).
Sentinel
Scheduled analytics rules in Microsoft Sentinel | Microsoft Docs
...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 scheduled analytics rules in Microsoft Sentinel demonstrates a Windows bias primarily in the 'Next steps' section, where automation and rule management are discussed. PowerShell is mentioned explicitly as a method for pushing rules, with no equivalent Linux shell (e.g., Bash, CLI) examples or references. The API and PowerShell are presented as the main automation options, and PowerShell is referenced before any cross-platform alternatives. There are no Linux-specific tools, shell commands, or examples provided throughout the page, and no mention of how Linux users might perform similar tasks. This may make the documentation less accessible or actionable for users on Linux or macOS systems.
Recommendations
- Add examples using Azure CLI (az securityinsights) for rule management and automation, which is cross-platform and works on Linux, macOS, and Windows.
- Include Bash shell script snippets for exporting/importing rules via API, demonstrating curl or wget usage.
- Explicitly mention that PowerShell Core is available on Linux and macOS, and provide installation instructions or links.
- Where PowerShell is referenced, also provide equivalent commands for Azure CLI or REST API usage.
- Review other sections for tool references and ensure parity by including Linux-friendly alternatives (e.g., mention text editors, scripting environments, etc.).
Sentinel
Create Analytics Rules for Microsoft Sentinel Solutions
.../articles/sentinel/sentinel-analytic-rules-creation.md
High Priority
View Details →
Detected Bias Types
Windows Tools
Powershell Heavy
Windows First
Summary
The documentation page exhibits Windows bias primarily in the section describing how to generate a GUID for the 'id' attribute. It explicitly mentions the PowerShell New-GUID cmdlet as a method, without referencing Linux or cross-platform alternatives. No Linux shell or tool examples are provided, and the Windows/PowerShell method is mentioned first and exclusively. The rest of the documentation is platform-neutral, focusing on YAML, KQL, and Microsoft Sentinel concepts.
Recommendations
- Include Linux and cross-platform methods for generating a GUID, such as 'uuidgen' (available on most Linux distributions and macOS) or Python's uuid module.
- Present platform-agnostic or cross-platform options before or alongside Windows/PowerShell examples.
- Add explicit examples for Linux/macOS users, e.g., 'Run uuidgen in your terminal to generate a GUID.'
- Where possible, avoid referencing platform-specific tools unless necessary, or always provide equivalent alternatives.
Sentinel
Create Playbooks for Microsoft Sentinel Solutions
...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 page demonstrates a significant Windows bias in its instructions for generating and sanitizing ARM templates for playbooks. All automation steps rely exclusively on PowerShell scripts, with explicit references to Windows PowerShell, Visual Studio Code, and commands like Set-ExecutionPolicy that are specific to Windows environments. There are no equivalent examples or instructions for Linux or macOS users, nor are alternative tools (such as Bash, Azure CLI, or cross-platform scripting) mentioned. The documentation assumes a Windows-first workflow and omits guidance for non-Windows platforms.
Recommendations
- Provide Linux and macOS equivalents for PowerShell-based steps, such as using Azure CLI, Bash scripts, or PowerShell Core on non-Windows platforms.
- Clarify which steps are cross-platform and which are Windows-specific; where possible, use cross-platform tools and document their usage.
- Include explicit instructions for running the ARM template generator script on Linux and macOS, including prerequisites and any required changes (e.g., script execution policies, authentication methods).
- Mention alternative editors (such as VS Code on Linux/macOS, nano, vim) instead of only Visual Studio Code and Windows PowerShell.
- Add notes or links to resources for users who do not have access to Windows environments, ensuring full parity in the documentation.
Sentinel
Microsoft Sentinel User and Entity Behavior Analytics (UEBA) reference
...ure-docs/blob/main/articles/sentinel/ueba-reference.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation page demonstrates a Windows bias primarily through its focus on Windows-centric data sources (e.g., Windows Security Events, Windows Forwarded Events), terminology (Active Directory, SID, local admin), and device enrichments (Windows device family, Windows 10 OS). There are no Linux-specific log sources, device types, or examples, and Linux equivalents (such as Linux audit logs, Linux device families, or Linux user attributes) are not mentioned or supported in the enrichment tables or schema. The documentation assumes a Microsoft/Windows environment for both cloud and on-premises scenarios, with no parity for Linux or other non-Windows platforms.
Recommendations
- Add Linux-specific data sources (e.g., Linux audit logs, syslog, SSH authentication logs) to the UEBA data sources table.
- Include Linux device families and operating systems in the DevicesInsights enrichment field and provide sample values (e.g., Ubuntu, CentOS, Red Hat).
- Document Linux user and device attributes in the enrichment tables (e.g., UID, GID, /etc/passwd fields, sudoers status).
- Provide examples and schema fields relevant to Linux environments, such as Linux group membership, PAM authentication events, and Linux-specific threat indicators.
- Clarify which features and enrichments are available or not available for Linux endpoints, and provide guidance for integrating Linux data into UEBA workflows.
- Ensure parity in terminology and examples, mentioning Linux alongside Windows wherever applicable (e.g., 'local admin' vs. 'sudo/root user').
Sentinel
Use matching analytics to detect threats
...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 solutions and connectors (e.g., Windows DNS, Windows Firewall) before or more prominently than Linux equivalents. While Syslog and CEF are mentioned, there are no explicit Linux-focused examples, and no Linux-specific tools or triage steps are provided. The configuration and triage instructions are generic and do not address platform-specific differences, especially for Linux environments.
Recommendations
- Add explicit Linux-focused examples, such as configuring Syslog or CEF connectors on popular Linux distributions.
- Include Linux-specific data sources (e.g., Linux audit logs, iptables logs) and describe how to connect and analyze them.
- Provide parity in troubleshooting and triage steps for incidents generated from Linux sources.
- Mention Linux tools and patterns (e.g., journalctl, rsyslog, auditd) alongside Windows tools.
- Ensure that solution and connector tables list Linux options with equal prominence and detail as Windows options.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/anomalies-reference.md
...ocs/blob/main/articles/sentinel/anomalies-reference.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation page exhibits a Windows bias by focusing heavily on Windows-specific data sources (e.g., Windows Security logs, Event IDs 4624/4625) for anomaly detection, especially in the machine learning-based anomalies section. There is a lack of equivalent examples or references for Linux systems (such as Linux audit logs or syslog), and Windows tools and patterns (like PowerShell and Windows event IDs) are mentioned exclusively or before any Linux alternatives. No Linux-specific anomaly rules, log sources, or event patterns are discussed, and no Linux-centric guidance is provided.
Recommendations
- Add Linux-specific anomaly detection examples, such as using Linux audit logs, syslog, or SSH authentication logs.
- Include equivalent Linux event patterns (e.g., failed SSH logins, suspicious sudo activity) alongside Windows event IDs.
- Mention Linux tools and log sources (e.g., /var/log/auth.log, auditd, journald) in anomaly rule descriptions.
- Provide guidance or links for configuring Linux log collection and anomaly detection in Sentinel.
- Ensure parity in documentation by presenting both Windows and Linux scenarios for common attack techniques (e.g., brute force, privilege escalation, code execution).
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 bias toward Windows environments by referencing PowerShell deployment scripts as the primary method for customizing deployments, without mentioning Linux-compatible alternatives (such as Bash or cross-platform CLI). There are no examples or instructions for Linux users, and Windows-centric tools (PowerShell) are referenced exclusively for deployment customization. No Linux-first or Linux-equivalent patterns are described.
Recommendations
- Provide equivalent Bash or Azure CLI examples for deployment customization, alongside PowerShell.
- Explicitly mention cross-platform compatibility for deployment scripts and workflows.
- Reference Linux tools and patterns (e.g., Bash scripts, shell environments) where PowerShell is mentioned.
- Include step-by-step instructions or examples for Linux users to achieve the same tasks.
- Clarify whether the deployment scripts and workflows are supported on Linux/macOS environments.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-microsoft-365-defender.md
...in/articles/sentinel/connect-microsoft-365-defender.md
High Priority
View Details →
Detected Bias Types
Windows Tools
Windows First
Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by focusing exclusively on Microsoft Defender products, which are primarily Windows-centric. The event tables and integration steps reference Windows-specific concepts (e.g., registry events, Windows Defender Antivirus, Active Directory), and there is no mention of Linux equivalents, Linux security tools, or how to stream data from Linux endpoints. All examples and instructions assume a Windows environment, with no guidance for Linux users or cross-platform scenarios.
Recommendations
- Include explicit instructions or references for integrating Linux endpoints with Microsoft Sentinel, such as using the Microsoft Sentinel Linux agent or other supported connectors.
- Provide examples of ingesting security data from Linux systems (e.g., syslog, auditd, or other Linux security logs) alongside Windows Defender data.
- Mention Linux-specific tables or connectors, if available, and clarify how Linux alerts/incidents can be streamed to Sentinel.
- Add parity in documentation by listing both Windows and Linux onboarding steps, tools, and troubleshooting guidance.
- Highlight cross-platform capabilities of Microsoft Sentinel, if applicable, to avoid the impression that it is Windows-only.
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 heavily focused on Windows DNS Events via the AMA connector, with all examples, field mappings, and instructions referencing Windows DNS servers and Windows-specific tools. There is no mention of Linux DNS servers, Linux equivalents, or cross-platform applicability, which may exclude users operating non-Windows environments.
Recommendations
- Include examples and instructions for collecting and normalizing DNS logs from Linux-based DNS servers (e.g., BIND, Unbound, dnsmasq).
- Mention whether the AMA connector or similar connectors support Linux DNS servers, and provide guidance for setup if available.
- Add field mapping tables for common Linux DNS log formats and show how they can be normalized to the ASIM schema.
- Clarify in the introduction whether the solution is Windows-only or cross-platform, and provide links to Linux-specific documentation if available.
- If Linux support is not available, explicitly state this limitation and suggest alternative approaches for Linux environments.
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 First
Summary
The documentation provides only a PowerShell script example for triggering the SAP prerequisites checker iflow, which is specific to Windows environments. There are no equivalent examples for Linux or cross-platform tools (e.g., curl, bash), and the Windows-centric approach is presented first and exclusively.
Recommendations
- Add a Linux/bash example using curl or wget to demonstrate how to trigger the iflow from a REST client on Linux systems.
- Include cross-platform REST client examples (e.g., Python requests, Postman) to ensure parity for users on non-Windows platforms.
- Explicitly state that the prerequisites checker can be triggered from any REST client, and provide links or references to platform-agnostic tools.
- Reorder or parallelize examples so that Windows and Linux approaches are presented together, avoiding implicit prioritization of Windows.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-schema-network.md
...main/articles/sentinel/normalization-schema-network.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Windows Examples
Summary
The documentation demonstrates a mild Windows bias. Windows-specific terminology, examples, and formats are presented before or more prominently than Linux equivalents. Hostname and FQDN examples use Windows formats (e.g., 'Contoso\DESKTOP-1282V4D'), process names use Windows paths (e.g., 'C:\Windows\explorer.exe'), and user/domain types reference Windows conventions. Linux alternatives are mentioned only in passing, and examples for Linux formats are missing.
Recommendations
- Add Linux-specific examples for fields such as FQDN, process names, and user/domain types (e.g., '/usr/bin/sshd', 'ubuntu.local', 'UID/GID').
- Present Windows and Linux formats side-by-side in tables and examples to ensure parity.
- Clarify normalization guidelines for both Windows and Linux systems, especially for fields like process IDs, domain types, and usernames.
- Include explicit Linux hostname/domain examples (e.g., 'server1.example.com') and process paths.
- Reference Linux tools and conventions where relevant (e.g., systemd, /etc/hostname, /proc).
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
Missing Linux Example
Windows Tools
Summary
The documentation is heavily focused on Windows Registry events, with all examples, terminology, and references specific to Windows. Windows tools and concepts (e.g., Sysmon, Registry keys, IFEO, HKEY_LOCAL_MACHINE) are mentioned exclusively, and there are no Linux equivalents or cross-platform considerations. Linux is only briefly mentioned in the context of process IDs, with no examples or guidance for Linux systems.
Recommendations
- Explicitly state that the schema is Windows-specific, and clarify cross-platform limitations.
- If Linux or macOS equivalents exist (e.g., dconf, gsettings, /etc configuration files), mention them and provide guidance on how similar events could be normalized or mapped.
- Add examples or notes for Linux systems where relevant fields (such as process IDs) might differ, or clarify that certain fields are not applicable.
- Provide a comparison table or section outlining how registry-like activity is handled on non-Windows platforms, even if only to state that such events are not supported.
- Ensure that references to tools (e.g., Sysmon, IFEO) are clearly marked as Windows-only, and suggest analogous monitoring approaches for Linux if possible.