What Zero Trust Actually Means

The traditional “castle-and-moat” security model assumed everything inside the network was safe. Zero Trust flips this: trust is never implicit, always earned. The core principles are:

• Verify explicitly — always authenticate and authorize based on all available data points
• Use least privilege access — limit user access with just-in-time and just-enough access
• Assume breach — minimize blast radius and segment access to limit lateral movement

“Zero Trust is not a product you buy — it’s an architecture you build. Start small, prioritize identity, and iterate.”

Step 1: Start with Identity

Identity is the new perimeter. Before you touch anything else, get your identity infrastructure solid. This means deploying Multi-Factor Authentication (MFA) everywhere, using a centralized identity provider (IdP), and enforcing conditional access policies.

For Microsoft shops, Azure AD (now Entra ID) is the obvious choice. For Google Workspace environments, Google Cloud Identity works similarly. Both support Conditional Access policies that can enforce MFA, device compliance checks, and sign-in risk scoring.

Step 2: Inventory and Classify Your Assets

You can’t protect what you can’t see. Run an asset discovery scan across your environment. Tools like nmap, Lansweeper, or even the built-in Windows SCCM can give you a full picture of what’s on your network. Once you have the list, classify assets by sensitivity:

# Quick nmap host discovery scan
nmap -sn 192.168.1.0/24 -oG - | grep "Status: Up" | cut -d " " -f2

# Export to CSV for asset tracking
nmap -sn 192.168.1.0/24 --open -oX assets.xml
xsltproc nmap.xsl assets.xml > assets.csv

Step 3: Micro-segment Your Network

Network segmentation is a core Zero Trust control. Instead of one flat network, break it into segments — servers, endpoints, IoT devices, guest Wi-Fi — each with explicit firewall rules. On a tight budget, this can be done with VLANs on a managed switch and firewall ACLs.

The goal is to ensure that if an attacker compromises a device on one segment, they can’t freely move to others. Even basic segmentation (servers separate from workstations) dramatically reduces your attack surface.

Step 4: Device Compliance Checking

Zero Trust requires knowing the health of devices before granting access. This means checking for:

• OS patch level (is the device up to date?)
• Endpoint protection (is antivirus/EDR running and current?)
• Disk encryption (is BitLocker/FileVault enabled?)
• Jailbreak/root detection for mobile devices

Microsoft Intune and Jamf handle this for managed fleets. For unmanaged or BYOD devices, conditional access policies can block or limit access until compliance is confirmed.

The Bottom Line

Zero Trust doesn’t happen overnight. Pick one pillar — start with Identity — and harden it completely before moving to the next. The journey matters more than reaching a theoretical “Zero Trust complete” state, which doesn’t really exist. Keep iterating, keep monitoring, and assume the breach is already happening.

The post Zero Trust Architecture: A Practical Implementation Guide for SMBs appeared first on InfoTech Ninja.

Why AD Defaults Are an Attacker’s Dream

Out of the box, Active Directory ships with configurations that made sense in the early 2000s but are dangerous today. Pre-Windows 2000 compatibility groups, default permissive ACLs on objects like AdminSDHolder, unrestricted Kerberos delegation, and the universal availability of NTLM authentication all create conditions that attackers exploit with freely available tools like BloodHound, Mimikatz, and Impacket.

BloodHound analysis on a typical enterprise AD environment consistently reveals hundreds of unintended privilege escalation paths — most of them created not by attackers, but by years of accumulated admin shortcuts. A user gets added to Domain Admins “temporarily” and never removed. A service account gets unnecessary replication rights. These misconfigurations compound over time, and without deliberate hardening, your AD becomes a house of cards.

Implement a Tiered Administration Model

Microsoft’s tiered administration model (also called the Enterprise Access Model) separates administrative access into three distinct tiers. Tier 0 covers your most critical assets: domain controllers, ADFS servers, PKI infrastructure, and identity management systems. Tier 1 covers server workloads and applications. Tier 2 covers end-user workstations and devices. Credentials from a lower tier must never be able to access a higher tier.

Privileged Access Workstations (PAWs) are a critical implementation detail. Tier 0 administrators should only perform privileged actions from dedicated, hardened workstations that are not used for email, web browsing, or general productivity work. These PAWs should be enrolled in their own OU with restrictive GPOs, application whitelisting via AppLocker or WDAC, and credential guard enabled. Yes, it adds friction — that friction is the point.

Lock Down NTLM and Legacy Protocols

NTLM is responsible for more lateral movement and credential relay attacks than almost any other protocol in Windows environments. Pass-the-Hash, NTLM relay (via tools like Responder + ntlmrelayx), and credential capture attacks all depend on NTLM being available. The good news: you can audit and progressively restrict it without breaking things, if you’re systematic about it.

Start by auditing who is using NTLM and why. Enable NTLM auditing via Group Policy, collect the logs in your SIEM, and identify which applications still require it. Modern applications should use Kerberos. Once you’ve cleaned up the dependencies, move to restricting outbound NTLM from workstations and eventually enabling the “Deny all” policy on DCs. Don’t rush this — a phased approach prevents outages.

