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 26-50 of 488 flagged pages
Sentinel Scenarios detected by the Microsoft Sentinel Fusion engine ...ob/main/articles/sentinel/fusion-scenario-reference.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Powershell Heavy 🔧 Windows Tools Windows First Missing Linux Example
Summary
The documentation page exhibits several forms of Windows bias. Many detection scenarios and descriptions reference Windows-specific technologies (PowerShell, WMI, Microsoft Defender for Endpoint, etc.) and focus on Microsoft cloud and endpoint products. Examples and threat techniques are almost exclusively Windows-centric, with little to no mention of Linux or cross-platform equivalents. Linux-specific attack patterns, tools, or detection methods are absent, and Windows tools (PowerShell, WMI) are referenced without Linux analogs. This can make the documentation less relevant or actionable for organizations with significant Linux infrastructure.
Recommendations
  • Include Linux-specific attack scenarios, such as suspicious Bash or Python script execution, SSH brute force, or Linux credential dumping tools (e.g., 'Linux mimikatz', 'LaZagne').
  • Add examples of detection for Linux-native threats and techniques, such as rootkit installation, unauthorized cron job creation, or suspicious use of system utilities (e.g., netcat, socat, curl, wget).
  • Reference Linux security tools and logs (e.g., auditd, syslog, journald, fail2ban) alongside Windows tools.
  • Where PowerShell or WMI are mentioned, provide equivalent Linux command-line or scripting examples (e.g., bash, python, systemd-run, etc.).
  • Clarify which scenarios and detections are cross-platform and which are Windows-only, to help users understand coverage gaps.
  • Expand data connector sources to include Linux endpoint solutions (e.g., Microsoft Defender for Endpoint for Linux, or third-party Linux EDRs) and describe their role in Fusion detections.
GitHub Create Pull Request
Sentinel This file is auto-generated . Do not edit manually. Changes will be overwritten. ...b/main/articles/sentinel/includes/connector-details.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Powershell Heavy Missing Linux Example
Summary
The documentation for Microsoft Sentinel data connectors demonstrates a Windows bias in several ways: Windows-specific tools and patterns (such as Azure Monitor Agent on Windows, Windows Event logs, and references to Windows agents) are frequently mentioned, often without equivalent Linux examples or guidance. Windows event collection (e.g., SecurityEvent, WindowsEvent, Event, W3CIISLog) is described in detail, while Linux log collection is mostly limited to Syslog, with less emphasis and fewer examples. Powershell and Windows-centric deployment instructions are referenced in prerequisites and links. In many cases, Linux alternatives are not mentioned or are presented after Windows options.
Recommendations
  • For every Windows-specific connector or example (e.g., Windows Event logs, IIS logs, Windows DNS, Windows Firewall), provide equivalent Linux-focused examples (e.g., Syslog, auditd, Linux firewall logs, BIND DNS logs).
  • When describing agent installation or prerequisites, include Linux-specific instructions and command-line examples (e.g., bash, systemctl) alongside Windows/Powershell.
  • Avoid presenting Windows options first by default; instead, structure documentation to present both Windows and Linux options in parallel, or clarify cross-platform applicability.
  • Expand the list of supported log types and connectors for Linux systems, and document them with equal detail and prominence.
  • Where Windows tools or patterns are referenced (e.g., Windows Event Forwarding, Windows agent), mention Linux equivalents (e.g., rsyslog, journald, auditd) and provide setup guidance.
  • Audit all connector documentation for assumptions of a Windows environment and revise to ensure Linux users are equally supported.
GitHub Create Pull Request
Sentinel Advanced multistage attack detection in Microsoft Sentinel ...tDocs/azure-docs/blob/main/articles/sentinel/fusion.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Powershell Heavy 🔧 Windows Tools Windows First Missing Linux Example
Summary
The documentation page demonstrates a Windows bias through frequent references to Windows-specific tools (e.g., PowerShell, Windows Error and Warning Events), and scenario examples that focus on Windows malware and PowerShell-based attacks. There is a lack of Linux-specific detection scenarios, examples, or references to Linux-native tools and attack patterns. Windows-centric terminology and tools are mentioned before or instead of Linux equivalents, and no Linux/POSIX command-line or attack examples are provided.
Recommendations
  • Add detection scenarios and examples involving Linux-based threats, such as SSH brute force, suspicious sudo activity, or Linux-specific malware.
  • Include references to Linux logs (e.g., syslog, auth.log) and Linux-native tools (e.g., Bash, systemd, auditd) in scenario tables and examples.
  • Provide parity in examples by showing how multistage attacks might manifest on Linux systems, including relevant alerts and severity levels.
  • Mention Linux data connectors and how to configure them for Fusion, alongside Windows connectors.
  • Ensure that documentation covers both Windows and Linux environments equally, especially in sections describing attack detection, incident generation, and analytics rule configuration.
