Metrics Library

This is a community-led space where Liongard users can come to teach and learn from one another. Share custom Metrics, get inspired and see what’s trending in the Pride.
Windows Server: Check if Network Card is DHCP or Static
Category: Network Configuration MetricsDescription:This metric determines whether a Windows server’s network interface card (NIC) is configured for DHCP (Dynamic Host Configuration Protocol) or a static IP address.Purpose:To assist IT Organizations in quickly identifying network configurations that may impact connectivity, troubleshooting, or compliance with established best practices.Use Cases:Network Troubleshooting: Quickly identify misconfigurations that may cause connectivity issues, such as an incorrect static IP or unexpected use of DHCP.Compliance and Best Practices Audits: Validate server configurations during routine maintenance to ensure compliance with organizational or client-specific standards.Change Management: Verify that static IP assignments remain consistent after server migrations or network changes.Proactive Monitoring: Identify servers inadvertently set to DHCP when they should use static IPs, avoiding potential downtime.Client Documentation and Reporting: Provide detailed reports to clients on their server configurations, highlighting potential risks or misalignments.How it works:The metric uses JMESPath to parse data from the Liongard Windows Server Inspector. It evaluates the server’s IPEnabled and DHCPEnabled fields and outputs the NIC’s configuration as either "DHCP Enabled" or "Static Enabled."Beneficiaries:MSPs: Gain clarity on network configurations to support client environments effectively.IT Administrators: Ensure server network settings align with enterprise requirements.End Clients: Benefit from improved uptime and compliance with best practices.Notes for Customization:Additional Enhancements:Expand Output Details: Include related data such as DNSHostName, IPAddressStr, IPSubnetStr, or MACAddress to provide a fuller picture of the network configuration.Highlight Inconsistencies: Flag specific conditions, such as DHCP being enabled on a server in a static IP-restricted subnet.Why Modify:Deeper Insights for MSPs: Expanded details allow technicians to address broader configuration issues or validate against complex network requirements.Faster Resolution Times: By incorporating more data, you can reduce the need for follow-up investigations, saving time during troubleshooting or audits.Client-Specific Policies: Tailoring the metric to client-specific requirements (e.g., all servers in a DMZ must have static IPs) can enhance the value your organization delivers. Network.Configuration[?IPEnabled== true ].[['Name:'Description], [replace(to_string('DHCPEnabled'), 'true', 'DHCP Enabled') | replace(to_string('DHCP is Enabled'), 'false', 'Static is Enabled')],['--']][]
0
·
submitted
Windows Server: AV/EDR - Sophos, Huntress, Defender Installed
Windows Server: Software Compliance - Sophos, Huntress, Defender InstalledCategory: Software ComplianceDescription:This metric pulls a list of all installed software from endpoints, specifically filtering for security-related software such as Sophos, Huntress, and Microsoft Defender. It displays both the software name and its version number.Purpose:The purpose of this metric is to ensure that critical security software is installed, up to date, and actively running on devices in the environment. This helps to maintain a robust security posture by confirming the presence of essential endpoint protection solutions.How It Works:The metric queries the software inventory from connected endpoints using JMESPath. It filters for software whose name contains "Sophos," "Huntress," or "Defender" and then returns the Name and DisplayVersion fields for each match. This allows teams to monitor the specific security software deployed across their managed devices.Beneficiaries:MSPs (Managed Service Providers): To ensure compliance with endpoint security policies.Security Teams: To track the versioning and presence of endpoint protection software.Compliance Officers: To verify that security software requirements are met for regulatory or internal audit purposes.Notes for Quick Modifications:Add more security vendors: You can quickly expand this metric to include other security solutions by simply appending more software names in the contains(Name, 'YourSoftware') part of the query.Filter by specific versions: If there is a need to ensure all devices run a particular version of the software, you can add an additional filter for DisplayVersion in the query.Why Make Changes:Customizing for your toolset: If your organization uses additional security tools beyond Sophos, Huntress, or Defender, expanding the query ensures those tools are monitored as well.Version-specific filtering: Keeping software updated is a critical security task, so adding version-specific checks will help ensure all endpoints run the latest secure versions. Software[?contains(Name,'Sophos') || contains(Name,'Huntress') || contains(Name,'Defender')].[['Name:'Name], ['Version:'DisplayVersion],['--']][]
0
·
submitted
Windows Server: Excessive Failed Logon Alerts (Last 2 Weeks)
Metric Name: Windows Server: Windows Server: Excessive Failed Logon Alerts (Last 2 Weeks)Category: Windows ServerDescription: This metric is designed to identify and report on local account logon failures that exceed one attempt within the past two weeks on Windows Servers. It provides critical security information, including the account name, number of failed logon attempts, the date of the last failed logon, and the time elapsed since the last failed attempt. This information is essential for identifying potential security risks or breach attempts on local accounts.Purpose: Monitoring failed logon attempts is vital for early detection of unauthorized access attempts and potential security threats. This metric helps IT security teams to quickly respond to and investigate unusual login behaviors, enhancing the security posture of the organization.How It Works: The metric filters user account data to identify accounts with more than one failed login attempt in the last 14 days. It then displays relevant details such as the user's full name, count of failed logon attempts, the date of the last successful logon, and days since the last bad password attempt. This allows for timely and focused security assessments and interventions.Beneficiaries: This metric is particularly beneficial for IT security and administrative teams tasked with safeguarding Windows Server environments. It aids in compliance with security policies that require monitoring and addressing failed access attempts to prevent potential breaches. Enhancing the "Windows Server: Excessive Failed Logon Alerts (Last 2 Weeks)" Metric 1. Adjusting the Time Frame:Current Setting: Last 2 weeks.Modification: You can modify the timeframe to be more or less restrictive, such as the last 7 days or the last 30 days, depending on the security monitoring needs of your organization.Value: Shorter timeframes might be useful for high-security environments where frequent monitoring is critical, whereas longer timeframes could be better for trend analysis and less critical systems.2. Varying the Threshold for Alerts:Current Setting: More than one failed attempt.Modification: Change the threshold for what constitutes an excessive number of failed logon attempts—either increasing or decreasing the number.Value: Higher thresholds may reduce the number of alerts, minimizing alarm fatigue among IT staff. Lower thresholds increase sensitivity to potential unauthorized access, enhancing security but potentially increasing the volume of alerts.3. Including Additional Data Points:Current Setting: Username, count of failed attempts, last successful logon, days since the last attempt.Modification: Include additional details such as IP address of access attempt, geographic location, or device type.Value: This provides more context for each alert, aiding in quicker and more accurate responses to potential security incidents. It helps in identifying patterns or common sources of attacks. Users[?BadLogonCount > '1' && time_since(LastBadPasswordAttempt, 'days') < 14 ].[['--'],['UserName:'FullName], ['Failed Logon Attempts:'BadLogonCount],['Last Successful Logon Date:'LastLogon],['Days Since Last Failed Logon Attempt:' time_since(LastBadPasswordAttempt, 'days')]][]
0
·
submitted
Load More