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 426-450 of 488 flagged pages
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/watchlist-schemas.md
...-docs/blob/main/articles/sentinel/watchlist-schemas.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation repeatedly references CSV formatting differences between files created in Microsoft Excel and those created in a 'text editor', but does not mention Linux-specific tools or editors (such as LibreOffice, nano, vim, or Linux command-line CSV creation). Microsoft Excel is mentioned by name, while the alternative is generically described, implicitly centering the Windows/Office experience. No Linux or cross-platform tools are named, and no Linux-specific examples are provided.
Recommendations
- Explicitly mention cross-platform and Linux-friendly tools for creating CSV files, such as LibreOffice Calc, Google Sheets, or command-line utilities (e.g., csvkit, awk, sed).
- Provide examples of CSV formatting/output from Linux tools or editors (e.g., show how to create a compatible CSV using nano, vim, or command-line tools).
- When describing CSV differences, avoid centering Microsoft Excel; instead, use neutral language or list multiple tools (e.g., 'for CSV files created in Microsoft Excel, LibreOffice Calc, or other spreadsheet editors...').
- Consider adding a section or note on ensuring CSV compatibility across different operating systems and editors, including common pitfalls on Linux.
- If relevant, provide sample commands for generating or validating CSVs on Linux (e.g., using cat, echo, or csvkit).
Create Pull Request
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/create-codeless-connector.md
...ob/main/articles/sentinel/create-codeless-connector.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Summary
The documentation demonstrates a mild Windows bias, particularly in the 'Testing APIs' section, where Windows-centric tools (Visual Studio Code, PowerShell Invoke-RestMethod, Microsoft Edge Network Console) are listed before cross-platform or Linux-native tools (Bruno, curl). PowerShell is specifically highlighted, and no Linux shell or CLI examples (such as bash with curl or httpie) are provided. There are no explicit Linux examples or references to Linux-native tools or workflows elsewhere in the document.
Recommendations
- List cross-platform and Linux-native tools (such as curl, httpie, Postman, or Bruno) before or alongside Windows-specific tools in the 'Testing APIs' section.
- Provide example API calls using both PowerShell and bash/curl to ensure parity for Linux users.
- Mention that Visual Studio Code and Edge are available cross-platform, or suggest alternative Linux editors (like Vim or nano) for editing JSON/ARM templates.
- Include explicit instructions or notes for Linux/macOS users where file paths, shell commands, or environment differences may be relevant.
- Where PowerShell is referenced, add equivalent bash or shell command examples to ensure inclusivity.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/automation/authenticate-playbooks-to-sentinel.md
...tinel/automation/authenticate-playbooks-to-sentinel.md
Medium Priority
View Details →
Detected Bias Types
Missing Linux Example
Windows Tools
Summary
The documentation exclusively describes authentication steps using the Azure Portal UI and Azure Logic Apps designer, both of which are web-based and platform-agnostic, but does not provide any command-line examples. There are no references to Windows-specific tools or PowerShell, but there is also a complete absence of Linux (or cross-platform) CLI examples (such as Azure CLI or REST API), which are commonly used in Linux environments. This omission may disadvantage Linux users or those who prefer automation via CLI or scripting.
Recommendations
- Add equivalent Azure CLI commands for all authentication and role assignment steps, showing how to enable managed identity, assign roles, and create connections programmatically.
- Include REST API examples for advanced users or automation scenarios, which are platform-neutral.
- Explicitly mention that all steps can be performed on any OS via the Azure Portal, but provide links or examples for CLI-based workflows to ensure Linux parity.
- If screenshots or UI steps are shown, consider adding CLI/script snippets alongside them for each major action.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/api-dcr-reference.md
...-docs/blob/main/articles/sentinel/api-dcr-reference.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation provides examples for creating Data Collection Rules (DCRs) and their associations, with a focus on API requests and JSON payloads. While the Syslog/CEF example explicitly sets 'kind': 'Linux', the custom log example uses a Windows file path ('C:\Server\bin\log\Apache24\logs\*.log') in the response, and does not provide a Linux file path equivalent. There are no PowerShell or Windows tool-specific commands, but the only concrete file path example is Windows-style, and Linux patterns are not shown. This may confuse or exclude Linux users, especially since custom log collection is a common Linux scenario.
Recommendations
- For every example using a Windows file path, provide a Linux equivalent (e.g., '/var/log/apache2/*.log').
- Explicitly mention both Windows and Linux file path conventions in the documentation.
- If the DCRs support both OS types, clarify any OS-specific requirements or differences.
- Add a note or table summarizing path syntax differences between platforms.
- Ensure that sample payloads and responses are balanced between Windows and Linux scenarios.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/cisco-ftd-firewall.md
...docs/blob/main/articles/sentinel/cisco-ftd-firewall.md
Medium Priority
View Details →
Detected Bias Types
Missing Linux Example
Windows First
Summary
The documentation does not provide explicit examples or instructions for either Windows or Linux, but it also does not mention Linux at all, nor does it clarify whether the connectors or eStreamer client can be run on Linux systems. The absence of Linux-specific guidance or parity in examples may lead to confusion for Linux users, especially since syslog and CEF are commonly associated with Linux environments.
Recommendations
- Explicitly state the supported operating systems (Windows, Linux) for each connector and the eStreamer client.
- Provide installation and configuration examples for both Windows and Linux environments, especially for the CEF via AMA connector and the eStreamer client.
- If the connectors or tools are cross-platform, clarify any OS-specific steps or requirements.
- Include links to Linux-specific documentation or troubleshooting guides where relevant.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/business-applications/power-platform-solution-security-content.md
...plications/power-platform-solution-security-content.md
Medium Priority
View Details →
Detected Bias Types
Windows Tools
Missing Linux Example
Summary
The documentation is heavily focused on Microsoft cloud services and tools (e.g., Dataverse, Power Platform, SharePoint, Microsoft Entra, Office 365, Microsoft Sentinel, Microsoft Teams, Outlook), with all examples, playbooks, and integrations referencing Microsoft-centric or Windows ecosystem products. There are no references to Linux, Linux-based tools, or cross-platform command-line examples. No PowerShell or CMD examples are present, but the entire workflow assumes use of Microsoft cloud and endpoint infrastructure, which is typically Windows-centric. There is a lack of parity for organizations or analysts operating in Linux environments.
Recommendations
- Add explicit notes on cross-platform compatibility for Microsoft Sentinel and Power Platform analytics, including any Linux support or limitations.
- Provide examples or guidance for integrating non-Windows endpoints (e.g., Linux servers, macOS devices) with Microsoft Sentinel, especially for USB exfiltration or device monitoring scenarios.
- Include references or links to Linux-based tools or agents that can send relevant logs (e.g., syslog, auditd) to Microsoft Sentinel, and describe how to configure these.
- Clarify if any playbooks or automations can be triggered or executed from non-Windows environments, and provide examples if possible.
- Where possible, mention open standards or APIs that can be used from any OS, not just Microsoft tools.
- If certain features are Windows-only, explicitly state this to set expectations for Linux users.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-mdti-data-connector.md
.../main/articles/sentinel/connect-mdti-data-connector.md
Medium Priority
View Details →
Detected Bias Types
Windows Tools
Missing Linux Example
Summary
The documentation exclusively references Microsoft portals (Azure portal, Defender portal) and GUI-based workflows, which are inherently Windows-centric. There are no command-line examples (such as PowerShell or CLI), but also no mention of Linux tools, command-line interfaces, or cross-platform automation. The documentation assumes users interact with Microsoft Sentinel through web portals, which are most commonly accessed from Windows environments. There are no Linux-specific instructions or parity examples.
Recommendations
- Add instructions or examples for enabling the data connector using cross-platform tools such as Azure CLI or REST API, which can be run on Linux, macOS, and Windows.
- Explicitly mention that the portals can be accessed from any OS with a supported browser, to clarify cross-platform compatibility.
- If automation is possible, provide sample scripts in both PowerShell and Bash (or Python), showing how to enable the connector programmatically.
- Include troubleshooting or verification steps that can be performed from Linux environments, such as querying logs using Azure CLI.
- Where screenshots or UI steps are shown, consider providing CLI equivalents or links to relevant API documentation.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-azure-stack.md
...ocs/blob/main/articles/sentinel/connect-azure-stack.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation page demonstrates a Windows-first bias by referencing Windows-specific guidance before Linux equivalents and omitting detailed Linux onboarding instructions. The only explicit installation reference is for Windows, while Linux is only mentioned in the context of troubleshooting, not onboarding. This may make it harder for Linux users to follow the onboarding process.
Recommendations
- Provide explicit, step-by-step onboarding instructions for Linux virtual machines, paralleling the Windows guidance.
- Include direct links to both Windows and Linux agent installation/configuration documentation in the onboarding steps, not just in troubleshooting.
- Ensure that examples and references to VM creation, extension installation, and agent configuration are presented for both Windows and Linux, ideally side-by-side or in parallel sections.
- Avoid placing Windows instructions or links before Linux equivalents unless there is a clear technical reason.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-microsoft-purview.md
...ob/main/articles/sentinel/connect-microsoft-purview.md
Medium Priority
View Details →
Detected Bias Types
Windows Tools
Missing Linux Example
Summary
The documentation page demonstrates a bias toward Windows environments by exclusively referencing Microsoft-centric tools (Azure portal, Microsoft Sentinel, Office Management API, Kusto Query Language) and workflows. There are no examples or instructions for Linux users, nor is there any mention of cross-platform command-line alternatives or compatibility considerations for non-Windows environments.
Recommendations
- Include explicit statements about platform compatibility (e.g., whether the Azure portal and Microsoft Sentinel can be accessed and configured from Linux systems or via cross-platform CLI tools).
- Provide examples using the Azure CLI or PowerShell Core (which is cross-platform), and clarify if these steps can be performed from Linux or macOS.
- Mention any Linux-specific considerations, such as required dependencies or differences in accessing the Azure portal or Microsoft 365 services.
- If all steps are web-based and platform-agnostic, explicitly state this to reassure non-Windows users.
- Add troubleshooting or FAQ sections for users on Linux or macOS, especially if there are known limitations or workarounds.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-microsoft-365-defender.md
...in/articles/sentinel/connect-microsoft-365-defender.md
Medium Priority
View Details →
Detected Bias Types
Windows Tools
Missing Linux Example
Summary
The documentation is heavily oriented toward Microsoft and Windows-centric environments, referencing tools and concepts such as Active Directory, Windows Defender, and registry events, with no mention of Linux equivalents or guidance for non-Windows environments. There are no examples or instructions for Linux-based systems, nor is there any discussion of cross-platform considerations.
Recommendations
- Include explicit guidance or notes for organizations running Linux endpoints, such as how to ingest Linux security events into Sentinel.
- Provide examples or references for integrating non-Windows data sources (e.g., syslog, auditd, Linux authentication logs) into Microsoft Sentinel.
- Clarify which features or connectors are Windows-specific and which are cross-platform, and provide parity where possible.
- Add documentation or links for onboarding Linux servers to Microsoft Defender for Endpoint and how their data appears in Sentinel.
- Balance event table descriptions by mentioning Linux event types or noting when a table is Windows-only.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-threat-intelligence-taxii.md
...articles/sentinel/connect-threat-intelligence-taxii.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation demonstrates a mild Windows bias by referencing the Azure and Defender portals (which are primarily accessed via web browsers on Windows environments) and by not providing any Linux-specific instructions or examples. The only command-line tool mentioned is cURL, which is cross-platform, but there are no PowerShell or Windows-specific tools referenced. However, there are also no Linux-specific examples or guidance, such as using Linux-based TAXII clients or command-line integration patterns. The documentation assumes use of the Microsoft Sentinel web interface and omits parity for Linux CLI or automation scenarios.
Recommendations
- Add examples or references for connecting to TAXII feeds using Linux command-line tools (e.g., using curl, httpie, or open-source TAXII clients like cabby or medallion).
- Include automation examples for both Windows (PowerShell) and Linux (bash) environments, especially for tasks like querying the discovery endpoint or testing connectivity.
- Explicitly mention that the steps are platform-agnostic where applicable, or provide notes for Linux users if there are any differences.
- Reference open-source TAXII clients and libraries that are commonly used on Linux, and provide links or example commands.
- If screenshots or UI instructions are platform-specific, clarify their applicability or provide Linux desktop equivalents if relevant.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/data-transformation.md
...ocs/blob/main/articles/sentinel/data-transformation.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Summary
The documentation page demonstrates a mild Windows bias by listing Windows-based data sources and connectors (such as 'Windows Security Events via AMA' and 'Windows Forwarded Events') before Linux equivalents in the data connector table. Additionally, the only explicit OS-specific links in the connector table point to Windows-based documentation (e.g., 'connect-services-windows-based.md'), while Linux or cross-platform connectors (such as Syslog or CEF) are not given equal prominence or dedicated links. There are no explicit Linux command-line or tool examples, and no mention of Linux-specific ingestion scenarios or tools.
Recommendations
- Provide equal prominence to Linux-based data sources and connectors (e.g., Syslog, Linux audit logs) in tables and lists, including dedicated documentation links where available.
- Include explicit examples or references for Linux ingestion scenarios, such as configuring data collection from Linux servers using the Azure Monitor Agent.
- Avoid listing Windows connectors or tools before Linux equivalents; instead, group by function or provide parallel examples for both platforms.
- Where possible, add cross-platform or Linux-specific sample scenarios and walkthroughs, ensuring Linux users can follow along without ambiguity.
- Review connector documentation links to ensure both Windows and Linux ingestion paths are equally discoverable.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/migration-qradar-historical-data.md
.../articles/sentinel/migration-qradar-historical-data.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation refers to 'open a command prompt' and 'download the results or returned data from the JSON file to a folder on the current system' without specifying the operating system, but the phrase 'command prompt' is commonly associated with Windows. No explicit Linux or macOS terminal instructions or examples are provided, and there is no mention of shell differences, file path conventions, or environment-specific considerations. All command-line examples use curl, which is cross-platform, but the lack of Linux/macOS context or terminology suggests a subtle Windows-first bias.
Recommendations
- Replace or supplement 'open a command prompt' with 'open a terminal or command prompt', and clarify that the instructions apply to Windows, Linux, and macOS.
- Provide explicit examples or notes for running the curl commands on Linux/macOS terminals, including any differences in authentication or file path syntax.
- Mention that curl is available by default on most Linux/macOS systems, but may need to be installed separately on Windows.
- Add screenshots or references to both Windows and Linux/macOS environments to reinforce cross-platform applicability.
- Where file paths are referenced (e.g., <enter_path_to_file>.json), clarify the syntax for both Windows (C:\path\to\file.json) and Linux/macOS (/path/to/file.json).
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/monitor-your-data.md
...-docs/blob/main/articles/sentinel/monitor-your-data.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Summary
The documentation demonstrates a mild Windows bias by referencing Windows-specific data sources (such as the SecurityEvent table from Windows) as the primary example in sample queries, and by mentioning Windows-centric tools and terminology before their cross-platform or Linux equivalents. There are no Linux-specific examples or explicit mention of Linux data sources, and the documentation does not provide parity in illustrating how Linux-based logs or events can be visualized in workbooks.
Recommendations
- Include sample queries that use Linux data sources (e.g., Syslog, LinuxAuditLog) alongside or instead of Windows SecurityEvent.
- When providing examples, alternate between Windows and Linux sources, or provide both to ensure parity.
- Explicitly mention that workbooks can visualize data from both Windows and Linux sources, and provide guidance or links for Linux log integration.
- Add screenshots or walkthroughs that show Linux data sources being selected and visualized in workbooks.
- Review terminology to ensure that Windows-specific terms are not presented as the default or only option.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-schema-audit.md
...b/main/articles/sentinel/normalization-schema-audit.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Summary
The documentation page demonstrates subtle Windows bias primarily through the use of Windows-centric terminology, examples, and field values. Hostname and domain examples (e.g., 'DESKTOP-1282V4D', 'Contoso\DESKTOP-1282V4D') are in Windows format, and fields such as 'ActorUsernameType' use 'Windows' as an example value. Application paths (e.g., 'C:\Windows\System32\svchost.exe') are Windows-specific. There are no equivalent Linux or cross-platform examples, and the documentation does not mention or illustrate Linux/Unix tools, naming conventions, or user/domain formats.
Recommendations
- Provide Linux/Unix examples alongside Windows ones, such as using hostnames like 'ubuntu-server', domain formats like 'example.com', and file paths like '/usr/bin/sshd'.
- When illustrating field values (e.g., ActorUsernameType, TargetFQDN), include both Windows and Linux/Unix representations.
- Clarify that the schema is platform-agnostic and explicitly mention support for Linux/Unix systems where applicable.
- Avoid using only Windows-specific application names or paths; include cross-platform or Linux-native applications and services in examples.
- Where domain or username formats are discussed, show both Windows (DOMAIN\user) and Linux (user@example.com or user@hostname) formats.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/offboard.md
...ocs/azure-docs/blob/main/articles/sentinel/offboard.md
Medium Priority
View Details →
Detected Bias Types
Missing Linux Example
Windows First
Summary
The documentation page exclusively describes GUI-based removal of Microsoft Sentinel via the Azure and Defender portals, with no mention of command-line or scripting options. There are no examples or instructions for Linux users (e.g., using Azure CLI, Bash, or cross-platform tools), and the workflow assumes a portal-based (often Windows-centric) approach. The absence of Linux or cross-platform command-line instructions may disadvantage users who prefer or require non-Windows environments.
Recommendations
- Add instructions for removing Microsoft Sentinel using Azure CLI, which is cross-platform and works on Linux, macOS, and Windows.
- Include Bash and PowerShell script examples for automating the removal process.
- Explicitly mention that the portal-based instructions apply equally to users on any OS, or clarify any OS-specific requirements.
- Provide links to relevant Azure CLI documentation for resource and workspace management.
- Ensure that any screenshots or UI references are supplemented with equivalent command-line steps for parity.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/sample-workspace-designs.md
...lob/main/articles/sentinel/sample-workspace-designs.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation repeatedly references 'Windows Security Events' and 'Windows Events' as primary examples of log sources, with no mention of Linux equivalents (such as Linux audit logs or syslog from Linux VMs) in the context of VM log collection. The only mention of syslog is as a network device/on-premises source, not as a core VM workload. The log collection agent (Azure Monitoring Agent, AMA) is discussed only in the context of Windows VMs, with no explicit mention of Linux VM support or examples. This creates a subtle Windows bias, as Linux scenarios are not equally represented.
Recommendations
- Explicitly mention Linux VMs as supported sources for log collection, alongside Windows VMs, in all relevant sections.
- Provide examples of collecting Linux audit logs and syslog from Linux VMs, not just from network devices.
- When describing the Azure Monitoring Agent (AMA), clarify that it supports both Windows and Linux, and provide example configurations for both platforms.
- In lists of data sources, include Linux-specific logs (e.g., /var/log/auth.log, /var/log/secure, auditd) where appropriate.
- Balance the mention/order of Windows and Linux examples to avoid the impression that Windows is the default or only supported platform.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/watchlist-schemas.md
...-docs/blob/main/articles/sentinel/watchlist-schemas.md
Medium Priority
View Details →
Detected Bias Types
Windows Tools
Missing Linux Example
Summary
The documentation repeatedly references Microsoft Excel as the tool for creating CSV files, and provides separate syntax examples for CSVs created in Excel versus those created in a 'text editor'. There is no mention of Linux-native tools (such as LibreOffice Calc, csvkit, or command-line utilities) or explicit Linux examples. The documentation implicitly assumes a Windows-centric workflow for CSV creation and editing.
Recommendations
- Include explicit examples using Linux-native tools for CSV creation and editing, such as LibreOffice Calc, csvkit, or command-line editors (vim, nano).
- Clarify that 'text editor' can refer to editors on any platform, and provide examples using Linux command-line tools (e.g., echo, cat, awk) to generate CSVs.
- Mention cross-platform CSV editors and note any differences in CSV formatting or quoting conventions between Windows (Excel), macOS, and Linux tools.
- Add a section or note on verifying CSV compatibility across different operating systems and tools.
Sentinel
The Advanced Security Information Model (ASIM) Authentication normalization schema reference | Microsoft Docs
...ticles/sentinel/normalization-schema-authentication.md
Low Priority
View Details →
Detected Bias Types
Windows First
Summary
The documentation references Windows as an example OS in several places (e.g., 'Windows sends several authentication events'), and Windows-style values (such as domain\hostname formats and SIDs) are used in example field values. However, the schema itself is designed to be cross-platform, supporting Linux, macOS, cloud, and third-party sources. No examples or patterns are exclusively Windows, and Linux/macOS equivalents are not omitted, but Windows is often mentioned first or as the primary example.
Recommendations
- Include Linux/macOS examples alongside Windows in field value examples (e.g., show a Linux hostname, a Linux user, or a Linux authentication protocol such as SSH).
- When describing formats (e.g., FQDN), clarify support for Linux/macOS conventions, not just Windows domain\hostname.
- In introductory text, mention that authentication events can come from Linux, macOS, and network devices, not just Windows.
- Balance examples so that Windows is not always the first or only example given.
Sentinel
The Advanced Security Information Model (ASIM) DHCP normalization schema reference | Microsoft Docs
...ob/main/articles/sentinel/normalization-schema-dhcp.md
Low Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Summary
The documentation for the ASIM DHCP normalization schema is generally platform-neutral, but there are minor signs of Windows bias. Windows-specific terminology and examples (such as referencing the Windows DHCP server and its logging format, and using Windows domain/hostname formats) are mentioned before or more prominently than Linux equivalents. There are no Linux-specific examples or clarifications about non-Windows DHCP servers, and the only concrete example of a hostname uses a Windows-style name.
Recommendations
- Add examples or notes for Linux-based DHCP servers (e.g., ISC DHCP, Kea) and their log formats.
- Clarify how the schema applies to non-Windows DHCP implementations, especially regarding MAC address formatting and session identifiers.
- Provide sample hostnames and domain formats from Linux/Unix environments alongside Windows examples.
- Explicitly state that the schema is designed to be source-agnostic and mention common Linux DHCP server fields where relevant.
Sentinel
The Advanced Security Information Model (ASIM) File Event normalization schema reference| Microsoft Docs
...n/articles/sentinel/normalization-schema-file-event.md
Low Priority
View Details →
Detected Bias Types
Windows First
Summary
The documentation presents Windows examples before Linux equivalents in several places, such as in the 'Schema overview' and 'Path structure' sections. For instance, the example for file renaming uses 'Windows File Explorer' and Windows-style paths are shown first in tables. However, Linux/Unix paths and concepts are also included, and there are no sections that are Windows-only or missing Linux examples entirely.
Recommendations
- Alternate the order of examples so that Linux/Unix paths and tools are shown first in some sections.
- Provide parallel examples for both Windows and Linux/Unix when demonstrating concepts (e.g., file operations, process names).
- Explicitly mention Linux/Unix tools or processes in narrative examples, not just in tables.
- Clarify that the schema is designed to support both Windows and Linux/Unix systems equally.
Sentinel
Microsoft Sentinel user management normalization schema reference | Microsoft Docs
...icles/sentinel/normalization-schema-user-management.md
Low Priority
View Details →
Detected Bias Types
Windows First
Summary
The documentation provides normalization schema details for user management activities in Microsoft Sentinel, supporting both Windows and Linux systems. However, there is a minor bias in the ordering and example formats: Windows identifiers (SID, domain\username) are consistently listed before Linux equivalents (UID, simple username), and Windows formats are shown first in field priority lists. No Windows-only tools, commands, or PowerShell examples are present, and Linux is included in all relevant places.
Recommendations
- Alternate the order of Windows and Linux examples in field format lists to avoid implicit prioritization.
- Explicitly state that all formats (Windows, Linux, cloud) are equally supported.
- Provide example values for Linux (e.g., UID, simple username) alongside Windows examples in tables and descriptions.
- Where field priorities are listed, consider rotating which format is shown first or clarify that order does not imply preference.
Sentinel
The Advanced Security Information Model (ASIM) Authentication normalization schema reference | Microsoft Docs
...ticles/sentinel/normalization-schema-authentication.md
Low Priority
View Details →
Detected Bias Types
Windows First
Windows Examples
Windows Terms
Summary
The documentation references Windows authentication events and Windows-specific terms (e.g., NTLM, SID, domain\hostname format) more frequently and provides Windows-centric examples (such as C:\Windows\System32\svchost.exe, domain\hostname, and 'Windows 10' OS values). Windows is mentioned first when discussing operating systems and authentication sources, and examples often use Windows conventions. However, the schema itself is designed to be cross-platform and references non-Windows systems (e.g., AWS, SaaS apps, PKI, Service Principal), and does not exclude Linux/macOS. There are no PowerShell-only instructions or Windows-only tooling.
Recommendations
- Add Linux/macOS-centric examples alongside Windows ones (e.g., show authentication events from Linux systems, use Linux process paths like /usr/bin/sshd, Linux user naming conventions, and Linux OS values).
- When describing fields such as FQDN, clarify Linux/macOS formats and provide examples (e.g., 'host.example.com').
- Include references to Linux/macOS authentication protocols (e.g., Kerberos, LDAP, PAM) in the LogonProtocol field.
- Balance introductory statements to mention Linux/macOS equally with Windows when discussing authentication event sources.
- Where possible, provide examples of authentication events from non-Windows devices (e.g., firewalls, VPNs running on Linux, macOS endpoints).
Sentinel
This file is auto-generated . Do not edit manually. Changes will be overwritten.
...b/main/articles/sentinel/includes/connector-details.md
Low Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Summary
The documentation for Microsoft Sentinel data connectors is largely cross-platform, but there are several instances where Windows-specific tools, patterns, or terminology are mentioned before their Linux equivalents, or where Windows is implicitly prioritized. For example, connectors such as 'IIS Logs of Microsoft Exchange Servers', 'Microsoft Active-Directory Domain Controllers Security Event Logs', and 'Windows DNS Events via AMA' focus on Windows event sources and reference Windows agents. Additionally, some sections refer to 'Windows machines' or 'Windows agent' without always providing Linux alternatives or mentioning Linux parity, even when the underlying Azure Monitor Agent supports both platforms.
Recommendations
- Wherever possible, clarify when connectors or agents are cross-platform (e.g., Azure Monitor Agent supports both Windows and Linux) and provide explicit instructions or notes for Linux/macOS users.
- When listing event sources or log types (e.g., IIS, Windows Event Logs), consider also mentioning common Linux equivalents (e.g., Apache/Nginx logs, Syslog) and linking to relevant connectors.
- Avoid using 'Windows machines' or 'Windows agent' as the default terminology in generic sectionsβuse 'machines' or 'agents' and specify platform differences only where necessary.
- For connectors that are Windows-specific by necessity (e.g., IIS logs, Windows Firewall), clearly label them as such to set user expectations.
- Ensure that any prerequisites or setup steps referencing PowerShell, Windows Event Viewer, or other Windows tools also provide Linux/CLI alternatives where applicable.
Sentinel
This file is auto-generated . Do not edit manually. Changes will be overwritten.
...b/main/articles/sentinel/includes/connector-details.md
Low Priority
View Details →
Detected Bias Types
Windows Tools
Windows First
Summary
The documentation lists a large number of Microsoft Sentinel data connectors, many of which are cross-platform or cloud-focused. However, there are several connectors and sections that are Windows-centric (e.g., Windows Firewall, Windows DNS Events, Windows Security Events, IIS Logs, Exchange logs, etc.), and in these cases, Windows tools and patterns are referenced without always providing equivalent Linux/macOS guidance. Additionally, in some multi-platform scenarios (e.g., custom logs, agent installation), Windows instructions or terminology are sometimes presented first or more prominently.
Recommendations
- For connectors that support both Windows and Linux (e.g., Custom Logs via AMA), ensure that Linux/Unix instructions, examples, and terminology are presented alongside Windows, not as an afterthought.
- Where agent installation is referenced (e.g., Azure Monitor Agent), provide explicit Linux/macOS installation and configuration steps/examples, not just Windows/PowerShell.
- For event log connectors (e.g., SecurityEvent, WindowsEvent), clarify if there are Linux/macOS equivalents (e.g., Syslog) and cross-reference them.
- In sections about Windows-specific features, clearly state if there is no Linux/macOS equivalent, to avoid confusion.
- Review the ordering of examples and instructions to avoid always listing Windows first when cross-platform options exist.