GitHub Create Pull Request
Sentinel This file is auto-generated . Do not edit manually. Changes will be overwritten. ...in/articles/sentinel/includes/deprecated-connectors.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by consistently mentioning Windows agents, tools, and patterns before or instead of Linux equivalents. Several connectors (e.g., Exchange Logs, Security Events) explicitly reference Windows machines and agents, with detailed prerequisites and instructions for Windows but lack equivalent detail for Linux. Examples and installation procedures are Windows-centric, and Linux coverage is limited to a single Syslog connector section, which is less detailed and appears later in the document.
Recommendations
  • Provide Linux-specific examples and instructions for each connector where applicable, not just for Syslog.
  • Ensure that prerequisites and installation procedures cover both Windows and Linux environments with equal detail.
  • Mention Linux agents and data collection patterns alongside Windows agents in all relevant sections.
  • Add parity in troubleshooting, configuration, and migration guidance for Linux users.
  • Review connector support tables to clarify Linux compatibility and limitations.
  • Avoid language that implies Windows is the default or primary platform; present Windows and Linux options side-by-side.
GitHub Create Pull Request
Sentinel SAP agentless data connector prerequisites checker ...icles/sentinel/includes/sap-agentless-prerequisites.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
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 (such as curl or bash). The PowerShell example is presented as the default method, implicitly prioritizing Windows users and leaving Linux users without guidance.
Recommendations
  • Add equivalent Linux/bash examples using curl or wget for triggering the REST endpoint.
  • Include a note clarifying that the prerequisites checker can be triggered from any REST client, with examples for both Windows and Linux.
  • Present cross-platform examples side-by-side or in parallel sections to ensure parity and inclusivity.
  • Avoid language that implies PowerShell is the only or preferred method.
GitHub Create Pull Request
Sentinel Microsoft Defender XDR integration with Microsoft Sentinel ...entinel/microsoft-365-defender-sentinel-integration.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First Missing Linux Example 🔧 Windows Tools
Summary
The documentation page demonstrates Windows bias by exclusively referencing Microsoft Defender XDR, Microsoft Sentinel, and related Microsoft security products, all of which are primarily Windows-centric. There are no examples, instructions, or mentions of Linux-specific tools, workflows, or integration patterns. The documentation assumes usage of Microsoft portals and services, which are typically accessed from Windows environments, and does not address Linux-based security operations or alternative SIEM/XDR solutions. No PowerShell examples are present, but the overall approach and terminology are Windows-focused, with no parity for Linux users.
Recommendations
  • Add explicit instructions or examples for integrating Microsoft Sentinel and Defender XDR with Linux-based systems, such as using Linux agents or connectors.
  • Include references to Linux-compatible tools and workflows for incident investigation and response within Sentinel.
  • Provide parity in documentation by mentioning how Linux endpoints and servers are onboarded, monitored, and correlated in Defender XDR and Sentinel.
  • Highlight any limitations or differences when using Defender XDR and Sentinel in Linux environments, and offer guidance for Linux-first organizations.
  • If advanced hunting or custom detection rules can be authored or executed from Linux environments, provide examples using Bash, Python, or other Linux-native scripting languages.
