Windows® Security Monitoring: Scenarios and Patterns
Published by
John Wiley & Sons, Inc.
10475 Crosspoint Boulevard
Indianapolis, IN 46256www.wiley.com
Copyright © 2018 by John Wiley & Sons, Inc., Indianapolis, Indiana
Published simultaneously in Canada
ISBN: 978-1-119-39064-0
ISBN: 978-1-119-39089-3 (ebk)
ISBN: 978-1-119-39087-9 (ebk)
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.
Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Web site is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or website may provide or recommendations it may make. Further, readers should be aware that Internet websites listed in this work may have changed or disappeared between when this work was written and when it is read.
For general information on our other products and services please contact our Customer Care Department within the United States at (877) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.
Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com
. For more information about Wiley products, visit www.wiley.com
.
Library of Congress Control Number: 2017962214
Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. Windows is a registered trademark of Microsoft Corporation. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.
I dedicate this book to those who always wants to know more and seek new information and experience every day.
—Andrei
Andrei Miroshnikov graduated at Irkutsk State University (Russia) with a Master Degree in Computer Science. With more than 9 years of experience in the Information Security field, he is an author and organizer for Forensics CTF for the DEFCON 24 conference. He authored “Windows 10 and Windows Server 2016 security auditing and monitoring reference,” which is a part of Microsoft TechNet. Andrei is a speaker for Microsoft BlueHat and Positive Hack Days conferences.
Roger A. Grimes, Microsoft, Principal Security Architect, is a 30-year computer security consultant specializing in host security, advanced persistent threat, IdM, and other defenses. Roger has written 9 books and over 1,000 magazine articles on computer security. He is a frequent guest speaker at national security conferences.
I would like to say thank you to my wife, Anna, for supporting me during the year I spent working on this book. She was taking care of our home and kids to give me more time to spend on the book.
Thank you to my mother, Natalia Miroshnikova, and father, Sergey Miroshnikov, who invested their time in me from the moment I was born. I owe them a lot.
Thank you to my technical editor, Roger A. Grimes, who supported me from the beginning of this process till the end.
Thank you to my friends Lucine Wang and Jon DeHart for a good time we spent together; this helped me to get some small breaks during my tight schedule.
Thank you to John Wiley & Sons for giving me the opportunity to write my own book. It is a great company to work with. I would like to also say a personal thank you to Tom Dinse, Jim Minatel, and Kim Cofer for their help editing the book and coordinating all work related to its creation.
In this book I share my experience and the results of my research about the Microsoft Windows security auditing subsystem and event patterns. This book covers the Windows Security auditing subsystem and event logs for Windows systems starting from Windows 7 through the most recent Windows 10 and Windows Server 2016 versions.
Many IT Security/Infrastructure professionals understand that they should know what is going on in their company's infrastructure—for example, is someone using privileged accounts during nonworking hours or trying to get access to resources he or she shouldn't have access to? Looking for activities like these is critical to all organizations. To help with this, this book provides technical details about the most common event patterns for Microsoft Windows operating systems. It is a great source of information for building new detection methods and improving a company's Security Logging and Monitoring policy.
The primary goal of this book is to explain Windows security monitoring scenarios and patterns in as much detail as possible. A basic understanding of Microsoft Active Directory Services and Microsoft Windows operational systems will be helpful as you read through the book.
The following areas are covered:
The following software and technologies are covered:
You will find detailed explanations for many event patterns, scenarios, technologies, and methods, and it is my hope that you will find that you've learned a lot, and will start using this book every day. This book is intended as a reference that you will return to many times in your career.
This book is best suited for IT security professionals and IT system administrators. It will be most valuable for IT security monitoring teams, incident response teams, data analytics teams, and threat intelligence experts.
The best way to use this book is as a reference and source of detailed information for specific Windows auditing scenarios.
One of the main goals of this book is to help you create a Security Logging and Monitoring (SL&M) standard for your company. At the beginning of the book I cover what this standard is about, which sections it has, and discuss best practices for creating this document.
Before jumping into the world of event logs, you need to understand how the Windows Auditing Subsystem works and which components and settings belong to this system. I cover security best practices for the Windows security auditing subsystem, its components, and internal data flows.
There are multiple event logs in Windows systems besides the Security log, and many of these logs contain very useful information. It's important to know which subsystems have which event logs, the purpose of these event logs, and the type of information collected in these logs. This information is also present in this book.
I think the most interesting part of the book deals with security monitoring scenarios and patterns. Based on these scenarios, security managers, analysts, engineers, and administrators will be able to improve security monitoring policies and build new or improve existing detection methods.
This book consists of 15 chapters and three appendixes. The first three chapters cover general information about the Windows auditing subsystem and security monitoring policy. The remaining chapters go deeper in to different monitoring scenarios and event patterns.
Chapter by chapter, this book covers:
Some of these questions are easy to answer, but some of them are not. In this chapter you will find information about monitoring recommendations for the most common scenarios related to Windows filesystem and removable storage objects.
This book requires that you have Windows 10 (build 1511 or higher) installed to open the .evtx
files included in this book's download materials.
To help you get the most from the text and keep track of what's happening, we've used a number of conventions throughout the book.
As for styles in the text:
persistence.properties
.We present code and event listings in two different ways:
We use a monofont type with no highlighting for most code and event examples.
We use bold type to emphasize code or events of particularly importance in the present context.
All of the event examples used in this book are available for download at www.wiley.com/go/winsecuritymonitoring
as .evtx
files. These files can be opened by the built-in Windows 10 or Windows Server 2016 Event Viewer application. You will find references to these event log files in each section of every chapter that has event samples in it.
Chapter 1: Windows Security Logging and Monitoring Policy
The purpose of the Security Logging and Monitoring (SL&M) policy is to ensure the confidentiality, integrity, and availability of information by specifying the minimum requirements for security logging and monitoring of company systems.
It is recommended to have such a policy defined and published in order to standardize security logging and monitoring requirements.
This chapter guides you through the sections of the SL&M policy and provides basic information for creating your own version.
This section outlines the requirements for what needs to be logged and how logs need to be managed.
Security logs provide vital information about system events that may, when correlated with other events or used independently, indicate a breach or misuse of resources. When configured and managed properly, logs are key in establishing accountability and attribution for any event. They provide answers to the critical questions about security events: who is involved, what happened, when and where it happened, and how it happened.
Companies should ensure that information passing through their systems, including user activities such as web sites visited and servers accessed, is logged, reviewed, and otherwise utilized.
Implementing the recommendations in this section can mitigate the risk of an attacker's activities going unnoticed and enhance a company's ability to conclude whether an attack led to a breach.
Information systems should enable and implement logging, also referred to as audit logging. Activities that should be logged may include the following:
LSASS.exe
)All of these items are discussed in more detail in this book.
You should also think about where and how to store system events that are used to detect system attack attempts. These events also represent evidence for incident follow-up.
Here are the basic requirements for monitoring an information system. An information system should:
Information systems handling Personally Identifiable Information (PII) and Protected Health Information (PHI) should also log the following information about the data:
Logging should be active at all times and protected from unauthorized access, modification, and accidental or deliberate destruction on all company information resources.
Company employees should not disable audit logs or make system configuration changes that conflict with approved baselines or services without prior authorization from the internal information security team. All changes must create auditable events themselves for tracking purposes.
Logs should be stored in such a way that they cannot be tampered with, or that tampering can be detected and corrected. You cannot trust the log if you do not control the log's integrity.
Access to view the logs should be limited to only those staff members with a job responsibility to analyze the log data. This requirement applies to local logs as well as centralized storage.
Security log storage should have adequate capacity and mechanisms to recycle logs, ensuring that logs will not exhaust the available storage space in an unreasonable amount of time.
The company's information security team should provide for the central collection of security logs from systems throughout the environment.
The centralized log collection and analysis tool should meet the following requirements:
Centralized logging servers should be considered critical assets and be protected in accordance with corporate standards for confidential information. Systems that cannot be configured to log to a centralized or consolidated log system should have appropriate access controls for access to log data.
These requirements can be achieved using the built-in Windows Event Forwarding (WEF) feature, which is included in all Windows operating systems starting from Windows XP SP2 and Windows Server 2003 SP1. WEF is out of scope for this book, but there is a lot of information about this feature on the Internet.
An event log retention policy should be defined for both local and centralized collection storage. For example, the company should retain security logs for at least 30 days short term in the Security Information and Event Manager (SIEM) and 90 days long term in the long-term storage. Company policy, and legal and regulatory requirements, should be taken into consideration when defining the policy.
Chapter 2 contains detailed information about the Microsoft Windows auditing subsystem's group policy settings, which allow you to specify security event log maximum size, retention policy, event log file location, and so on.
Security analysts should regularly review and analyze the collected logs according to a documented and approved schedule to ensure relevancy and adequacy of collected information. Out of date, deprecated, redundant, or superfluous logs should be removed from the central collection system to ensure positive system performance and to reduce the occurrence of false positives.
This section describes what needs to be monitored. It includes requirements for monitoring of logs, intrusion detection systems, and internal communications, as well as mandates for performance review of monitoring systems.
Implementing the recommendations in this section reduces the risk of failure to monitor for security events. Such failure can result in unsuccessful detection or slowed reaction to potential intrusions or misuse of corporate systems.
Companies should implement security monitoring processes and technologies to ensure timely detection and response to security events.
Security logs collected from disparate information systems must be aggregated and analyzed in a timely manner to quickly detect possible unauthorized user activities, misuse, compromise, or attack.
Standard operating procedures should be established and followed by the Security Operations staff to perform analysis and detection activities including, but not limited to, the following:
Electronic communication and all content, voicemail, and any other data of any kind stored or transmitted by company-owned or leased equipment, is the property of the company, and the company may access, monitor, intercept, and/or retain this data at any time without further notice.
Internal communications monitoring should include e-mail, tracking the websites that personnel visit, monitoring internal chat groups, social networks and newsgroups, reviewing material downloaded or uploaded, and voice communications.
Security monitoring and auditing tools and technologies (for example, intrusion detection systems, network scanning tools, and so on) should be deployed and used to monitor company assets. Without proper automation, security monitoring may be a really hard task.
Network-based Intrusion Detection Systems (NIDS) are designed to provide monitoring and support of network intrusion detection across a variety of platforms and technologies and should not be used for any other purpose.
The department charged with ensuring information security should be responsible for approving all Network Intrusion Detection Systems for use on managed networks and systems.
Host-based Intrusion Detection System (HIDS) should be capable of performing file integrity monitoring for critical content files, system files, and configurations, and alerting when attempts to modify the system are detected.
Host-based intrusion detection capabilities should be deployed on all the information resources where sensitive data is stored and potential for damage is high.
HIDS should be configured to perform file integrity comparisons to known good versions on a regular schedule.
Data fields logged by host-based IDS may include the following:
The department charged with ensuring for information security should perform periodic reviews to ensure the company's monitoring systems are successful in detecting unauthorized attempts to access information resources.
Any computer security event deemed suspicious or malicious and critical or high priority should be reported immediately with all relevant details and logs.
Chapter 2: Auditing Subsystem Architecture
Chapter 3: Auditing Subcategories and Recommendations