# Audit NTLM authentication events via PowerShell
# Enable NTLM auditing first via GPO:
# Security Settings > Local Policies > Security Options
# "Network security: Restrict NTLM: Audit NTLM authentication in this domain" = Enable all

# Then query the Security event log for NTLM events (Event ID 8004)
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" |
    Where-Object { $_.Id -eq 8004 } |
    Select-Object TimeCreated,
        @{N='User';E={$_.Properties[0].Value}},
        @{N='Workstation';E={$_.Properties[1].Value}},
        @{N='TargetServer';E={$_.Properties[2].Value}} |
    Sort-Object TimeCreated -Descending |
    Export-Csv -Path "C:\Logs\ntlm-audit.csv" -NoTypeInformation

Write-Host "NTLM audit exported to C:\Logs\ntlm-audit.csv"

Privileged Access Controls That Actually Work

Local Administrator Password Solution (LAPS) should be non-negotiable in any environment with more than a handful of machines. Without LAPS, local administrator accounts typically have the same password across all machines — one credential compromise means every workstation is owned. LAPS rotates unique passwords per machine and stores them in AD with ACL-controlled access. Microsoft LAPS (the updated version shipping with Windows 2022/11) adds even more capability including managed service account support.

Just-in-Time (JIT) administration takes privilege reduction further by eliminating standing privileged access entirely. Instead of accounts permanently in Domain Admins, admins request elevated access for a specific time window and purpose. Microsoft Privileged Identity Management (PIM) in Entra ID handles this for cloud/hybrid scenarios. For pure on-prem, Microsoft Identity Manager or third-party PAM solutions like CyberArk or BeyondTrust can provide JIT. The Protected Users security group is a quick, free win — adding privileged accounts to it disables NTLM, DES, and RC4 Kerberos, and prevents credential caching.

The post Active Directory Hardening: 10 Security Controls You Should Implement Today appeared first on InfoTech Ninja.

Why Roll Your Own SIEM?

Splunk’s licensing model charges per daily ingest volume — at enterprise scale, costs climb quickly into six figures annually. Microsoft Sentinel charges per GB ingested into Log Analytics. For a 500-seat organization generating 50GB of logs per day, these costs add up fast. The open-source alternative — Elastic Stack plus Wazuh — can run on commodity hardware or modest cloud VMs for a fraction of the licensing cost, with the trade-off being that you manage the infrastructure yourself.

Beyond cost, running your own SIEM gives you full control over data residency, retention policies, and detection logic. You’re not constrained by vendor rule update schedules or limited API access. The Elastic SIEM interface (now called Elastic Security) has grown significantly and provides timeline investigation, anomaly detection via machine learning, and prebuilt detection rules that track the MITRE ATT&CK framework.

Standing Up the Elastic Stack

The core stack is Elasticsearch (the search and analytics engine), Logstash or Elastic Agent (data ingestion), and Kibana (the visualization and UI layer). For a lab or small production deployment, a single VM with 8+ cores, 32GB RAM, and fast SSD storage works well. For production with high ingest rates, plan for a multi-node cluster. Elastic provides official APT and YUM repositories making installation straightforward on Debian/Ubuntu or RHEL/CentOS systems.

Security hardening from day one is critical. Enable TLS on all inter-node and client-facing communications, configure Elasticsearch security features (formerly X-Pack), set up role-based access control, and put Kibana behind a reverse proxy like nginx with authentication. An unsecured Elasticsearch instance exposed to the internet is a data breach waiting to happen — this has happened to real organizations and made headlines.

# Install Elastic Stack on Ubuntu 22.04
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | \
    sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] \
https://artifacts.elastic.co/packages/8.x/apt stable main" | \
    sudo tee /etc/apt/sources.list.d/elastic-8.x.list

sudo apt-get update

# Install Elasticsearch
sudo apt-get install -y elasticsearch

# Capture the auto-generated password from first start
sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic

# Install Kibana
sudo apt-get install -y kibana

# Generate enrollment token for Kibana
sudo /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s kibana

# Enable and start services
sudo systemctl enable --now elasticsearch kibana

Connecting Wazuh as Your Security Engine

Wazuh is an open-source security platform that functions as a HIDS (Host Intrusion Detection System), vulnerability detector, log analysis engine, and compliance framework. It deploys as a central manager with lightweight agents on each endpoint. The agents collect logs, monitor file integrity, detect rootkits, and enforce security policies. Wazuh then forwards enriched security events into Elasticsearch, where Kibana dashboards surface actionable alerts.

Wazuh ships with thousands of out-of-the-box detection rules mapped to MITRE ATT&CK techniques. These cover everything from brute-force detection and privilege escalation attempts to web application attacks and malware execution patterns. The ruleset is actively maintained and updated regularly. You can also write custom rules in a simple XML format — useful for application-specific log sources or internal tooling that Wazuh doesn’t know about natively.

Correlation Rules and Alert Tuning

