Name: Blue Team Handbook SOC, SIEM, and Threat Hunting (for Raymond Rhine) (Don Murdoch) (z-library.sk, 1lib.sk, z-lib.sk)
Author: Unknown Author

Page 1

(This page has no text content)

Page 2

Blue Team Handbook: SOC, SIEM, and Threat Hunting Practical Techniques for Security Operations and Threat Hunting Teams With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles. Don Murdoch

Page 3

Blue Team Handbook: SOC, SIEM, and Threat Hunting by Don Murdoch Copyright © 2026 Don Murdoch. All rights reserved. Published by O’Reilly Media, Inc., 141 Stony Circle, Suite 195, Santa Rosa, CA 95401. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (https://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Acquisitions Editor: Simina Calin Development Editor: Jill Leonard Production Editor: Kristen Brown Cover Designer: Susan Brown Cover Illustrator: José Marzan Jr. Interior Designer: David Futato Interior Illustrator: Kate Dullea June 2026: First Edition Revision History for the Early Release 2026-02-19: First Release See https://oreilly.com/catalog/errata.csp?isbn=9798341662292 for release details.

Page 4

The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Blue Team Handbook: SOC, SIEM, and Threat Hunting, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the author and do not represent the publisher’s views. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights. 979-8-341-66229-2 [LSI]

Page 5

Brief Table of Contents (Not Yet Final) Preface (available) Chapter 1: Security Operation Center Field Notes (available) Chapter 2: SOC Access, Training, Skills, Staffing, and Roles (available) Chapter 3: Metrics for the SOC (available) Chapter 4: Threat Hunting Practices in the SOC (unavailable) Chapter 5: A Day in the Life of a SOC Analyst (unavailable) Chapter 6: Timekeeping and Event Times (unavailable) Chapter 7: Continuous Monitoring (unavailable) Chapter 8: Security Architecture Considerations for SOCs (unavailable) Chapter 9: SOC and SIEM Use Cases and Template (unavailable) Chapter 10: Complete SOC and SIEM Use Case Example (unavailable) Chapter 11: Partial SOC Use Cases (unavailable) Chapter 12: Detection Engineering (unavailable) Chapter 13: Security Monitoring Use Cases and Detections by Data Source (unavailable) Chapter 14: Log Management (unavailable) Chapter 15: Manual Log Analysis for IR and the SOC (unavailable)

Page 6

Preface Blue Team Handbook: SOC, SIEM, and Threat Hunting teaches you how to build out security operations teams and centers as if you were sitting over coffee with a twenty-year veteran in the field. This book was written for the express purpose of providing practical day-to-day guidance for Security Operations, implementing SIEM, and using SIEM and other data sources for modern threat hunting. This book will cover many topics related to the Security Operations Team from a “Field Notes” perspective. It is based on a long career implementing multiple SIEM technologies, building SOC’s, conducting all manner of cyber investigation, developing and running an MSSP, and working as the Countermeasures lead with one of the largest Splunk installations in the USA. The major topics are: Building a Security Operations functional unit, including provisioning plan, budget considerations, thought habits, analyst skills, and tiering structures. Deciding how to structure your Security Operations capability and the services it will offer. An extensive discussion of security focused use cases organized by their respective data source. This chapter describes what to monitor from a given data source, as succinctly as possible. Many of these use cases have a threat hunting theme to them. Building Security Operations Use Cases using my own Use Case Template, followed by a complete use case to use as a model in your own work, and some excerpts from other use cases. Critical SOC analyst skills and investigation processes, which my own team used while I managed a MSSP operational unit for two years in a mid-sized consulting firm.

Page 7

A discussion on applying modern Threat Hunting to the Security Operations team. And a host of other topics that relate to security operations, SOC analyst skills, and SIEM. It is my sincere hope that this book delivers on the Blue Team Handbook motto: “a zero-fluff reference guide for the security practitioner, written with the intention of sharing real life experience”. I trust that you will learn something useful as you read it as many readers of Blue Team Handbook: Incident Response (BTHb:INRE) have shared with me over the years. Who Should Read This Book This book is for IT professionals, cyber security professionals, security operations staff, security consultants, SOC staff, SIEM designers and consultants, and line managers: those responsible for protecting information assets and teaching the next generation of security professionals. Why I Wrote This Book The idea for this book predates the first book in the series, BTHb: INRE. In 2011, our team needed to replace our commercial SIEM platform. We headed down a path that led to my fourth major SIEM implementation. We needed an outline to develop use cases, document all the attributes of a use case and SOC procedures to fully use the new platform. I wanted our chosen vendor to have the best possible chance of bidding on the work and completing our use cases on time, and on budget. After vendor selection, we engaged a major firm and set about replacing the legacy platform. The vendor estimated they could achieve 26 to 28 use cases. After 12 weeks, we exceeded project expectations. They implemented 35 of 37 fully defined use cases that totaled 497 pages in print once the paperwork was done. We added fourteen new right click integrations. We even had a custom UI extension that pulled in a dozen account attributes for every user account

Page 8

listed in an alert when we opened an alarm from three different Active Directory domains. Lastly, we also went from 1.5 people monitoring the prior solution to four full-time analysts because we had so much content and could surface three times the number of security issues and respond appropriately. Along the way I started an MSSP practice with a good friend working with a consulting firm. We won 78% of our POC’s in year one, and had a 100% renewal rate during year two, so several of those life lessons are incorporated herein. Navigating the Book Part One: Security Operations Field Notes Chapter 1: SOC Field Notes: This chapter provides practical advice for setting up a security operations center, proper planning, and definition of SOC services. There are several SIPOC diagrams of several services as well. Chapter 2: Staff and Maturity. This chapter goes over the various roles in the SOC, analyst training, and traits, and tiering models. Chapter 3: SOC Metrics. Key metrics and definitions for security operations. Chapter 4: Threat Hunting. This chapter outlines a threat hunting function in the security operations center. Chapter 5: SOC Analysis and Investigation. This chapter walks through what an analyst goes through on a daily basis, investigating alerts. Chapter 6: Timekeeping. There are many issues that SOC analysts can wrestle with when it comes to events and alarm times. This chapter describes many of them.

Page 9

Chapter 7: Continuous Monitoring. Specific to SOC, this chapter defines how the SOC interacts with and uses data from a continuous monitoring program. Chapter 8: Security Architecture and SOC. There are some security architecture topics that impact the SOC and they are covered here. Part Two: Use Case Development Chapter 9: Use Case Template. This chapter defines the Security Operations Use Case template format that the author has used for fifteen years with multiple consulting engagements. Chapter 10: Use Case Example. This is a fully developed use case example. Chapter 11: Partial SOC Use Cases. This chapter covers some key aspects of some other use case examples. Part Three: Detections Chapter 12: Detection engineering. This is the lifeblood of the SOC, the ability to consume log data and develop alerts and follow through on them. Chapter 13: Detections. The longest chapter in the book, this chapter defines numerous detection patterns organized by the type of data they depend on. Part Four: Log Management Chapter 14: Log Management. Log management is a core function of the SOC and one of the key services it provides. Chapter 15: Manual Log Review. This section covers some software and command liens to search through log files and covers jq for JSON data.

Page 10

Acknowledgements Each of the technical content reviewers throughout the history of BTHb: SOC, SIEM, and Threat Hunting is a seasoned InfoSec pro with multiple certifications. This group represents a cross section of the community ranging from security operations and management, vendor product development and implementation, penetration testing, security engineering, and architecture. These reviewers are directly responsible for 42 pages of additional text from the original draft and collectively provided over 700 suggestions as a testament to their skills and passion for helping me to produce a well written book. I cannot thank them enough. In alphabetical order, the reviewers were: Christopher Beiring: Lead Security Operations analyst, network penetration tester, and all-around security engineer for a Virginia- based consulting firm. Chris Crowley, Montance, LLC. Chris is a well-known information security consultant, a Principal Instructor with SANS, and a course author for two courses with the SANS Institute. John Hubbard: John is a SANS Instructor and author, a SOC Lead for a large pharmaceutical company, and an all-around dedicated blue-teamer. Seth Misenar, GSE #28: Seth is a Cyber Security Expert who serves as a Faculty Fellow with SANS. Seth is a co-author for the bestselling SANS course SEC511: Continuous Monitoring and Security Operations. Seth provided the initial technical review for this book, when it was in its infancy. Ryan O’Connor: Ryan is an InfoSec security operation engineer for a leading security products company. Phil Plantamura: Phil is the COO for Security Onion Solutions. Phil has a 20+ year distinguished career in InfoSec working for defense, IR firms, and education.

Page 11

Chris Sanders, GSE #64, Applied Network Defense. Chris is a well-known security analyst, author, and educator. Chris reviewed the sections titled “A Day in the Life of SOC Analyst” and “Alarm Investigation Process.” Johanna Schafer, M.A.C.E.: Johanna provided a layperson read through, checked it for readability, grammar, and punctuation for the first edition of the book during the technical review process. My favorite error she found was the word “bacon” instead of “beacon”, which for some strange reason, was a repeat occurrence in early drafts. Peter Szczepankiewicz: A long-term colleague and a SANS Instructor. Martin Tremblay, GSE #80: Martin has 20 years of combined red and blue team experience. He works for a leading international consulting firm and is based in Canada.

Page 12

Chapter 1. Security Operation Center Field Notes “If you fail to plan, you plan to fail.” —Commonly attributed to Benjamin Franklin “The only thing that is constant is change.” —Heraclitus “One of the main cyber-risks is to think they don’t exist. The other is to try to treat all potential risks.” —Stephane Nappo A NOTE FOR EARLY RELEASE READERS With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles. This will be the 1st chapter of the final book. If you’d like to be actively involved in reviewing and commenting on this draft, please reach out to the editor at jleonard@oreilly.com. A Security Operations Center (SOC) means different things to different people. Some say they “run the security platform”, others say “they handle incidents”, and still others say, “they monitor the security of the network”. The definition for a SOC used in BTHb:SOCTH is:

Page 13

“A centralized team in a single organization that monitors the information technology environment for vulnerabilities, unauthorized activity, acceptable use/policy/procedure violations, intrusions into and out of the network, and provides direct support of the cyber incident response process.” The SOC is the first line of cyber defense for your organization. This definition incorporates several important strategies for a successful SOC. First, a SOC must be under a single management and reporting structure so that it has a clear line of authority, funding, reporting, and accountability. Second, a SOC must have awareness of all aspects of both the business and the IT environment, from the smallest workstation to the largest supercluster in the cloud. Third, a SOC needs to understand its area of operation (AO), how they will support the business, monitor business applications, and infrastructure. These criteria must be covered in the SOC charter. Fourth, SOC budget needs to be large enough to continually invest in people and support cross training instead of sophisticated software. That concept leads to the fifth strategy: train and encourage analysts to be calm, correctly interpret alerts and supporting data. This requires that SOC analysts are well trained. One point deserves some elaboration. There are few different ways that the SOC team can establish its AO. The SOC can use the IT General Controls program, corporate policy/procedure, guidance from standards like the ISO 2700X series, or follow the Center for Internet Security’s 20 critical controls. When designing, building, staffing, and operating a SOC, you need to develop a charter and mission statement. To achieve these various strategies, the SOC needs to know the network, the application to server relationships, what is happening on the network, and

Page 14

be able to determine if that activity presents a significant enough risk to the organization that the activity needs to be effectively dealt with. SOC teams don’t solve security issues with complex SIEM software. They solve it with knowledge, skill, and ability. Complex SIEM tools help – but they are not a technological panacea. Start With a SOC Charter Every security operations center needs a “charter”. The SOC charter defines how the SOC serves the business, mandate(s), defines governance and operational rules, what its areas of operation are, and how the organization needs to respond to the investigations conducted by the SOC as it goes about its daily business. Note that the SOC charter is not the same as a project charter, a document defined by the Project Management Body of Knowledge (PMBOK). The SOC Project Implementation Charter is a formal document that provides an overview, authorizes the project to develop a SOC, the SOC scope and key deliverables, a high-level timeline and milestones, names the key stakeholders, assumptions, constraints, and risks, and empowers the project manager to apply resources and create the SOC. On the heels of the SOC charter usually is a more focused project on implementing the SOC’s key platforms, one or more SIEMs and SOAR suite, and has the same key points plus support for a budget and a brief spending plan. The SOC charter is often developed in tandem with the SOC/SIEM project implementation charter. The SOC charter should be scoped properly, whereas an implementation charter is a Project Management Institute (PMI) defined document. The term comes from the Project Management Body of Knowledge (PMBOK) as a type “project artifact”. Don’t get the two confused. Consider, and be Prepared, for Tough Questions

Page 15

To fund SecOps, SIEM, and a SOC, you will undoubtedly face many questions. Here are a few of them that I have been asked over the years, condensed for publication, quoted to by memory as best as I can. Determine the answer when building your funding request. Nothing has happened yet. Why do we need to do this? How can you be sure that nothing has happened yet? As a possible answer, try this out: “It’s not if, it’s when.” How will the team detect and respond to security issues, incidents, and data breaches? How did we do this before? Isn’t that what the sysadmins do? Did the organization incur any costs from an incident last year? Virus outbreaks? What costs are incurred from our peers and competitors? How many users at what “level” were negatively affected (as in lost productivity) from an incident? How are you going to measure yourselves and get on the IT Balanced Scorecard? As a possible approach, ask if you can be on the business scorecard during the SOC charter development process. How will the team determine what alarm conditions are prioritized over something else – who wins? (Hint: asset value tied to critical business processes and revenue stream protection). I thought we spent X on Security last year. Why do you want more? I know we don’t have anything worth stealing. Why do we need to do more of this security “stuff”? Don’t those things cost millions? We are doing vulnerability assessments. Isn’t that enough? If you are not doing active and timely remediation, then no, it isn’t.

Page 16

Those security people keep saying no, so I’m going to say no to them this time. So there. We can successfully outsource that for 1/8 the cost, right? After all, that’s what the vendors say. Why do you disagree with them? Aren’t they experts? How will this SOC solve business problems for us? What does this SOC thing look like in year 1, year 3, and year 5? I don’t want to buy more expensive security people only to have them quit. What are you going to do about staff retention? Burnout? Attrition? Internal transfer? I recently heard at a security conference that when people take a SOC job they plan to quit in 18 months. How will you know when you have had a success? What does success and failure look like for a SOC? (or a major security purchase?) Have you been talking to the auditors again? They said something about this last year. I bought a new firewall. Show me a playbook first – can you do that? Come back when that’s done. IT is outsourced, it is “company X’s” responsibility, not ours. We have no liability because that rests with the outsourced vendor and it’s in the cloud/vendor contract1. What can you do with a third of that? Because that’s all we have. We spent $3.5M on SOX last year. No more! Identify SOC Services by Development Phase

Page 17

A Security Operations center can provide numerous services to both the business and to IT. A list of these services is provided in Table 1-1. You do not need to build each service “Day One”. Instead, evaluate your current state, staff, maturity, and funding available. Be careful to build out services which will be successful by only taking on a service that you can successfully deliver when your plan and staff are ready. Determine which service will be built and the order. Understand how the organization can use a given service and how the SOC can acquire and deliver that service and mature it. It is entirely possible that the SOC will develop a hybrid service inventory with some services in-house, some through a partner, and some fully outsourced. The core services of a SOC operations team are listed below. Your organization will certainly implement these services based on your own capabilities, funding, anticipated service window such as 8AM to 6 PM, 6AM to 12 PM, or full 7/24/365 and the staffing level required for each delivery window.

Page 18

Table 1-1. Security Operations Center Service List Reactive Services Proactive Services Other Related Services Monitor Security Posture (Alerts) Network Security Monitoring Policy Procedure Support Initiate & Manage Incident Response Threat Hunting Internal Training and Support Command Function (IR/Analysis) Platform Health Monitoring & Support Audit and Assessment Vulnerability Management Cyber Threat Intel Generation Organization facing briefings and updates Forensics/eDiscovery Cyber Threat Intel Integration (ISAC)   Reporting     Malware Analysis     Intrusion Detection     Audit/Assessment     Notification Refinement Log Management    

Page 19

As you consider each of these services, be sure to incorporate them into your SOC planning process. Here is an outline of the steps involved. 1. Assign them to an implementation phase 2. Ensure the supporting skills required to deliver on each 3. Identify the data sources that enable a service offering are available 4. Plan for policies and procedures to support the service 5. Build out engagement and IR response patterns related to the service 6. Establish staffing to realize that service over the lifetime of the SOC. 7. Build the budget for each service. The Security Operations SIPOC Diagram as a Service Design Tool There is a very useful tool that SOC service planning can utilize to diagram out the main elements of a SOC service process: a five-column diagram that lists Suppliers, Inputs, Process, Output, and Customer, or SIPOC diagram. This diagram comes from Six Sigma. If you are interested in using Six Sigma methods, SIPOC’s are developed and are foundational tools at the “Define” and “Measure” phase. This diagramming model embodies five elements, with the definition adapted for SOC services and model the processes used to deliver that service: Suppliers Anyone who provides the inputs for the process. Can be internal or external. Input The resources, materials, or information needed for the process to function; other services may be an input as well.

Page 20

For SOC’s, data sources need to be spelled out. Process A high-level overview of the major steps in the process, often in four to five steps. Leave the details for the playbook(s). It is likely that processes will include interconnections with outer IT and business teams. Outputs The products, services, or information that result from the process. Customers The people or departments who receive the outputs, For the SOC application of SIPOC, these are stakeholders, application owners, SLT/ELT, HR, and staff management. An end user may also be a customer, but you will find that end users are often the subject of an investigation. SIPOC Diagrams are included for these services: Table 1-2 Security Monitoring Table 1-3 Incident Response Table 1-4 SecOps Platform Health Monitoring Table 1-5 Cyber Threat Intelligence Voice of the Customer SIPOC diagrams need to include, or make clear, the “Voice of the Customer” (another Sig Sigma term). As these diagrams are developed, ensure that VoC analysis is conducted and included so that outputs are aligned with stakeholder needs.

Tip the Site

Blue Team Handbook SOC, SIEM, and Threat Hunting (for Raymond Rhine) (Don Murdoch) (z-library.sk, 1lib.sk, z-lib.sk)

Blue Team Handbook SOC, SIEM, and Threat Hunting (for Raymond Rhine) (Don Murdoch) (z-library.sk, 1lib.sk, z-lib.sk)

Registered users can read the full content for free

AI Reading Assistant

Passage locations

Recommended for You

Tip the Site