GitHub Create Pull Request
Sentinel Microsoft Sentinel migration: Select a data ingestion tool | Microsoft Docs ...lob/main/articles/sentinel/migration-ingestion-tool.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Powershell Heavy Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation page exhibits a Windows bias in several areas. PowerShell scripts are presented as the primary method for custom log ingestion and API-based ingestion, with no equivalent Linux shell or cross-platform scripting examples. The SIEM data migration accelerator deploys a Windows VM and downloads Windows-centric tools, with no mention of Linux-based automation or VM options. While some tools (Logstash, AzCopy) are noted as cross-platform, their usage and examples are not shown for Linux environments. Windows tools and patterns (PowerShell, Windows VM) are mentioned first or exclusively, and Linux alternatives are missing or underrepresented.
Recommendations
  • Provide Linux shell (bash) and cross-platform scripting examples alongside PowerShell for ingestion tasks.
  • Include instructions for deploying the SIEM data migration accelerator on Linux VMs or containers, or provide parity for Linux environments.
  • Highlight cross-platform capabilities of tools (e.g., AzCopy, Logstash) with explicit Linux usage examples and commands.
  • Avoid presenting Windows tools and patterns first or exclusively; ensure Linux equivalents are mentioned with equal prominence.
  • Clarify when tools are Windows-only and suggest alternative approaches for Linux users.
  • Add documentation sections or links for Linux-specific migration workflows and automation.
GitHub Create Pull Request
Sentinel Advanced Security Information Model (ASIM) security content | Microsoft Docs ...s/blob/main/articles/sentinel/normalization-content.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
🔧 Windows Tools Powershell Heavy Missing Linux Example Windows First
Summary
The documentation page exhibits a Windows bias in several ways: many analytic rules and hunting queries focus on Windows-specific tools (e.g., rundll32.exe, PowerShell, certutil, Exchange PowerShell Snapin), and there is a notable absence of Linux-specific examples or references to Linux tools and patterns. The majority of process activity examples are Windows-centric, and PowerShell usage is highlighted repeatedly without mention of Linux shell equivalents. No Linux-specific threats, commands, or detection patterns are provided, and Windows terminology (e.g., registry, UAC bypass) is used exclusively or first.
Recommendations
  • Add Linux-specific analytic rules and hunting queries, such as detection of suspicious bash, python, or perl scripts, or Linux persistence techniques (e.g., cron jobs, systemd services).
  • Include examples of Linux command-line tools (e.g., grep, awk, systemctl) and detection of common Linux attack patterns (e.g., SSH brute force, sudo abuse, rootkit installation).
  • Balance the coverage of Windows and Linux by providing parity in threat detection scenarios, such as both Windows and Linux privilege escalation, process monitoring, and file activity.
  • Explicitly mention Linux equivalents when referencing Windows tools (e.g., PowerShell vs. bash/zsh, certutil vs. openssl), and provide hunting queries for both platforms.
  • Highlight cross-platform threats and detection strategies, ensuring that examples and documentation do not assume a Windows-only environment.
GitHub Create Pull Request
Sentinel Transition Your Microsoft Sentinel Environment to the Defender Portal ...e-docs/blob/main/articles/sentinel/move-to-defender.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
🔧 Windows Tools Windows First Missing Linux Example
Summary
The documentation page exhibits a Windows bias primarily through the exclusive mention and prioritization of Microsoft Defender, WindowsDefenderATP, and other Defender-branded tools, which are Windows-centric. There is no mention of Linux-specific workflows, tools, or examples, nor is there any guidance for Linux users or parity with Linux-based security operations. All examples, connectors, and operational patterns are described in the context of Microsoft and Windows ecosystem tools, with no reference to Linux equivalents or cross-platform considerations.
Recommendations
  • Include explicit guidance and examples for Linux-based environments, such as onboarding Linux workspaces to Defender, configuring connectors for Linux endpoints, and managing incidents originating from Linux hosts.
  • Document any differences or limitations when using Microsoft Sentinel and Defender portal features on Linux systems, including supported connectors, analytics rules, and automation capabilities.
  • Provide parity in examples and walkthroughs, ensuring that both Windows and Linux scenarios are covered (e.g., incident investigation, advanced hunting queries, automation playbooks).
  • Reference Linux security tools and integration patterns (such as syslog, auditd, or Linux-native agents) alongside Windows tools, and clarify any platform-specific requirements or caveats.
  • Add troubleshooting and best practices sections for Linux users transitioning to the Defender portal, including common issues and solutions.