Raw alerts without tuning are noise. The first two weeks after standing up a SIEM are critical for establishing a baseline and suppressing false positives from known-good behavior. Wazuh supports active response (automatic actions triggered by alerts), alert thresholds, and exception lists. Start by identifying your top 10 highest-volume alert types and determining which are actionable versus noise. Create exclusions for known-good patterns before they bury your real alerts.

Sigma rules provide a vendor-neutral format for detection logic that can be converted to Elasticsearch queries, Splunk SPL, or other backend formats. The SigmaHQ repository on GitHub contains thousands of community-contributed detection rules covering Windows, Linux, network, and application log sources. Integrating Sigma into your Elastic SIEM workflow lets you pull in community detections without writing every rule from scratch and keeps your detection library current with emerging threat intelligence.

The post Setting Up a SIEM on a Budget with Elastic Stack and Wazuh appeared first on InfoTech Ninja.

The Secure Score Trap

Secure Score is a useful starting point — it measures your security posture against Microsoft’s recommendations and gives a percentage that’s easy for leadership to latch onto. The problem is that it’s a compliance checklist, not a threat model. A subscription can have a 90% Secure Score and still have misconfigured network security groups, overprivileged managed identities, or unmonitored storage accounts full of sensitive data. Score gaming is easy; genuine security improvement takes more work.

Use Secure Score as a prioritization tool, not a goal. Filter recommendations by severity and impact. Focus on “High” severity findings first — these represent genuine attack vectors, not stylistic preferences. Pay particular attention to the Identity and Access recommendations: disabling legacy authentication protocols, enabling MFA for all users, and removing unused service principals are consistently high-impact, low-complexity wins that significantly reduce your real attack surface.

Workload Protections That Actually Matter

Defender for Cloud’s paid Workload Protection Plans extend protection to specific resource types: servers (via Defender for Servers), SQL databases, Kubernetes clusters, App Service, Storage accounts, Key Vault, and more. Defender for Servers is often the highest-value plan — it enables just-in-time VM access, adaptive application controls, file integrity monitoring, and integrates with Microsoft Defender for Endpoint for EDR capability on Azure VMs.

Defender for Storage is frequently overlooked but deserves attention. It monitors blob, file, and queue storage for anomalous access patterns — things like unusual geographic access, access from Tor exit nodes, or malware uploads detected via hash reputation. Defender for Key Vault detects unusual access patterns to your secrets, keys, and certificates and can alert on potentially compromised service principals trying to exfiltrate credentials.

Just-in-Time VM Access

Just-in-time (JIT) VM access is one of Defender for Cloud’s most practically useful features. Instead of leaving RDP (port 3389) or SSH (port 22) open to the internet or your entire corporate network, JIT locks down management ports and only opens them on-demand for a specific source IP and time window. The access request goes through Azure RBAC, creates an NSG rule, and automatically reverts after the time window expires. This dramatically reduces your exposure to brute-force and credential stuffing attacks.

Enabling JIT is straightforward from the Defender for Cloud portal or via the Azure CLI. For organizations managing many VMs, you can deploy JIT policy via Azure Policy to ensure all new VMs automatically get the protection. Note that JIT requires Defender for Servers Plan 2. The audit trail — who requested access, from where, and when — feeds into your SIEM via Azure Monitor, giving you a complete record of privileged management access.

# Enable JIT VM access via Azure CLI
# Requires Defender for Servers Plan 2

# Define JIT policy for a VM (RDP on 3389, SSH on 22)
$jitPolicy = @{
    "kind" = "Basic"
    "properties" = @{
        "virtualMachines" = @(
            @{
                "id" = "/subscriptions/SUB-ID/resourceGroups/RG-NAME/providers/Microsoft.Compute/virtualMachines/VM-NAME"
                "ports" = @(
                    @{ "number" = 3389; "protocol" = "TCP"; "allowedSourceAddressPrefix" = "*"; "maxRequestAccessDuration" = "PT3H" },
                    @{ "number" = 22;   "protocol" = "TCP"; "allowedSourceAddressPrefix" = "*"; "maxRequestAccessDuration" = "PT3H" }
                )
            }
        )
    }
}

# Apply via portal: Defender for Cloud > Workload protections > Just-in-time VM access > Configure

Connecting Defender to Microsoft Sentinel

Defender for Cloud’s alerts become significantly more powerful when correlated with other signals in Microsoft Sentinel. Enabling the Defender for Cloud data connector in Sentinel streams all alerts, security recommendations, and regulatory compliance assessments into Sentinel’s Log Analytics workspace. From there, Sentinel’s analytics rules can correlate a Defender alert with Azure AD sign-in anomalies, network flow data, and endpoint telemetry to surface attacks that span multiple signal types.

Sentinel’s playbooks (Azure Logic Apps) allow automated response to Defender alerts. A common workflow: when Defender detects a brute-force attack on a VM, a playbook automatically triggers JIT to revoke current access, posts a Teams notification to the security team, creates an incident in ServiceNow, and runs a diagnostic script on the VM to capture in-memory forensics. Building these automation chains transforms Defender from a passive alert system into an active response platform.

The post Microsoft Defender for Cloud: Moving Beyond the Dashboard appeared first on InfoTech Ninja.