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 201-225 of 488 flagged pages
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-schema-file-event.md
...n/articles/sentinel/normalization-schema-file-event.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Windows Examples Heavy
Summary
The documentation demonstrates a moderate Windows bias. Windows-specific terminology, examples, and tools are mentioned first or exclusively in several places. For instance, the main example uses 'Windows File Explorer', and file path examples default to Windows formats (e.g., 'C:\Windows\System32\notepad.exe') before Unix equivalents. Windows domain and username formats are referenced in field descriptions, and guidance for fields like ActorSessionId and ActingProcessId specifically call out Windows conversion requirements. Linux/Unix equivalents are present but less emphasized, often appearing after Windows references or only in specific field examples.
Recommendations
- Provide Linux/Unix examples alongside Windows examples in all relevant sections, especially in introductory schema explanations and field descriptions.
- Alternate the order of Windows and Linux/Unix examples to avoid implicit prioritization.
- Include references to Linux/Unix tools and patterns (e.g., 'mv', 'cp', 'ls') where Windows tools (e.g., File Explorer) are mentioned.
- Clarify normalization guidance for Linux/Unix systems in fields that currently only mention Windows-specific conversion or formats.
- Expand examples to include cloud-native and cross-platform scenarios, such as macOS file operations or common SaaS integrations beyond Microsoft-centric tools.
Create Pull Request
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 First
Windows Examples
Summary
The documentation page exhibits subtle Windows bias. Several example values and field descriptions reference Windows-specific concepts, formats, and tools (e.g., file paths like 'C:\Malicious\ImNotMalicious.exe', domain names such as 'WORKGROUP' and 'DESKTOP', and user identifiers like SID). Network interface examples include 'Microsoft Hyper-V Network Adapter' and 'Ethernet adapter Ethernet 4', which are Windows-centric. The HTTP user agent example also references 'Windows NT 10.0'. There are no explicit Linux or cross-platform examples, and Windows terminology appears first or exclusively in several places.
Recommendations
- Add Linux-specific and cross-platform examples alongside Windows examples (e.g., use '/home/malicious/ImNotMalicious' for file paths, 'eth0' for network interfaces, and Linux-style domain/workgroup names).
- Include references to Linux user identifiers (e.g., UID/GID) and authentication mechanisms where relevant.
- Balance example values and terminology to reflect both Windows and Linux environments, especially in fields like device names, domains, and network adapters.
- Clarify that the schema is OS-agnostic and provide guidance for mapping Linux/macOS concepts to the schema fields.
- Where Windows-specific tools or formats are mentioned, add equivalent Linux tools or formats (e.g., mention both SID and UID/GID for user IDs).
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 the PowerShell cmdlet Unlock-SPOSensitivityLabelEncryptedFile as a method for removing sensitivity labels from files, but does not mention any equivalent Linux or cross-platform tools or methods. There are no examples or instructions for performing similar operations on Linux or macOS, nor is there any indication of parity or alternatives for non-Windows environments. The documentation assumes familiarity with Windows-centric tooling and omits Linux-specific guidance.
Recommendations
- Provide equivalent command-line examples for Linux (e.g., using Azure CLI, REST API, or other cross-platform tools) where PowerShell cmdlets are referenced.
- Explicitly state whether the described operations (such as removing sensitivity labels) can be performed on Linux or macOS, and if so, how.
- Include links or references to Linux/macOS documentation or tools for managing sensitivity labels and interacting with Microsoft Purview and Sentinel.
- Add a section clarifying platform support and any limitations for non-Windows users.
- Ensure that examples and instructions are presented in a platform-neutral way, or provide parallel instructions for both Windows and Linux environments.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-develop-parsers.md
...ain/articles/sentinel/normalization-develop-parsers.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Missing Linux Example
Summary
The documentation demonstrates a Windows bias in several areas: examples and references to Windows-specific event sources (e.g., Microsoft-Windows-Sysmon), deployment and management instructions that prioritize or exclusively mention Windows tools such as PowerShell, and a lack of Linux-specific or cross-platform alternatives for key steps (e.g., deleting functions, deploying templates). There are no explicit Linux or bash examples, and Windows-centric terminology and workflows are presented first or exclusively.
Recommendations
- Include Linux-specific examples, such as using Syslog or Linux-native event sources in filtering and mapping sections.
- Provide bash/CLI alternatives for deployment and management steps, such as using Azure CLI or REST API for ARM template deployment and function deletion.
- Reference Linux tools and workflows alongside Windows tools (e.g., mention both PowerShell and bash/CLI for automation tasks).
- Ensure event source examples cover both Windows and Linux environments, such as showing how to filter for Linux audit logs or other common Linux sources.
- Add explicit guidance for Linux users in sections that currently only mention Windows or PowerShell.
- Review and update documentation to use neutral, cross-platform language where possible.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-schema-audit.md
...b/main/articles/sentinel/normalization-schema-audit.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Examples
Windows Terms
Summary
The documentation demonstrates mild Windows bias. Windows terminology (e.g., domain\hostname format, 'Windows' username type, Windows 10 as OS example, svchost.exe as application example) is used preferentially or exclusively in examples and field descriptions. Examples of hostnames and usernames are Windows-centric, and the documentation explains support for Windows-specific formats before mentioning generic or Linux equivalents. No explicit Linux or Unix examples (e.g., Linux hostnames, usernames, processes) are provided.
Recommendations
- Add Linux/Unix-specific examples alongside Windows ones, such as Linux hostnames (e.g., 'webserver1'), Linux usernames (e.g., 'alice'), and Linux process paths (e.g., '/usr/bin/nginx').
- Clarify that fields such as FQDN, Hostname, and Username support Linux/Unix formats and provide examples.
- Mention Linux/Unix OS types in OS-related fields (e.g., 'Ubuntu 22.04', 'Red Hat Enterprise Linux 9') in addition to Windows.
- Balance application examples by including Linux/Unix processes (e.g., 'sshd', '/usr/sbin/cron') as well as Windows executables.
- Explicitly state cross-platform compatibility in relevant sections to reassure non-Windows users.
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
Windows Heavy
Summary
The documentation page lists ASIM parsers for a wide range of sources, including both Windows and Linux systems. However, Windows-centric sources (e.g., Microsoft Windows Events, Sysmon for Windows, Microsoft Defender XDR, Windows Security Events) are consistently listed and described in detail, often before or with more specificity than their Linux equivalents. Windows-specific tools and event IDs are frequently referenced, while Linux sources are present but less emphasized and sometimes grouped generically (e.g., 'Linux sshd activity reported using Syslog'). There are no explicit PowerShell examples or commands, but the overall structure and detail favor Windows environments.
Recommendations
- Ensure Linux sources are described with equal specificity, including event IDs, collection methods, and connector details.
- Add more detailed notes for Linux parsers, similar to the Windows entries (e.g., specify which Syslog facilities, event types, or collection agents are supported).
- Where Windows and Linux equivalents exist, list them together or alternate their order to avoid implicit prioritization.
- Provide explicit examples or references for Linux data collection and normalization workflows, matching the detail given for Windows.
- Review parser tables to ensure Linux tools (e.g., auditd, journald, rsyslog) are mentioned where relevant, not just generic 'Syslog'.
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
Windows Format Preference
Summary
The documentation page demonstrates a mild Windows bias. Windows terminology, formats, and examples are frequently used, such as Windows-style hostnames (e.g., 'DESKTOP-1282V4D'), domain formats (domain\hostname), and file paths (e.g., 'C:\Windows\explorer.exe'). Windows is often mentioned first or exclusively in field descriptions, and Windows-specific formats are referenced as defaults. Linux equivalents (e.g., Linux-style hostnames, file paths, process IDs) are not shown in examples, and Linux-specific terminology is rarely mentioned. The documentation does acknowledge Linux in some places (e.g., process ID types), but does not provide parity in examples or guidance.
Recommendations
- Provide Linux-specific examples alongside Windows examples, such as Linux-style hostnames (e.g., 'ubuntu-server'), file paths (e.g., '/usr/bin/sshd'), and process names.
- Mention Linux formats and conventions explicitly in field descriptions, especially where Windows formats are referenced (e.g., FQDN, process IDs, domain formats).
- Include guidance for Linux users on how to normalize or convert Linux-specific values (e.g., hexadecimal PIDs, process names, interface names like 'eth0').
- Ensure that examples and field descriptions alternate or balance between Windows and Linux to avoid implying Windows as the default or preferred platform.
- Add references to Linux tools and patterns where relevant (e.g., netstat, ifconfig, systemd process names) in addition to Windows tools.
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
Missing Linux Example
Windows First
Summary
The documentation page exhibits a notable Windows bias. Many of the process activity hunting queries and analytics rules focus on Windows-specific tools (e.g., PowerShell, rundll32.exe, certutil, Exchange PowerShell Snapin, cscript, AdFind, Powercat, Nishang), and several queries explicitly reference Windows system events (e.g., Windows System Shutdown/Reboot). There are no equivalent Linux or cross-platform examples provided, nor is there mention of Linux-specific tools or attack patterns. The documentation consistently prioritizes Windows-centric scenarios and tools, with little to no consideration for Linux environments.
Recommendations
- Add Linux-specific examples for process activity, such as detection of suspicious bash scripts, cron job persistence, or use of common Linux attack tools (e.g., netcat, bash reverse shells, python one-liners).
- Include analytics rules and hunting queries that target Linux system events (e.g., unauthorized sudo usage, suspicious modifications to /etc/passwd or /etc/shadow, abnormal SSH activity).
- Provide parity for registry and file activity by referencing Linux equivalents (e.g., monitoring changes to important configuration files, detection of rootkit installation attempts).
- Balance PowerShell and Windows tool coverage with Linux shell and utility coverage (e.g., grep, awk, sed, systemctl, journalctl).
- Explicitly state cross-platform applicability where possible, and clarify which content is Windows-only versus platform-agnostic.
- Consider adding a section or table that maps Windows-centric detections to their Linux equivalents to help users adapt content for non-Windows environments.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/notebooks.md
...cs/azure-docs/blob/main/articles/sentinel/notebooks.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Windows Tools
Summary
The documentation page demonstrates a Windows bias primarily through its focus on Microsoft Azure and Sentinel, which are more commonly used in Windows-centric environments. Examples and instructions reference Windows tools (e.g., PowerShell) before Linux equivalents, and there is no mention of Linux-specific patterns, tools, or examples for managing access or running Jupyter notebooks. The documentation assumes the use of Azure Machine Learning Compute, which is platform-agnostic but presented in a way that aligns with Windows workflows. PowerShell is referenced explicitly, while Linux alternatives (such as Bash or native Linux CLI usage) are not mentioned.
Recommendations
- Include Linux/Bash command examples alongside PowerShell for role assignments and workspace management.
- Explicitly mention that Jupyter notebooks and MSTICPy can be used on Linux systems, and provide setup instructions for Linux environments.
- Reference Linux-native tools and workflows (e.g., Azure CLI usage from Bash, Linux authentication patterns) where applicable.
- Add a section or note about cross-platform compatibility, clarifying that the tools and libraries work on both Windows and Linux.
- Provide troubleshooting tips or FAQs for Linux users running Jupyter notebooks with Microsoft Sentinel.
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 demonstrates a Windows bias by referencing Windows authentication events first, providing examples and field values that are Windows-centric (e.g., NTLM, SID, Windows domain\hostname format, svchost.exe), and omitting equivalent Linux authentication examples, protocols, or tools. Linux authentication mechanisms and field values (such as PAM, SSH, UIDs, Linux process names) are not mentioned or exemplified, and Windows terminology is used as the default in several places.
Recommendations
- Include Linux authentication event examples (e.g., SSH logins, PAM events, Linux process names) alongside or before Windows examples.
- Mention Linux authentication protocols (e.g., Kerberos, SSH, PAM) and provide sample values for fields like LogonProtocol and LogonMethod relevant to Linux.
- Add Linux-specific field value examples (e.g., UID for ActorUserId, /usr/bin/sshd for ActingAppName, Linux hostname formats) in relevant tables.
- Clarify that fields such as UsernameType, UserIdType, and AppType can have Linux-specific values, and provide those values in documentation.
- Ensure that references to domain/hostname formats acknowledge Linux conventions (e.g., FQDN, /etc/hostname) and not just Windows domain\hostname.
- Balance introductory statements to mention Linux and other OS authentication events equally with Windows.
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 exhibits subtle Windows bias. Examples for fields such as ProcessName, FilePath, and RegistryKey use Windows-style paths and conventions (e.g., C:\Windows\explorer.exe, HKEY_LOCAL_MACHINE), and references to Windows-specific concepts (SID, Windows usernames) appear before or without Linux equivalents. No Linux or cross-platform examples (e.g., Linux process paths, Linux registry equivalents, Linux user formats) are provided, and Windows tools (e.g., PSEXEC) are mentioned as rule examples. There are no PowerShell-specific examples, but the overall schema and examples are Windows-centric.
Recommendations
- Include Linux-specific examples for fields such as ProcessName (e.g., /usr/bin/sshd), FilePath (e.g., /etc/passwd), and RegistryKey (or note Linux does not have a registry).
- Add user examples using Linux formats (e.g., user@hostname, UID/GID) alongside Windows formats.
- Mention Linux tools (e.g., SSH, sudo, systemd) in rule and threat examples, not just Windows tools like PSEXEC.
- Clarify that the schema is intended for cross-platform use and provide guidance for mapping Linux/macOS fields.
- Where fields are Windows-specific (e.g., SID, RegistryKey), explicitly note their applicability and suggest Linux/macOS alternatives or indicate when fields are not relevant.
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 focused on Windows, as registry events are inherently Windows-specific. All examples, terminology, and references are Windows-centric (e.g., Windows Registry, Sysmon, Windows EDR, HKEY_LOCAL_MACHINE, C:\Windows paths). There are no Linux equivalents or examples, and Windows tools and patterns are mentioned exclusively. Even when discussing process IDs, the Linux mention is secondary and lacks concrete Linux context or examples.
Recommendations
- Explicitly state that the schema is Windows-specific and clarify that Linux does not have a direct registry equivalent.
- If relevant, provide guidance or references for Linux systems regarding comparable configuration or persistence mechanisms (e.g., Linux config files, dconf, gsettings, etc.), and how those might be monitored or normalized in Microsoft Sentinel.
- Add a section comparing Windows Registry events to Linux/Unix configuration changes, highlighting differences and possible monitoring strategies.
- Where fields (such as process IDs) are applicable to both Windows and Linux, provide Linux-specific examples and normalization guidance.
- If the schema is intended to be extensible for other platforms, outline how it could be adapted for non-Windows systems.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-schema-dns.md
...lob/main/articles/sentinel/normalization-schema-dns.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Windows Examples
Windows Heavy Field Examples
Summary
The documentation page exhibits a moderate Windows bias. Windows terminology, formats, and examples are consistently presented first or exclusively (e.g., domain\hostname, SIDs, process paths like C:\Windows\explorer.exe, domain types labeled 'Windows', and user types labeled 'Windows'). Field descriptions and examples favor Windows conventions, with Linux equivalents mentioned only in passing or not at all. There are no Linux-specific examples, and Windows-centric identifiers (SIDs, domain\hostname) are used as canonical formats. The schema and field guidelines are tailored to Windows environments, with Linux support implied but not demonstrated.
Recommendations
- Add Linux-specific examples for fields such as hostnames, process names (e.g., /usr/bin/sshd), and user identifiers (e.g., UID/GID).
- Present Linux and Windows formats side-by-side in field descriptions, especially for fields like SrcFQDN, SrcDomainType, SrcProcessName, and SrcUserId.
- Include explicit mention and examples of Linux domain types (e.g., FQDN, local UNIX domains) and user types (e.g., POSIX users, service accounts).
- Clarify how Linux systems map to schema fields, such as process IDs, hostnames, and domain information.
- Ensure that recommendations and best practices are applicable to both Windows and Linux environments, and highlight any platform-specific discrepancies.
- Where Windows-centric terminology is used (e.g., SIDs, domain\hostname), provide Linux equivalents (e.g., UID/GID, /etc/hostname) and explain mapping.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/move-to-defender.md
...e-docs/blob/main/articles/sentinel/move-to-defender.md
High Priority
View Details →
Detected Bias Types
Windows Tools
Windows First
Missing Linux Example
Summary
The documentation page demonstrates a Windows bias primarily through exclusive references to Microsoft Defender, WindowsDefenderATP, and other Defender products, which are Windows-centric. There are no Linux-specific examples, tools, or operational patterns mentioned, nor is there guidance for Linux users or parity with Linux-native security workflows. The documentation assumes usage of Microsoft-centric (and thus Windows-centric) security solutions and does not address Linux environments or provide examples for Linux-based operations.
Recommendations
- Add explicit guidance for Linux environments, including how Linux-based hosts and data sources are onboarded, managed, and monitored in the Defender portal.
- Include examples and workflows for Linux systems, such as onboarding Linux servers to Microsoft Sentinel/Defender, configuring connectors for Linux logs, and managing incidents originating from Linux endpoints.
- Reference Linux-native tools (e.g., auditd, syslog, rsyslog, journald) and how their data can be integrated and visualized in the Defender portal.
- Provide parity in automation and playbook examples, showing how Linux-based automation (e.g., Bash scripts, Python, Ansible) can be triggered and managed alongside Azure Logic Apps.
- Clarify any limitations or differences in feature support for Linux endpoints compared to Windows endpoints within the Defender portal.
- Ensure that role-based access control, data retention, and privacy policies are explained for Linux data sources as well as Windows.
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
Missing Linux Example
Summary
The documentation page exhibits a Windows bias in several areas. Windows-specific terminology and examples (such as 'Windows DHCP server', 'TransactionID', and domain formats like 'Contoso\DESKTOP-1282V4D') are mentioned explicitly, often without Linux equivalents. The schema fields and notes frequently reference Windows conventions (e.g., MAC address formatting in Windows logs, Windows domain types), and there are no examples or guidance for Linux DHCP servers or their log formats. Linux tools, patterns, or field mappings are not discussed, leaving gaps for users working in non-Windows environments.
Recommendations
- Add explicit examples and notes for Linux DHCP servers (such as ISC DHCP, Kea, or dnsmasq), including how their logs map to schema fields.
- Where Windows-specific behavior is described (e.g., MAC address formatting), include Linux equivalents and parsing guidance.
- Expand domain and hostname field documentation to cover common Linux/Unix naming conventions and formats.
- Provide parity in examples: for every Windows example, include a Linux example.
- Reference Linux tools and patterns (e.g., systemd, syslog, log file locations) alongside Windows tools.
- Clarify that the schema is intended to be source-agnostic, and highlight any differences in field population between Windows and Linux DHCP servers.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/resource-context-rbac.md
...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 referencing Windows event data and Windows administrators as primary examples, and by mentioning Windows-specific scenarios before Linux or cross-platform equivalents. There is a lack of explicit Linux-focused examples, such as Linux event data or Linux administrator scenarios, and no mention of Linux tools or commands for log forwarding or collection. The documentation also refers to Syslog and CEF (which are cross-platform), but does not provide Linux-specific guidance or examples, nor does it mention Linux-native tools or patterns for managing access.
Recommendations
- Include Linux-specific examples, such as granting access to Linux audit logs or Linux administrator scenarios.
- Provide explicit guidance for Linux log forwarding, including sample configurations for rsyslog or syslog-ng.
- Mention Linux-native tools and patterns for log collection and RBAC, such as using Azure Arc with Linux VMs.
- Ensure that examples and scenarios alternate between Windows and Linux, or present them in parallel, to avoid Windows-first bias.
- Clarify that resource-context RBAC applies equally to Linux resources and provide links to Linux documentation where appropriate.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-entity-application.md
.../articles/sentinel/normalization-entity-application.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Windows Tools
Summary
The documentation page exhibits Windows bias by providing only Windows-style examples for process paths (e.g., 'C:\Windows\explorer.exe'), referencing Windows directories and tools (e.g., 'rundll32.exe'), and omitting equivalent Linux examples (such as '/usr/bin/bash'). The guidance on process IDs mentions Windows and Linux together, but examples and terminology are Windows-centric and appear first.
Recommendations
- Add Linux-specific examples for process paths (e.g., '/usr/bin/bash', '/usr/sbin/sshd') alongside Windows examples.
- When mentioning process IDs, provide both Windows and Linux sample values and clarify any platform-specific differences.
- Avoid referencing only Windows tools (like 'rundll32.exe'); include common Linux processes (such as 'systemd', 'sshd', etc.) in examples.
- Present Windows and Linux information in parallel, rather than Windows-first, to improve parity and inclusiveness.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-schema-process-event.md
...rticles/sentinel/normalization-schema-process-event.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Windows Examples
Windows Concepts
Summary
The documentation exhibits a Windows bias in several areas: process and file path examples use Windows conventions (e.g., C:\Windows\explorer.exe), integrity level and token elevation concepts are described using Windows-specific terminology and references, and links to further information point to Windows documentation. Linux equivalents, examples, and concepts are not presented, and Windows is often mentioned first or exclusively when discussing process attributes and security features.
Recommendations
- Include Linux-specific examples for process names, file paths (e.g., /usr/bin/bash), and command lines alongside Windows examples.
- Describe Linux process integrity and privilege concepts (e.g., user/group IDs, SELinux/AppArmor contexts) in parallel to Windows integrity levels and UAC.
- Reference Linux documentation and security models where appropriate, such as links to man pages or kernel documentation.
- Clarify which fields and concepts are cross-platform and which are Windows-specific, and provide guidance for Linux implementations.
- Add sample queries and field values from Linux systems to demonstrate parity.
- When listing supported values or describing normalization, mention Linux first or equally with Windows to avoid ordering bias.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/sentinel-analytic-rules-creation.md
.../articles/sentinel/sentinel-analytic-rules-creation.md
High Priority
View Details →
Detected Bias Types
Windows Tools
Powershell Heavy
Windows First
Summary
The documentation page demonstrates Windows bias primarily in the 'ID' section, where PowerShell's New-GUID cmdlet is explicitly mentioned as a way to generate GUIDs, with no mention of Linux or cross-platform alternatives. Windows/PowerShell tooling is referenced first and exclusively, and there are no Linux or platform-neutral examples for GUID generation. The rest of the documentation is generally platform-agnostic, focusing on YAML, KQL, and Microsoft Sentinel concepts, but the only concrete tooling example is Windows-centric.
Recommendations
- Include Linux and cross-platform alternatives for GUID generation, such as 'uuidgen' (Linux/macOS) or Python's uuid module.
- Present platform-neutral instructions first, e.g., 'You can generate a GUID using any development tool, online generator, or command-line utility such as PowerShell (New-GUID), Linux (uuidgen), or Python (uuid.uuid4()).'
- Wherever a tool or command is referenced, provide both Windows and Linux/macOS equivalents, or use generic language.
- Audit other sections for subtle platform assumptions and clarify if any tool or pattern is Windows-specific.
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 scheduled analytics rules in Microsoft Sentinel demonstrates a Windows bias primarily in the 'Next steps' section, where automation is described via API and PowerShell, with PowerShell mentioned explicitly and no Linux-native equivalents (such as Bash, shell scripts, or CLI tools) provided. There are no examples or references to Linux tools or workflows, and the only automation scripting language referenced is PowerShell, which is traditionally associated with Windows environments. No Linux-specific instructions, examples, or parity is offered for users who may be managing Sentinel from Linux systems.
Recommendations
- Include examples of automating rule enablement using Azure CLI (az), which is cross-platform and commonly used on Linux.
- Provide sample Bash or shell scripts for exporting/importing rules, alongside PowerShell examples.
- Mention that PowerShell Core is available on Linux, but also offer instructions for users who prefer native Linux tools.
- Reference Linux-compatible tools and workflows (e.g., curl for API calls, jq for JSON processing) in automation sections.
- Ensure that scripting and automation instructions are presented in a platform-neutral way, or provide both Windows and Linux examples side-by-side.
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
Windows Tools
Missing Linux Example
Windows First
Summary
The documentation page demonstrates a Windows bias by exclusively providing a PowerShell script for automating client secret rotation, referencing Azure PowerShell modules, and omitting equivalent Linux/bash examples. The automation and scripting guidance is tailored to Windows environments, with no mention of cross-platform alternatives such as Azure CLI or bash scripts. The documentation also implicitly assumes use of Windows tooling by referencing PowerShell first and not offering Linux-native instructions.
Recommendations
- Provide equivalent automation examples using Azure CLI and bash scripts for Linux/macOS users.
- Explicitly state that the solution can be managed from Linux/macOS and provide guidance for those platforms.
- Reference cross-platform tools (e.g., Azure CLI, REST API via curl) alongside PowerShell, and avoid assuming PowerShell as the default.
- Add notes or sections clarifying platform compatibility and offering parity in instructions for Linux and macOS environments.
- Where screenshots or UI instructions are given, clarify any platform-specific differences or offer alternatives.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/sentinel-playbook-creation.md
...b/main/articles/sentinel/sentinel-playbook-creation.md
High Priority
View Details →
Detected Bias Types
Powershell Heavy
Windows Tools
Missing Linux Example
Windows First
Summary
The documentation page exhibits a strong Windows bias in its instructions for generating and sanitizing ARM templates for playbooks. All automation steps rely exclusively on a PowerShell script, with explicit references to Windows PowerShell, Visual Studio Code (on Windows), and PowerShell Core. There are no examples or instructions for Linux users, such as using Bash, Azure CLI, or cross-platform scripting alternatives. The documentation assumes the reader is on a Windows environment and does not mention Linux-compatible workflows or tools.
Recommendations
- Provide equivalent instructions for Linux users, such as using Azure CLI, Bash scripts, or cross-platform PowerShell Core.
- Explicitly state platform compatibility for the PowerShell script and offer troubleshooting or alternatives for Linux/macOS environments.
- Include examples showing how to run the script on Linux (e.g., with PowerShell Core or Azure CLI), and clarify any prerequisites or differences.
- Mention and link to cross-platform tools where possible, and avoid assuming Visual Studio Code or PowerShell is only available on Windows.
- Consider providing Docker-based or cloud-based alternatives for users who do not have access to Windows environments.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/sentinel-summary-rules-creation.md
...n/articles/sentinel/sentinel-summary-rules-creation.md
High Priority
View Details →
Detected Bias Types
Windows Tools
Windows First
Missing Linux Example
Summary
The documentation page exhibits Windows bias by exclusively mentioning the PowerShell 'New-GUID' cmdlet as a way to generate GUIDs, without referencing Linux or cross-platform alternatives. No Linux or macOS command-line examples (such as 'uuidgen') are provided, and the Windows tool is mentioned first and solely. This may lead Linux users to feel unsupported or unclear about equivalent workflows.
Recommendations
- Add Linux/macOS command-line examples for generating GUIDs, such as 'uuidgen' or 'cat /proc/sys/kernel/random/uuid'.
- Present cross-platform options together, e.g., 'You can generate a GUID using PowerShell (New-GUID), Linux/macOS (uuidgen), or any online generator.'
- Avoid mentioning Windows tools exclusively or first; strive for parity by listing alternatives side-by-side.
- Where possible, link to documentation for Linux/macOS tools as well as PowerShell.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/sentinel-solutions-deploy.md
...ob/main/articles/sentinel/sentinel-solutions-deploy.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Missing Linux Example
Summary
The documentation page demonstrates a Windows bias primarily through its focus on Microsoft portals (Defender and Azure), and by referencing PowerShell as a deployment method for ARM templates, without providing equivalent Linux-specific examples (such as Bash or Azure CLI usage on Linux). The documentation does not mention or illustrate Linux-specific tools, workflows, or command-line examples, and assumes a Windows-centric environment for management and automation tasks.
Recommendations
- Add explicit examples for deploying ARM templates using Azure CLI on Linux, including Bash command snippets.
- Reference cross-platform tools and clarify that Azure CLI is available on Linux and macOS, not just Windows.
- Include screenshots or instructions for Linux users where relevant (e.g., terminal usage, authentication flows).
- Avoid listing PowerShell before Azure CLI, or provide both options equally in automation sections.
- Mention any Linux-specific requirements or differences in configuring data connectors, especially for Syslog/CEF connectors.
- Ensure that any automation or scripting guidance is platform-neutral or includes both Windows and Linux variants.
Sentinel
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/stix-objects-api.md
...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 example for interacting with the API, relying on the MSAL.PS module and Windows certificate store. There are no equivalent examples for Linux or cross-platform command-line tools (such as curl, Python, or bash), nor is there guidance for acquiring tokens or making API calls on non-Windows systems. The use of Windows-specific tooling and lack of Linux alternatives creates a clear Windows bias.
Recommendations
- Add equivalent sample code for Linux environments using curl, Python (requests + MSAL), or bash scripts.
- Document how to acquire and use certificates and secrets for authentication on Linux/macOS, including storing and referencing them.
- Provide cross-platform guidance for installing and using MSAL libraries (e.g., Python MSAL, Node.js MSAL) and making REST API calls.
- Include notes or sections on how to adapt the workflow for Linux, such as using OpenSSL for certificate management and environment variables for secrets.
- Ensure all examples are presented in a platform-neutral way or provide both Windows and Linux/macOS alternatives side-by-side.