GitHub Create Pull Request
Sentinel Develop Microsoft Sentinel Advanced Security Information Model (ASIM) parsers | Microsoft Docs ...ain/articles/sentinel/normalization-develop-parsers.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
🔧 Windows Tools Powershell Heavy Windows First Missing Linux Example
Summary
The documentation page demonstrates a bias toward Windows environments and tooling. Examples and deployment instructions frequently reference Windows-specific tools (such as PowerShell and ARM templates via the Azure portal), and Windows-centric event sources (e.g., Microsoft-Windows-Sysmon) are used in filtering examples. There is a lack of parity in providing Linux-specific instructions, tools, or examples, such as using Azure CLI, Bash, or Linux-native log sources and deployment methods. Linux alternatives are not mentioned or are omitted entirely, and Windows/PowerShell methods are presented first or exclusively.
Recommendations
  • Provide Linux-specific deployment instructions, such as using Azure CLI or Bash scripts for ARM template deployment.
  • Include examples using Linux log sources (e.g., Syslog, Auditd) alongside Windows event sources in filtering and parsing sections.
  • Mention Linux-native tools for managing and deploying parsers, such as az CLI, and provide equivalent steps for Linux users.
  • When referencing PowerShell scripts or Windows portal actions, offer parallel instructions for Linux environments.
  • Ensure that sample queries and code snippets include both Windows and Linux event types and field names.
  • Explicitly state cross-platform compatibility and highlight any platform-specific considerations.
GitHub Create Pull Request
Sentinel List of Microsoft Sentinel Advanced Security Information Model (ASIM) parsers | Microsoft Docs ...b/main/articles/sentinel/normalization-parsers-list.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Windows Heavy
Summary
The documentation lists a wide array of ASIM parsers for both Windows and Linux sources, but Windows-centric tools, event types, and connectors (such as Windows Events, Sysmon for Windows, Windows Security Events, and Microsoft Defender XDR) are consistently mentioned before or more prominently than their Linux equivalents. Windows-specific event IDs and connectors are described in detail, while Linux sources are fewer and often grouped or described more generically (e.g., 'reported using Syslog'). There are more parser types and examples for Windows than for Linux, and Windows event collection methods (Azure Monitor Agent, Log Analytics Agent) are referenced frequently, with less detail on Linux ingestion patterns.
Recommendations
  • Ensure Linux parsers are described with equal detail, including specific event IDs, log sources, and collection methods (e.g., auditd, journald, rsyslog, etc.).
  • Add more Linux-specific examples and expand coverage to include common Linux tools and patterns (such as audit logs, systemd journal, and other security-relevant sources).
  • Where Windows and Linux equivalents exist, present them side-by-side or in parallel sections to avoid implicit prioritization.
  • Clarify ingestion and normalization steps for Linux sources, matching the specificity given to Windows connectors.
  • Consider adding tables or lists that explicitly compare Windows and Linux event types, connectors, and parser coverage for transparency.
GitHub Create Pull Request
Sentinel The Advanced Security Information Model (ASIM) Authentication normalization schema reference | Microsoft Docs ...ticles/sentinel/normalization-schema-authentication.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Windows Heavy Examples Missing Linux Example
Summary
The documentation page demonstrates a Windows bias in several ways: Windows is mentioned first and most frequently as an example of authentication event sources, and Windows-specific tools, formats, and terminology (e.g., NTLM, SID, domain\hostname, svchost.exe) are used throughout field examples and descriptions. There are no equivalent Linux or non-Windows examples (e.g., Linux PAM, SSH, systemd, /usr/bin/sshd, UID/GID, etc.), nor are Linux authentication protocols or patterns referenced. This may make the documentation less accessible or relevant to users working in heterogeneous or Linux-dominant environments.
Recommendations
  • Add Linux-specific examples alongside Windows ones for fields such as LogonProtocol (e.g., Kerberos, SSH, PAM), LogonMethod (e.g., public key, password, certificate), and application/process names (e.g., /usr/bin/sshd, /usr/sbin/login).
  • Include Linux authentication event sources (e.g., Linux servers, firewalls, VPN gateways using OpenVPN or strongSwan) in introductory explanations.
  • Reference Linux user and device identifiers (e.g., UID, GID) and hostname/domain formats (e.g., FQDN, /etc/hostname) where appropriate.
  • Provide examples of authentication events from Linux systems in KQL queries and field value tables.
  • Clarify that the schema is intended to be cross-platform and provide guidance for mapping Linux authentication events to the schema fields.
