Virtology

  Windows Server 2025: Secure Single-DC Domain Build (Contoso.com) A start-to-finish, production-grade guide for deploying a fully secured Windows Server 2025 Domain Controller holding all FSMO roles , with DNS (DNSSEC) , DHCP , and Certificate Services , designed as the first and only DC in the domain. Architecture Overview Domain: contoso.com Server Name: DC01 Server IP: 10.10.10.224/24 Gateway: 10.10.10.1 Roles Installed: Active Directory Domain Services (AD DS) DNS Server (DNSSEC enabled) DHCP Server Active Directory Certificate Services (AD CS) Security Design Principles Applied: Tier 0 hardening Secure DNS with DNSSEC Least privilege Secure service bindings Modern crypto defaults No legacy protocols Phase 1 – Base OS Preparation 1. Install Windows Server 2025 Install Windows Server 2025 (Standard or Datacenter) Choose Desktop Experience Use NTFS for system volume Apply all Windows Updates 2. Rename the Server Rename-Computer -NewName DC01 -Restart 3. Configure Static IP...

  The Incident That Ties It All Together A Multi-Stage Security Event, From First Signal to Final Fix What You Will Learn From This Walkthrough This section shows what security looks like while it’s happening , not after the fact. By the time you finish this walkthrough, you will understand: How a real incident unfolds incrementally over time How alerts, logs, and human judgment interact at each stage Why not every alert is an emergency — and when one becomes critical How containment can stop damage without destroying evidence How a single incident improves detection, response, and confidence How architecture directly affects MTTD and MTTR Most importantly, you’ll learn how a security engineer thinks while an incident is still unfolding . Beginner Callout — Why This Section Matters Most security content explains tools. This section explains decision-making under uncertainty . Incident Timeline Overview Everything that follows maps directly to this ...

  Chapter Five Expanded: Beyond the Playbook What You Will Learn By the end of this chapter, you will understand: What a security playbook really is and why it is only the starting point Who uses playbooks at each stage of incident response and operations How playbooks evolve into repeatable, measurable operational workflows When to rely on automation versus human judgment Where metrics, training, and feedback loops fit into daily engineering work How all of these components combine into a mature operational system Why this process fundamentally makes you a stronger, calmer, and more effective engineer This chapter is written for engineers who are moving from building systems to operating systems under pressure . 1. The Playbook Is the Beginning, Not the Goal What A playbook is a documented response pattern for a known or anticipated event. It defines: What triggered the response What information must be gathered What decisions must be made What actions are allowed or required Who...

  Playbook 002: Confirmed Suspicious Activity (Escalation & Containment) This playbook builds directly on Playbook 001 . You open it only after you’ve determined that activity is likely not normal — even if you’re not 100% certain it’s malicious. That uncertainty is expected. Purpose To guide your response when: Activity is ongoing and Normal explanations no longer fit and Inaction could increase risk This playbook focuses on controlled escalation , not panic response. Trigger (When to Use This Playbook) Open this playbook when one or more of the following is true: Repeated abnormal behavior across multiple time windows A system attempts lateral movement across VLANs Multiple alerts correlate to the same source A system behaves outside its defined role Blocking one path causes the behavior to shift elsewhere This is your signal that something is actively trying — not just misbehaving. Context (Confirm the Scope) Before acting, clear...

How a Playbook Fits Into the Architecture High-Level Concept The playbook is not a tool The playbook is the decision path between tools Tools generate signals. The playbook tells you what to do with them. Architecture-to-Playbook Flow (Visual) ┌───────────────────────┐ │ Network & Systems │ │ (Endpoints, Servers, │ │ Firewalls, VLANs) │ └───────────┬───────────┘ │ │ Logs / Events ▼ ┌───────────────────────┐ │ SIEM │ │ (Central Visibility) │ │ - Correlation │ │ - Detection Rules │ └───────────┬───────────┘ │ │ Alert / Anomaly ▼ ┌───────────────────────┐ │ PLAYBOOK ENTRY │ │ "Something Happened" │ │ │ │ - Which alert? │ │ - Which system ? │ │ - Which boundary? │ └───────────┬───────────┘ │ │ Guided Questions ▼ ┌───────────────────────┐ │ CONTEXT GATHERING │ │ ...

  Your First-Ever Security Playbook If you’ve never used a playbook before, this one is intentionally simple. Its job is not to make you fast. Its job is to make you calm, consistent, and correct . You will improve it over time. That’s expected. Playbook 001: Unusual Network Activity Detected Purpose To guide your response when the monitoring system reports network behavior that doesn’t look normal. This is one of the most common starting points for security investigations. Trigger (Why You’re Here) You open this playbook when any one of the following happens: Your SIEM raises an alert about unexpected traffic You see repeated firewall denies from the same source A system is communicating with networks it normally doesn’t East-west traffic appears where none existed before If you’re unsure whether the alert matters, that’s normal . This playbook helps you figure that out. Context (Understand Before Acting) Before touching anything, answer these quest...

  What a Playbook Is — and Why You Need One If you’re new to operational security or lab design, the word playbook can sound abstract or overly “enterprise.” It isn’t. A playbook is simply a written plan that tells you what to do when something specific happens . Not theory. Not best practices. Actual steps. Think of it as the difference between: “I know how firewalls work” and “Here’s exactly what I do when the firewall detects something suspicious.” This lab is designed to teach the second one. Why This Lab Needs Playbooks (Even If You’re Just Learning) This environment isn’t a single flat network with one server and a router. It has: Multiple VLANs Defined trust boundaries Centralized logging Monitoring and alerting Recovery paths That’s intentional. But once you add structure, you also add decision points . When an alert fires, you must decide: Is this normal? Is this a misconfiguration? Is this a real incident? What do I t...