Practical insights from real engagements — configuration references, architectural decisions, and lessons learned in production environments.
Conditional Access is the enforcement engine of Zero Trust identity — but poorly scoped policies can lock out users, break service accounts, and generate a flood of helpdesk tickets. This article walks through a deployment methodology we use on every identity engagement: report-only validation, phased rollout, and the specific policy ordering that prevents the most common production incidents.
We cover the baseline policy set we deploy for every client (legacy auth block, MFA enforcement, location-based controls), how to handle service accounts and break-glass scenarios, and the sign-in log queries we use to validate policy impact before switching from report-only to enforced.
Running two SIEM platforms sounds redundant until you understand what each one does well. Wazuh excels at agent-based endpoint detection — file integrity monitoring, rootkit detection, and CIS compliance scanning. Splunk excels at log aggregation, correlation, and dashboarding at scale. This article documents the architecture we deploy when clients need both capabilities without the licensing cost of a single enterprise SIEM that does everything.
We cover the integration pattern (Wazuh alerts to Splunk via CEF syslog), how to avoid duplicate alerting, index design in Splunk for multi-source correlation, and the detection rules we build on top of this architecture mapped to MITRE ATT&CK.
After hardening dozens of AD environments, patterns emerge. This article covers the five most common Active Directory security findings we encounter on penetration test reports and how we remediate each one: excessive Domain Admin membership, Kerberoastable service accounts, missing LAPS, disabled audit logging, and NTLMv1 still in use.
For each finding, we provide the PowerShell commands to identify the issue, the remediation steps, and the GPO or PSO configuration required to close the gap. These are not theoretical — they are the exact remediations we implement on client engagements.
Configuration management tools like Ansible and Puppet are the right choice for large-scale environments, but many of our clients operate server fleets in the 20–50 range where the overhead of a full CM platform isn't justified. For these environments, we've developed a modular Bash hardening toolkit that can be version-controlled, audited, and executed idempotently.
This article walks through the architecture of the toolkit — OS detection, module structure, dry-run mode, and compliance reporting — with code samples for SSH hardening, firewall configuration, auditd rules, and kernel parameter tuning. We also cover how we integrate the toolkit into server provisioning workflows.
Azure AD Privileged Identity Management (PIM) is straightforward to enable but requires careful configuration to be operationally effective. Activation duration, approval workflows, MFA requirements, and notification settings all influence whether PIM becomes a security control or a rubber-stamp process.
This article documents the PIM configuration decisions we make on identity engagements — why we set 8-hour activation windows for most roles, why Global Admin activations require approval while User Admin activations don't, and how we configure access reviews to catch privilege drift without creating review fatigue.
The Linux audit daemon is one of the most powerful security monitoring tools available on any Linux system — and one of the most underutilized. The default installation monitors almost nothing. This article provides a production-ready auditd ruleset with explanations for each rule category: privileged command execution, identity file modifications, kernel module operations, network configuration changes, and unauthorized file access attempts.
We also cover performance considerations (auditd can impact I/O-heavy workloads if configured carelessly), log rotation, and how to forward audit logs to a centralized SIEM via rsyslog.