GitHub Create Pull Request
Sentinel The Advanced Security Information Model (ASIM) Alert Events normalization schema reference | Microsoft Docs ...b/main/articles/sentinel/normalization-schema-alert.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation exhibits subtle Windows bias. Examples and field descriptions frequently use Windows-centric values (e.g., file paths like C:\Windows\System32\notepad.exe, registry keys such as HKEY_LOCAL_MACHINE, and process names like explorer.exe). There are no Linux-specific examples (such as /var/log/syslog, /usr/bin/bash, or Linux-style process/file paths), nor are Linux tools or patterns mentioned. The schema fields and descriptions prioritize Windows terminology and conventions, and do not provide parity for Linux or cross-platform scenarios.
Recommendations
  • Add Linux-specific examples alongside Windows examples for fields such as FilePath, ProcessName, RegistryKey, etc. (e.g., /etc/passwd, /usr/bin/sshd, /var/log/auth.log).
  • Include references to Linux equivalents for Windows concepts (e.g., registry vs. configuration files, Windows SID vs. Linux UID/GID).
  • Ensure field descriptions and sample values are platform-neutral or provide both Windows and Linux variants.
  • Mention Linux security tools and detection methods (e.g., auditd, syslog, SELinux, AppArmor) where relevant.
  • Clarify that the schema is intended for cross-platform use and provide guidance/examples for mapping Linux-originating alerts.
GitHub 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 →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Windows Heavy Examples
Summary
The documentation page for the ASIM DHCP normalization schema exhibits a moderate Windows bias. Windows-specific terminology, examples, and field handling are presented before or instead of Linux equivalents. For instance, the schema references the Windows DHCP server explicitly (e.g., TransactionID mapping, MAC address formatting), and examples use Windows-style hostnames and domain formats. There is little to no mention of Linux/Unix DHCP servers, their log formats, or field mappings, and no Linux-specific examples are given.
Recommendations
  • Add explicit references and examples for Linux/Unix DHCP servers (e.g., ISC DHCP, Kea), including how their fields map to the schema.
  • Include Linux-style hostnames and domain formats in example values (e.g., 'dhcp-client-01', 'example.com').
  • Document differences in MAC address formatting and session IDs for common Linux DHCP servers.
  • Provide guidance for parsing and normalizing logs from Linux DHCP servers alongside Windows.
  • Ensure that field descriptions and notes do not assume Windows as the default, and clarify cross-platform applicability.
GitHub Create Pull Request
Sentinel The Advanced Security Information Model (ASIM) DNS normalization schema reference | Microsoft Docs ...lob/main/articles/sentinel/normalization-schema-dns.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Windows Examples Windows Heavy Field Examples
Summary
The documentation exhibits a moderate Windows bias. Windows terminology, domain formats, and examples (such as 'Contoso\DESKTOP-1282V4D', 'C:\Windows\explorer.exe', and SIDs) are used throughout, often as the first or only examples. Windows-specific concepts (domain types, process paths, user types) are referenced before or instead of Linux equivalents. There is little mention of Linux-specific formats, tools, or examples, and fields are often described with Windows-centric values or notes.
Recommendations
  • Add Linux-specific examples alongside Windows ones (e.g., show Linux process paths like '/usr/bin/bash', Linux hostnames, and user formats).
  • Document Linux domain and username formats (e.g., FQDNs, UIDs, and typical Linux DNS server event fields).
  • Clarify that fields such as process IDs, hostnames, and domain types can have Linux-specific values and provide those examples.
  • Include references to Linux DNS server software (e.g., BIND, Unbound) and their event formats where relevant.
  • Ensure that guidance and field descriptions do not assume Windows as the default, and explicitly mention Linux/Unix systems where applicable.
  • Where Windows domain concepts are described, provide equivalent Linux/Unix concepts (e.g., local users, /etc/hosts, /etc/resolv.conf).
GitHub Create Pull Request
Sentinel The Advanced Security Information Model (ASIM) File Event normalization schema reference| Microsoft Docs ...n/articles/sentinel/normalization-schema-file-event.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Windows Examples Heavy
Summary
The documentation demonstrates a moderate Windows bias. Windows tools and terminology (e.g., File Explorer, Windows path formats, domain\hostname, SIDs) are mentioned first or exclusively in several places. Examples for file paths, process names, and user/domain formats predominantly use Windows conventions, with Linux/Unix equivalents appearing less frequently or as secondary notes. The only concrete example of a file operation uses Windows File Explorer. There are no PowerShell-specific examples, but the overall schema and field descriptions favor Windows-centric patterns and identifiers.
Recommendations
  • Provide Linux/Unix examples alongside or before Windows examples for file paths, process names, and user/domain formats.
  • Include more concrete Linux/Unix scenarios (e.g., using Nautilus, cp/mv commands, or Linux file system paths) in illustrative examples.
  • Clarify that fields such as ActorSessionId, process IDs, and path formats are equally applicable to Linux/Unix systems, and provide normalization guidance for those platforms.
  • Expand the schema reference to mention Linux/Unix tools and patterns (e.g., inode numbers, UID/GID, /etc/passwd) where relevant.
  • Ensure that documentation language and examples do not assume Windows as the default, but treat Linux/Unix and Windows equally as primary platforms.
GitHub Create Pull Request
Sentinel The Advanced Security Information Model (ASIM) Audit Events normalization schema reference | Microsoft Docs ...b/main/articles/sentinel/normalization-schema-audit.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First Windows Examples Windows Terms
Summary
The documentation demonstrates a moderate Windows bias. Windows terminology (e.g., domain\hostname format, Windows username type, Windows 10 OS examples) is used preferentially or exclusively in field examples and descriptions. Windows-specific formats are mentioned before or in preference to Linux/Unix equivalents, and examples for fields like hostnames, usernames, and application paths are Windows-centric. There are no explicit Linux or Unix examples, nor are Linux-specific patterns or tools referenced.
Recommendations
  • Include Linux/Unix examples alongside Windows examples for fields such as hostnames, usernames, application paths, and OS types (e.g., show 'ubuntu-server', '/usr/bin/sshd', 'root', etc.).
  • Mention Linux/Unix formats (e.g., FQDN as 'host.example.com', usernames without domains, application paths like '/usr/bin/bash') equally or before Windows formats where relevant.
  • Add references to Linux audit tools and patterns (e.g., auditd, syslog, journald) in relevant sections.
  • Clarify that the schema is OS-agnostic and provide guidance for mapping Linux/Unix audit events to the schema.
  • Where enumerated types or examples are given (e.g., OS, username type), explicitly list Linux/Unix values alongside Windows values.
GitHub Create Pull Request
Sentinel The Advanced Security Information Model (ASIM) Network Session normalization schema reference | Microsoft Docs ...main/articles/sentinel/normalization-schema-network.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Windows Examples Windows Format Preference
Summary
The documentation demonstrates a subtle Windows bias. Windows-specific formats (such as domain\hostname) are mentioned before or alongside standard FQDN formats, and Windows examples (e.g., C:\Windows\explorer.exe, DESKTOP-1282V4D) are used for hostnames and process names. Windows-centric terminology (domain, GUID, SIDs) is prevalent, and references to Windows tools and conventions appear more frequently than Linux equivalents. Linux is mentioned only in passing, often as an afterthought, and no Linux-specific examples (e.g., /usr/bin/sshd, linux hostnames, process IDs) are provided.
Recommendations
  • Include Linux-specific examples for fields such as process names (e.g., /usr/bin/sshd), hostnames (e.g., ubuntu-server), and process IDs.
  • Present FQDN formats and Linux conventions before or alongside Windows formats, rather than defaulting to Windows-first.
  • Add explicit references to Linux tools and patterns (e.g., systemd, /etc/hostname, UID/GID formats) where relevant.
  • Ensure that field descriptions and examples are OS-neutral or provide parity between Windows and Linux.
  • Where Windows-specific terminology is used (e.g., domain\hostname, SIDs), provide Linux equivalents (e.g., FQDN, UID/GID) and clarify cross-platform applicability.
GitHub Create Pull Request
Sentinel The Advanced Security Information Model (ASIM) Process Event normalization schema reference | Microsoft Docs ...rticles/sentinel/normalization-schema-process-event.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Windows Examples Windows Terms
Summary
The documentation page exhibits a moderate Windows bias. Many field examples use Windows paths (e.g., C:\Windows\explorer.exe), Windows usernames, and Windows-specific terms. Windows concepts such as integrity levels and User Access Control (UAC) are described in detail, with references to Microsoft documentation. Linux is mentioned only in passing, typically in notes about converting data types, and there are no Linux-specific examples, terms, or references. The documentation assumes familiarity with Windows conventions and tools, and does not provide Linux equivalents or parity in examples.
Recommendations
  • Add Linux-specific examples for process names, paths (e.g., /usr/bin/bash), and command lines.
  • Include references to Linux process concepts (e.g., SELinux context, capabilities) where relevant.
  • Describe Linux equivalents for Windows-specific fields, such as integrity levels and UAC, or clarify their applicability.
  • Provide sample queries and field values using Linux conventions and users.
  • Balance documentation by mentioning Linux and Windows tools, patterns, and terminology equally.
  • Clarify which fields are applicable to Linux, Windows, or both, and provide guidance for normalization across platforms.
GitHub Create Pull Request
Sentinel Microsoft Sentinel user management normalization schema reference | Microsoft Docs ...icles/sentinel/normalization-schema-user-management.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Windows Examples Priority
Summary
The documentation demonstrates a Windows bias by consistently listing Windows-specific formats (such as SID, domain\username, and Windows session ID requirements) before Linux equivalents (UID, simple username), and by providing Windows-centric examples and normalization recommendations. Windows terminology and patterns (such as domain\username, SID, and session ID conversion requirements) are emphasized, while Linux is mentioned as an alternative or secondary option. No Linux-specific tools, patterns, or examples are provided, and Windows formats are often described as the default or preferred.
Recommendations
  • Alternate the order of Windows and Linux examples and formats to avoid implying priority.
  • Provide Linux-specific examples (e.g., UID, username formats, session IDs) alongside Windows examples.
  • Include normalization recommendations for Linux systems, not just Windows.
  • Add explicit references to Linux tools and patterns where relevant (e.g., mention /etc/passwd, getent, or Linux group management commands).
  • Ensure that guidance for converting or normalizing values applies equally to Linux and Windows, with examples for both.
  • Where session ID conversion is mentioned for Windows, clarify Linux requirements and provide Linux conversion examples if applicable.
GitHub Create Pull Request
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 →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation is strongly Windows-centric, focusing exclusively on Windows Registry events and referencing only Windows-specific concepts, tools, and examples. There are no Linux equivalents or cross-platform considerations provided, and all examples, terminology, and references are Windows-specific.
Recommendations
  • Explicitly state that the schema is Windows-only, or clarify cross-platform applicability if relevant.
  • If Linux or other platforms have registry-like concepts (e.g., dconf, gsettings), mention their absence or provide guidance for analogous monitoring.
  • Add a section comparing Windows Registry monitoring to Linux/macOS system configuration monitoring, even if only to clarify differences.
  • Provide examples or references for how Linux systems might be monitored for similar persistence or configuration changes, if applicable.
  • Where fields are described as supporting both Windows and Linux (e.g., process IDs), clarify Linux-specific behaviors or provide Linux-centric examples.
GitHub Create Pull Request
Sentinel Microsoft Sentinel network normalization schema (Legacy version - Public preview)| Microsoft Docs ...blob/main/articles/sentinel/normalization-schema-v1.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
🔧 Windows Tools Windows First Windows Examples Missing Linux Example
Summary
The documentation exhibits Windows bias through the use of Windows-centric terminology, examples, and references. File paths (e.g., C:\Malicious\ImNotMalicious.exe), device names (e.g., Ethernet adapter Ethernet 4), and user agent strings (e.g., Mozilla/5.0 (Windows NT 10.0; WOW64)) are all Windows-specific. There is no mention of Linux or Unix equivalents, nor are Linux-style file paths, network interface names, or user agents provided. The schema and examples prioritize Windows conventions and tools, with no parity for Linux environments.
Recommendations
  • Include Linux/Unix examples alongside Windows ones, such as file paths (/home/user/malicious.sh), network interfaces (eth0, wlan0), and user agent strings from Linux browsers.
  • Add notes or guidance for Linux-specific ingestion methods and data types, especially where Log Analytics or other ingestion tools may differ.
  • Ensure terminology is platform-neutral (e.g., 'network interface' instead of 'Ethernet adapter'), or provide both Windows and Linux terms.
  • Where device or domain names are given, use examples that reflect both Windows (e.g., WORKGROUP, CONTOSO) and Linux (e.g., ubuntu-server, example.org) conventions.
  • Explicitly mention Linux support and provide links or references to Linux-focused documentation or best practices.
GitHub Create Pull Request
Sentinel Jupyter notebooks with Microsoft Sentinel hunting capabilities ...cs/azure-docs/blob/main/articles/sentinel/notebooks.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First Powershell Heavy Missing Linux Example
Summary
The documentation page demonstrates a Windows bias primarily by referencing Windows-centric tools and workflows, such as PowerShell and the Azure portal, without providing Linux-specific equivalents or examples. Where command-line access is mentioned, PowerShell is listed before Azure CLI, and there are no explicit Linux shell or cross-platform examples. The documentation assumes usage of Microsoft tools and platforms, which are more commonly used in Windows environments, and does not address Linux-specific considerations for Jupyter notebook deployment or usage.
Recommendations
  • Add explicit examples for Linux environments, such as bash shell commands for role assignments and notebook management.
  • When listing command-line tools, present Azure CLI and PowerShell together, or mention Azure CLI first, as it is cross-platform.
  • Include notes or sections on running Jupyter notebooks and MSTICPy on Linux VMs, including any differences in setup or package management.
  • Reference Linux-compatible authentication and access management methods alongside Windows-centric ones.
  • Provide troubleshooting tips or documentation links for common Linux issues when using Jupyter notebooks with Microsoft Sentinel.
GitHub Create Pull Request
Sentinel Manage access to Microsoft Sentinel data by resource ...s/blob/main/articles/sentinel/resource-context-rbac.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates Windows bias primarily by referencing Windows event data as the main example for resource-context RBAC and mentioning Windows administrators and Windows Security events before any Linux equivalents. There is no mention of Linux-specific event types (e.g., Linux audit logs) or examples for Linux administrators. Additionally, tools and patterns such as Syslog and CEF are mentioned, but only in the context of forwarding from VMs, with no explicit Linux-centric guidance or examples. The documentation lacks parity in providing Linux-specific scenarios, examples, or administrative roles.
Recommendations
  • Include Linux-specific examples, such as granting access to Linux audit logs or SSH logs for Linux administrators.
  • Mention Linux administrators alongside Windows administrators in scenarios and tables.
  • Provide sample configurations for Linux event forwarding (e.g., using rsyslog or auditd) and how resource-context RBAC applies.
  • Clarify that Syslog forwarding applies to both Windows and Linux sources, and provide explicit Linux VM examples.
  • Add parity in describing access requirements and patterns for both Windows and Linux teams.
GitHub Create Pull Request
Sentinel Sample Microsoft Sentinel workspace designs ...lob/main/articles/sentinel/sample-workspace-designs.md
High Priority View Details →
Scanned: 2026-01-11 00:00
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by consistently listing Windows data sources (e.g., Windows Security Events, Windows Events) before Linux equivalents (e.g., Syslog, CEF), and by referencing Windows-specific tools such as the Azure Monitoring Agent (AMA) primarily in the context of Windows VMs. There are no explicit examples or guidance for collecting Linux-specific logs (such as syslog or auditd) or for configuring Linux agents, and Linux collection patterns are not described in detail. The documentation also lacks parity in describing how Linux data sources are onboarded, routed, or managed compared to Windows.
Recommendations
  • Include explicit examples and guidance for collecting logs from Linux VMs, such as syslog, auditd, or other Linux-specific sources.
  • Describe how the Azure Monitoring Agent (AMA) can be used on Linux VMs, including configuration steps and routing options.
  • Provide Linux-focused workspace design scenarios, or ensure that existing scenarios mention Linux alongside Windows when discussing data sources and agent deployment.
  • List Linux data sources (e.g., syslog, CEF) alongside Windows sources, and avoid always mentioning Windows first.
  • Add references to Linux documentation and troubleshooting guides for Sentinel workspace onboarding.
GitHub Create Pull Request
← Previous Page 2 of 20 Next →