these materials are © 2020 john wiley & sons, inc. any … · 2020. 5. 18. · stigs for...

These materials are © 2020 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.

www.steelcloud.com

mailto:[email protected]


STIGsSteelCloud Special Edition

by Kenneth Hess


STIGs For Dummies®, SteelCloud Special Edition

Published by

John Wiley & Sons, Inc.

111 River St.

Hoboken, NJ 07030-5774

www.wiley.com

Copyright © 2020 by John Wiley & Sons, Inc.

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 the prior written permission of the Publisher. 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.

Trademarks: Wiley, For Dummies, the Dummies Man logo, The Dummies Way, Dummies.com, Making Everything Easier, and related trade dress 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. SteelCloud and the SteelCloud logo are registered trademarks of SteelCloud. 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.

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 WEBSITE 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, or how to create a custom For Dummies book for your business or organization, please contact our Business Development Department in the U.S. at 877-409-4177, contact [email protected], or visit www.wiley.com/go/custompub. For information about licensing the For Dummies brand for products or services, contact BrandedRights&[email protected].

ISBN: 978-1-119-71387-6 (pbk); ISBN: 978-1-119-71407-1 (ebk)

Manufactured in the United States of America

10 9 8 7 6 5 4 3 2 1

Publisher’s Acknowledgments

Some of the people who helped bring this book to market include the following:

Project Editor: Carrie Burchfield-Leighton

Development Editor: Ryan Williams

Editorial Manager: Rev Mengle

Acquisitions Editor: Steve Hayes

Business Development Representative: Karen Hattan

Contributors: Brian Hajost, Brian Walker, Jamie Coffey, Karl Walinskas

Production Editor: Siddique Shaik

Acknowledgments

Special thanks to Sandra Jamshidi for sharing her “voice of government experience.”

http://www.wiley.com

http://www.wiley.com/go/permissions

http://www.wiley.com/go/permissions

mailto:[email protected]

http://www.wiley.com/go/custompub

mailto:BrandedRights&[email protected]

Table of Contents iii


Table of ContentsINTRODUCTION ............................................................................................... 1

About This Book ................................................................................... 1Icons Used in This Book ....................................................................... 2Beyond the Book .................................................................................. 2

CHAPTER 1: STIG Is a Four-Letter Word (Acronym, Actually) ................................................................... 3I Feel the Need for STIGs ..................................................................... 4Complying with STIGs .......................................................................... 5Tiptoeing through the STIG Process .................................................. 6Showing and Proving STIG Compliance ............................................. 7

CHAPTER 2: Implementing STIGs .................................................................. 9Deciphering STIGs .............................................................................. 10Scanning for Compliance .................................................................. 10Harden My (System’s) Heart.............................................................. 11How Effective Is My STIG? .................................................................. 12Repeating the Process ....................................................................... 12

CHAPTER 3: Troubleshooting STIG Implementations ................ 13Managing Configuration Errors ........................................................ 14Mitigating Conflicting STIGs .............................................................. 15Dealing with System Drift .................................................................. 15There’s No Downtime in Production! ............................................... 16

CHAPTER 4: Automating STIG Compliance.......................................... 19Going beyond Traditional STIG Compliance ................................... 20Exploring Automated STIGs .............................................................. 20Drifting Away ....................................................................................... 21Eliminating STIG Controls from Active Directory ............................ 22Trusting the Process .......................................................................... 23The Ultimate Test of STIGs ................................................................ 23These STIGs Are Deeply Conflicted .................................................. 24

iv STIGs For Dummies, SteelCloud Special Edition


CHAPTER 5: Ten Reasons to Automate STIG Implementation ......................................................................... 25Faster Implementation Speed .......................................................... 25Immediate Compliance Feedback .................................................... 26Easy Compliance Scanning ................................................................ 26Minimal Training Required ................................................................ 26Create New Secure Baselines ........................................................... 26Maintain Secure Baselines ................................................................ 27Centralized Management .................................................................. 27Reduce Service Delivery Costs .......................................................... 28Increased Agility ................................................................................. 28Better Quality and Consistency ........................................................ 28

Introduction 1


Introduction

If you’ve ever touched a computer or smartphone, you’ve heard about maintaining cybersecurity, which is important for every-body, but people who run businesses or maintain networks

have to care about more than their personal information. Cybersecurity is a massive, overwhelming topic, not unlike an avalanche, and because we can’t tackle all that info rumbling down the mountain, we focus on the software that powers all devices — the operating system.

Unfortunately, no contemporary OS is secure upon standard installation. Security patching alone doesn’t meet the needs of a typical user, let alone the strict standards maintained by Depart-ment of Defense (DoD) military commands, civilian agencies, or defense contractors who process, store, and secure DoD data-related contracts. To better protect DoD-related data, the Defense Information Systems Agency (DISA) created a set of mandatory configuration standards known collectively as Security Techni-cal Implementation Guides (STIGs). DoD contractors use STIGs to harden and to lock down information systems and software that may otherwise be vulnerable to malicious attacks.

As of this writing, the DoD has released approximately 500 STIGs and continues to release new and updated STIGs on a quarterly schedule — not quite as entertaining as a certain book series star-ring child wizards and stern educators, but just as important and likely to deal with “dark arts.” Currently, DoD contractors must apply STIGs through a painstaking and manual process to achieve compliance with the standards.

About This BookWe can’t guarantee total and utter safety with this book. How-ever, we can get you started on the right path with the right tools. This book provides you with an overview of traditional STIG implementation measures and contrasts them with an automated option that saves time and effort. STIGs For Dummies, SteelCloud Special Edition, is short (also unlike previously mentioned fantasy book series) but full of valuable information to help understand the complexities of STIG compliance, demonstrate the need for an automation option, and describe that automation option in detail.

2 STIGs For Dummies, SteelCloud Special Edition


Icons Used in This BookNotice some eye-catching art in the margins of this book? These icons help simplify information, emphasize key points, and point out potential pitfalls along the path to accomplishing your goals in setting up and implementing technologies.

Reference these items to save yourself some time and effort.

These key takeaway points reinforce learning. If these pages were websites, you’d bookmark them for later.

Some icons point out helpful advice. Some icons keep you from falling into the Grand Canyon, coyote-style. These icons handle the latter impending danger. Watch out!

This information explores topics in greater detail. If you aren’t too technical, don’t worry; you can skip this.

Beyond the BookThis book helps you discover more about STIG compliance, but if you want to go deeper, take a look at these resources:

» public.cyber.mil/stigs: The DoD updates on STIGs

» public.cyber.mil/stigs/downloads: The DoD STIG document library

» public.cyber.mil/stigs/faqs: STIGs FAQs

» www.acq.osd.mil/cmmc: Cybersecurity Maturity Model Certification (CMMC)

» www.cdse.edu/catalog/curricula/CS100.html: Risk Management Framework (RMF)

https://public.cyber.mil/stigs

https://public.cyber.mil/stigs/downloads

https://public.cyber.mil/stigs/faqs

https://www.acq.osd.mil/cmmc/

https://www.cdse.edu/catalog/curricula/CS100.html

CHAPTER 1 STIG Is a Four-Letter Word (Acronym, Actually) 3


Chapter 1

IN THIS CHAPTER

» Exploring the need for STIGs

» Seeing the need for compliance

» Working through the STIG process

» Reporting STIG compliance

STIG Is a Four-Letter Word (Acronym, Actually)

Ever get the feeling that our military branches like acronyms? The documentation is no different. In this case, Security Technical Implementation Guides (STIGs) are specific configu-

ration standards for Department of Defense (DoD), Information Assurance (IA), and IA-enabled systems created and maintained by the Defense Information Systems Agency (DISA). STIGs con-tain technical guidance to secure information systems and soft-ware that may otherwise be vulnerable to malicious attacks. STIGs are available for a variety of information systems including hard-ware, enterprise software, applications, and network appliances. If it’s got a circuit board in it somewhere, it probably has a com-panion STIG.

For various technologies that don’t have a STIG, DISA produces a Security Requirements Guide (SRG). SRGs reference more general security guidelines, whereas STIGs reference specific control con-figurations that can be scanned and remediated.



The guidelines are extensive and often require multiple steps to complete each one. A complicated government process — imagine that! The process is manual and time-consuming for system administrators, network administrators, and security personnel, often requiring weeks or months to fully implement for a single technology.

STIG compliance is especially difficult for organizations man-dated to comply with DoD regulations that have limited staff to perform the lengthy STIG compliance scan, remediation, and reporting tasks.

In this chapter, you discover an introduction to STIGs and STIG compliance through the eyes of a system administrator.

I Feel the Need for STIGsThe online world is dark and full of terrors. For each type of mal-ware, advanced persistent threat, and ransomware, the risk of theft and damage to non-secured data increases. Default config-urations for operating systems and applications offer inadequate protection for systems. To better harden systems, STIGs provide configuration guides for operating systems, open-source soft-ware applications, databases, network devices, wireless devices, virtualization software, and mobile systems to create resilient environments.

The requirement for standardized security measures and guide-lines has grown out of a need to protect DoD-related data, appli-cations, and systems both locally (at a system’s console) and across the network. Think of this concept like needing to lock the door and making sure a bunch of strangers don’t have a key. STIGs grant you that protection and fill a fundamental security necessity.

All government systems are mandated to receive an Authority to Operate (ATO) or you can’t even turn them on. The ATO is the Holy Grail of government IT. You’ve got to earn and maintain this ATO, or your entire environment is dead in the water. Think of it like your system’s driver’s license. Practically speaking, government agencies are required to go through something called Risk Man-agement Framework (RMF) accreditation in order to achieve ATO, and STIG compliance is a major part of that process. Without RMF



certification, an agency can’t deploy its IT assets. New computers sit on desktops collecting dust, often for many months, waiting for a unicorn to fly in and fix all the problems that derail this accreditation. And, based on current projections, unicorn deploy-ment is unreliable at best. Slow or unachievable ATOs are the bane of a federal IT administrator’s existence.

In Figure 1-1, you can see the thoughtful and deliberate means through which the broad concepts of RMF are translated into direct action by the STIG authors.

Complying with STIGsCompliance checks begin with an initial scan using the Security Content Automation Protocol (SCAP) compliance checker tool, which runs vulnerability and compliance scans locally or across the network. This check isn’t as exciting or futuristic as a tricorder scan from Dr. McCoy, but it works. This tool allows administra-tors to evaluate and secure the systems within their companies. The SCAP tool performs automated scans, using STIGs to analyze and report on the security of scanned systems.

FIGURE 1-1: How a STIG is developed.



SCAP content coverage isn’t universal. The tool doesn’t cover 100 percent of technologies that have STIGs or 100 percent of the controls within the STIGs that they cover. For example, network gear, databases, and web components all lack SCAP content. SCAP is a good place to start, but you’ve still got a lot more work to do.

Follow these steps to run a SCAP:

1. A system or network administrator with domain admin-istrator and local administrator privileges scans each system on a network.

2. The administrator evaluates its level of compliance.

3. The administrator manually remediates out-of-compliance items.

4. The administrator rescans to check compliance.

In other words, run the steps, and then run them again! This process repeats until systems are 100 percent compliant or 100 percent compliant minus any exceptions or waivers.

Exceptions and waivers don’t come easily. Waivers and Plans of Action and Milestones (POAMs) are costly and time-consuming. Waived controls

» Require extensive documentation on mitigation measures

» Involve approval processes through higher echelons of governance

» Consume technicians, managers, and leaders in justification dialogues that often iterate back-and-forth multiple times throughout the process

Tiptoeing through the STIG ProcessThe administrator who has the responsibility for applying a STIG to a system or application generally works through a process to scan and remediate them. That oh-so-lucky admin tackles these steps:

1. Determine whether SCAP content is available for all the particular components of your app stack environment.



2. Download the specific STIG for an application or operat-ing system.

3. Using the downloaded STIG, scan the host with the SCAP compliance tool or equivalent.

4. Save the STIG scan results.

5. Import the STIG compliance checker XCCDF file into the STIG Viewer.

6. Follow the instructions in the Check Text section on each control.

7. Follow the instructions in the Fix Text section on each control.

8. Change the Status in the checklist.

9. Repeat the process until the system or application either is fully remediated or fully remediated less any excep-tions or waivers.

Depending on the compliance level required, the number of reme-diation tasks can vary from 1 to over 200. Because STIG Check and Fix sections can impact systems dramatically, you shouldn’t leave this process to amateurs. We recommend admins with an inter-mediate or higher skill level to tackle this task.

Showing and Proving STIG ComplianceAfter the administrator completes the STIG scan and remedia-tion process (and probably enjoys a refreshing beverage or three), he can use the STIG Viewer to show compliance information. For obvious reasons, you don’t just download this info and pass it along via email. During DoD cybersecurity inspections, a DoD representative of the U.S. Cyber Command, or for contractor sites, the Defense Security Service (DSS), inspects the data and may perform separate, independent scans of systems and applications as a compliance check. Somebody has to review the work, after all.

This step isn’t optional. STIG compliance by defense contractors is mandated by the Defense Federal Acquisition Regulation Supple-ment (DFARS) to ensure that contractors can adequately protect DoD- and Intelligence-Community-(IC)-sensitive but unclassi-fied national security, and classified information, depending on the nature of their contracts.

CHAPTER 2 Implementing STIGs 9


Chapter 2

IN THIS CHAPTER

» Deciphering and remediating systems and applications

» Scanning for compliance

» Protecting your systems by following hardening guides

» Learning about the effectiveness of STIGs

» Repeating processes for resolution

Implementing STIGs

S ecurity Technical Implementation Guides (STIGs) are estab-lished to

» Harden systems that store and transmit classified and unclassified Department of Defense (DoD) data

» Strengthen security to ensure the safety of the data and the resilience of the environment

» Maintain its integrity throughout the data life cycle

STIGs have been developed for virtually every major DoD compo-nent including: applications, operating systems, mobile devices, network devices, databases, and web-servers. If your systems are a house, STIGs are the security system, dead-bolts, window latches, and other essential items that make sleeping safely at night a reality.

Every system that comes in contact with sensitive DoD data requires STIG hardening. No off-the-shelf system, application, or device is secure enough to interact with classified or sensitive data. This chapter helps you implement STIGs and make every-thing safe.



Applying STIGs to a device, to an application, or to an operating system is a tedious, manual process that consumes large amounts of time and effort. Implementing STIGs in this manner pulls val-uable resources away from production, from development, and from cyber defense activities. Plan and implement wisely to avoid the unnecessary waste of a lot of time and effort.

Deciphering STIGsWith more than 500 STIG policies available, and dozens of individual controls per policy, the sheer number of controls may seem daunt-ing, especially to junior or even intermediate system administra-tors. Many systems require hundreds of controls to be fully secure. Add the number of controls to the often vague nature of some of the STIGs, and the task of remediation is significant. For example, APP3510 requires validation for user input, but it doesn’t offer spe-cific controls or remedial steps. Big help, huh? And APP3540 states that an application be safe from SQL injections, with no further documented guidance. Not the best user experience, yet here we are.

Smaller organizations that must comply with STIGs may seek outside assistance to augment their own personnel during initial compliance phases to help decipher and remediate systems and applications. In other words, it’s time to phone a friend.

Typically, STIGs classify vulnerabilities into three severity cat-egories, based on what might happen if an exploit occurs:

» CAT I: CAT I, the first category, is the most severe. CAT I controls must be addressed and remediated or DoD authority to operate (ATO) won’t typically be granted.

» CAT II and CAT III: The second and third categories aren’t as critical as CAT I (see the preceding bullet), as you might surmise from the number. Don’t neglect them, though — that inattention can lead to CAT I vulnerabilities.

Scanning for ComplianceAfter determining that a system or an application must undergo STIG compliance remediation, the administrator downloads two applications: the Security Content Automation Protocol (SCAP)

CHAPTER 2 Implementing STIGs 11


Compliance Checker tool (or its equivalent) and the STIG Viewer application. Additionally, the administrator must download the latest STIG benchmark content necessary to access the systems to be STIGed. Thankfully, admins don’t need to wait for optical media or (shudder) floppy discs anymore.

Administrators initiate STIG compliance and execute tasks across the network, or locally, on the system itself. In both cases, the administrator must have administrative privileges on the system to be scanned to ensure all system registries and restricted con-figuration files are completely scanned for compliance.

Check out Chapter 1 for more on the steps for scanning and remediation.

Harden My (System’s) HeartThe remediation process requires that an administrator make changes to registry and configuration files on individual systems. It can also include making changes to Active Directory (AD), Group Policy Objects (GPOs), and other local and global system settings. Hardening a system creates a more resilient environ-ment and protects the environment from both accidental and malicious security breaches and compromises.

Because the remediation process can be tedious and time-consuming, make sure you utilize automation and prioritize CAT I for completion. You should also consider an extra cup of coffee. It’s going to be a long day.

Exercise extreme caution when editing intimate system data because a small mistake can have large consequences for an entire network. Such configuration changes can have undesired conse-quences, such as locking out users and administrators, disrupt-ing applications, or releasing a pack of velociraptors (depending on your location, of course). Some controls outlined in the STIGs require the administrator to make significant global configuration changes that, if done incorrectly, can cause permanent damage to a system, application functionality, or to your AD.

Because of the potential for outages, hardening systems is a lengthy process that requires a senior-level administrator to make decisions about changes to large-scale systems and



authentication schemas. Create snapshot backups prior to making any changes to your AD or any system configuration files for easy restoration or backout. Unfortunately, it’s impractical to snapshot systems at scale.

How Effective Is My STIG?After remediation, you get to do the whole thing again! Run a new compliance check to evaluate the effectiveness of the STIG con-trols in each category (CAT I, II, and III). This spot check validates compliance and also checks for missed tasks.

To further assess STIG effects, administrators must check access to network resources, VPNs, application operations, and other services. Because many configuration changes are global, have representative users from all departments and locations perform these checks and immediately report their findings. Assemble your squad, and make sure each person is clear about the goals you want to achieve. Some changes require that users log off or reboot for new configurations to replicate to users’ profiles and systems. In other words, you should always ask if they’ve tried turning off and on again.

Before backing out of a global configuration change, check with users from multiple departments to verify failures and config-uration errors. Some configuration changes take effect immedi-ately, while others, such as AD changes, need time to propagate through the network and to users’ systems. Be aware that some users won’t be able to report any differences right away. Consider restarting services, rebooting systems, and forcing updates prior to testing change effectiveness.

Repeating the ProcessThink you’re done after you get certified? Nope. Apart from the multiple passes required during an initial STIG process, admin-istrators need to routinely perform compliance scans periodically (minimally once a month) on all IT assets and systems to ensure continued compliance. Remediation requirements need to be assessed on an application-by-application basis between releases of new STIGs.

CHAPTER 3 Troubleshooting STIG Implementations 13


Chapter 3

IN THIS CHAPTER

» Taking care of configuration changes and errors

» Managing STIGs/system-operation conflicts

» Managing drift

» Controlling production downtime

Troubleshooting STIG Implementations

Even the most skilled system administrators make mistakes. A misspelled word, an errant click of your mouse, or a missed control option can all lead to troubleshooting during the

Security Technical Implementation Guide (STIG) implementation process. The STIGs themselves may also contain errors or settings that are incompatible with other configurations on your systems. These require troubleshooting, too.

Administrators who troubleshoot STIGs must figure out which control or group of controls caused the problem. And because of all the virtual moving parts, this process isn’t quick. Trouble-shooting for system administrators can take hours, days, or more. Some problems are so difficult to find and remedy that adminis-trators choose to start the process over from the beginning instead of trying to find the errant entry or series of entries necessary to make a system operational again. Yep, sometimes you just have to restart that journey of a thousand miles with a new single step.

Troubleshooting takes time away from standard production sup-port and cyber activities, and it takes time away from implement-ing STIGs on other systems. In this chapter, you discover the causes and need for STIG troubleshooting.



And just as a teaser, you find out in Chapter 4 how STIG auto-mation can alleviate many of the problems you encounter in this chapter.

Managing Configuration ErrorsDuring manual STIG implementation, a system administrator makes many configuration changes that affect a system and its users both globally and locally. Some changes affect every user, while other changes may only impact a few. A global change such as altering the login permissions of a group of machines affects many users simultaneously. Don’t forget they’ll always let you know how much pain they feel as a result of that change.

One of a system administrator’s greatest fears is misconfigur-ing a system or service that causes an outage. Nothing good ever comes from unplanned outages — they’re costly events that require troubleshooting, recovery, and a post-mortem investiga-tion to find out the root cause. In all, the experience is unpleasant for customers, management, and the system administrator team. There will never be enough coffee to make it feel better.

The problems don’t just stop there, either. As an example of cas-cading impact, changing which groups can log onto a system can cause scripts tagged to specific users to cease functioning. On top of that, use of the system may be restricted to a group of local users, who may or may not remember their passwords, which can be disastrous. Global changes that affect all users have the greatest potential for creating an outage. For this reason, admin-istrators must take great care when manually changing group permissions or placing other restrictions on applications, brows-ers, or network traffic.

When making global changes, administrators need to adhere to a strict change, test, accept, or fix protocol. Changes that can’t be implemented due to application conflicts must be accepted and documented as waivers. And, as we mention in Chapter 1, waivers aren’t easy to obtain — just like tickets to a certain one-named Broadway musical.



Mitigating Conflicting STIGsA conflicting STIG is a control that causes a conflict, restricts access, or prevents normal operation. Removing a conflicting STIG con-trol may seem easy enough, but it largely depends on the severity of the STIG control, or the risk score for the system. For example, if a STIG control causes severe problems with one of your net-work applications but is a CAT I severity (check out Chapter 2 for CAT levels), you may not be able to get a waiver to address it. It’s always something, isn’t it?

Removing conflicting STIG controls can also have a detrimen-tal effect to your security posture. Therefore, any changes made should utilize information prepared for the Risk Management Framework (RMF) process. The DoD RMF is a series of documents that details the process and controls necessary to harden and maintain systems in the safest way possible.

Just as in implementing a STIG control (see Chapter 2), great care and testing must accompany removing controls. The same amount of testing should follow any control removal to check for permissions, access, and security problems. With great power comes great responsibility, or something like that.

Dealing with System DriftDespite the heading, system drift is neither fast nor furious. Typi-cally, when a system administrator refers to drift, in the context of the STIG, it means security configuration drift. Security con-figuration drift is any deviation from your approved security pos-ture or baseline over time. Think of this like a security guard who starts the night following the correct patrol route, then detours to the cafeteria around three in the morning.

Baseline configurations are documented, formally reviewed, and agreed-on sets of specifications for information systems or con-figuration items within those systems.



Administrators may think system drift is remedied during weekly or monthly patching events. Unfortunately, this isn’t true. Sys-tems may drift from the approved application baseline in multiple ways:

» Patching

» Security updates

» Hardware changes

» Application installations

» Local system security changes

» Software additions and removals

» Routine system administration

Unlike scanning with generic STIG content, when implementing or remediating STIG controls for a specific application stack, the approved baseline means applying the approved STIG settings for that specific application. These include operating system, appli-cation, and support components, with the appropriate control waivers. Periodic STIG compliance scans should be performed as a starting point to check drift from the approved baseline. Generic STIG scans don’t include waivers, so there’s still a lot of manual work to do. Because STIGs are released quarterly, periodic means at least monthly after initial STIG implementation and remedia-tion activities. Imagine constantly driving back to your house to verify if you left the oven on or not.

These regular drift checks keep systems within the baseline between STIG updates and maintain security across all systems that fall under STIG compliance policy.

There’s No Downtime in Production!Downtime is bad! Handling downtime in production due to mis-configuration, errant STIGs, or simply human error isn’t how administrators want to spend their days. Downtime can mean

» Your command or organization wastes mission or produc-tion time and potentially incurs cost or experiences outright mission failure.



» Your users lose confidence in you and their access to critical capabilities.

» Your system administrators lose the professional respect of their leadership, colleagues, and user base.

In large operations, STIG implementation activities routinely cause downtime and outages from user access problems to major systems being bricked (placed completely into an unreachable and non-responsive state). The term is slightly unfair, as a real brick is actually more useful.

When possible, try to take “snapshots” of systems prior to mak-ing STIG changes so the changes can be rolled back to their sta-tuses just prior to the outage. Procedural regulations dictate that administrators document and clear all changes prior to imple-menting them, so documentation should exist that outlines all changes and rollback procedures.

STIG-induced downtime can be minimized by carefully following directions and involving affected user groups in extensive testing. Try to remove the possibility of human error as much as possible to mitigate configuration errors and associated downtime. Some-thing can always go wrong, but preparation makes it less likely.

CHAPTER 4 Automating STIG Compliance 19


Chapter 4

IN THIS CHAPTER

» Shifting your mindset

» Learning the concept of automating STIGs

» Eliminating drift

» Localizing STIG controls

» Automating policy ingest and deployment processes

» Measuring the impact of testing

» Minimizing conflicts and rollbacks

Automating STIG Compliance

Sometimes, you just need to let machines lend a hand. Save time, training, and costs, and overcome the anxiety and frustration associated with manual Security Technical

Implementation Guide (STIG) processes by automating your STIG management. This chapter gives you an efficient and effective method of STIG remediation using automated methods.

Automated STIG compliance is accomplished through three workflows:

» Hardening and updated STIGs around new applications

» Automating STIG compliance and policy configuration

» Integration of quarterly STIG updates

Add meditation, prayer, or liberal swearing as necessary.



Going beyond Traditional STIG Compliance

The challenge of STIG compliance is significant and can’t sim-ply be addressed by “trying harder” (increased focus, training, effort, eating raw eggs, or a training montage on a beach). But, because many professionals think STIG implementation is overly complex, they may also accept that automated compliance is just not achievable. That belief is just not true, though! The concept and the administrative actions, while simple on the front end, are complex on the back end. In other words, you can hide all the complex stuff in the engine and still make an easy-to-drive car. Automating STIG compliance for systems is a non-trivial task, but the interface and automation workflow can be simplified.

Automating STIG compliance eliminates frustration and anxiety inherent in the hit-and-miss challenges of manual STIG imple-mentation. Automated STIG management simplifies an overly complex, lengthy, and expensive process to one involving a few mouse clicks and almost no manual steps. This automation frees up the experienced, senior-level administrators for higher-level management tasks (like playing Solitaire and Facebooking) while less-experienced administrators can perform STIG implementa-tion and remediation.

Exploring Automated STIGsExperienced administrators are often skeptical about whether STIG management can even be automated. Many STIGs exist, and embedded within each of them are numerous, discrete security controls addressing a wide range of security issues from operating system registries to correctly configuring your auditing policies.

Administrators also tend to lump STIG non-compliances into the same bucket as other vulnerabilities. But it doesn’t make sense to mix something that’s known and is updated quarterly with patches and zero-day exploit defenses that are in a constant state of change. Typical production support tends to take systems out of compliance (drift) as changes are made to keep systems avail-able to their users. When all the disparate STIG compliance tasks are brought into a comprehensive process that addresses the full



STIG life cycle (shown in Figure 4-1), STIG compliance is actually greatly simplified — that is, when that process is fully automated. Traditionally, separate processes address STIG issues in develop-ment, integration, authorization and accreditation, deployment, and sustainment stages. It is important to understand the impact of addressing STIGs throughout the entire policy life cycle.

For example, a STIG conflict that might cost $1,000 to fix in the development phase might cost 100 times that cost to fix in the RMF/ATO phase. These costs are due to the fact that gaining waiv-ers, due to STIG and application conflicts, can be hugely expensive. It’s much cheaper to know what STIG conflicts will occur with your application or environment before hardening and make the necessary adjustments to code or configuration pre-STIG. With an automation approach, testing for STIG conflicts can be easily and rapidly accomplished in each phase of application development.

Drifting AwayDrift is any deviation away from an approved standard. Think of it like the extra donut compared to your strict diet plan. For exam-ple, an administrator applies a newly released operating system STIG and checks for compliance on the first working day of the month. The administrator then downloads and installs operating

FIGURE 4-1: The STIG full policy life cycle.



system patches on the 15th working day of the month. On the 20th working day of the month, the administrator performs a spot check for compliance and finds that four of the previously remediated controls are now out of compliance. The configura-tions, for multiple reasons, have drifted or deviated from the STIG controls set earlier in the month. Note that the administrator was just trying to do her job. This example highlights the need for constant vigilance, great patience, and maybe the aforementioned extra donut.

Through automated STIG remediation, you can remediate sys-tems daily to control drift. This continuous background remedi-ation means that security and configuration drift are prevented. Systems are always set to and maintained at the approved secure baseline. So, instead of performing scans as the start of the pro-cess to correct drift, the scans become proof of compliance via a constant automated compliance regimen.

Eliminating STIG Controls from Active Directory

Applying STIG controls to Active Directory (AD) can be a pain-ful process. AD Group Policy Objects (GPOs) can be overwritten by AD synchronization, which makes it difficult for administra-tors to make changes and to keep all domain controllers in sync with each other. Now add the tasks of ingesting thousands of STIG controls quarterly, testing new production configurations, and deploying them to the right systems. Your results may include an ineffective AD, which helps nobody at all.

Automation shifts the management of STIG controls from AD and onto local systems. This switch has the net effect of moving secu-rity controls to local registries and configuration files, making global change issues less likely to impact a large number of users. Additionally, Linux and Mac systems are generally not managed under AD, so creating STIG policy via GPOs has no effect on them. You have to manage them locally anyway, so why not mitigate the risk for all systems at the same time?



Trusting the ProcessLike all traditional STIG method tasks, the policy ingest and deploy processes are also manual tasks. The administrator must purposely download all STIGs initially and quarterly. It’s just as boring a task as changing your furnace filter and on about the same schedule. The admin then has to import or ingest the STIGs into the Security Content Automation Protocol (SCAP) tool. That’s a lot of ingestion, isn’t it? You may need some antacid. Finally, the admin manually initiates the scan.

New quarterly STIG updates also must be manually downloaded and ingested, and then the systems are scanned with the new STIGs. The administrator also must “filter on differences” for the new policy controls so only the new policies are included in the STIG testing process. A filtered test takes much less time than dealing with the entire STIG policy. Think of this process like reading a newspaper versus the entire history of the world.

Automation resolves the need for manual filtering and testing for policy changes. Automation streamlines the new policy ingest and deploy processes by comparing existing STIG policy to the newly ingested ones. Additionally, fast remediation and rollback com-plement the entire STIG testing and deployment process.

The Ultimate Test of STIGsTesting new policy controls is an extremely time-consuming task for system administrators. Depending on how sensitive the appli-cation or the environment is, this process can also be tedious as well. Sounds like a real vacation, right?

For example, an administrator implements a small subset of CAT I STIG controls on a system. The next steps include

» Stopping the STIG implementation process

» Sending a request for testers

» Allowing time for the users to test the system

» Noting any exceptions or problems, and then

» Attempting to identify which controls caused the problem



Some environments and systems require testing after each con-trol. If you consider that RHEL Linux 7.x currently has 30 CAT I controls to implement, the testing phase becomes quite lengthy.

Testing is often a progress-limiting step in implementing STIGs due to the time involved with individual schedules and extensive and intrusive testing requirements.

Because of this arduous testing phase, many administrators cre-ate waivers rather than manually test and identify the correct setting for every control. Automated STIG testing eliminates the need for testing avoidance and the large numbers of waiv-ers seen by auditing agents. Automation allows the administrator to quickly (less than 60 minutes) test every STIG control for an operating environment.

These STIGs Are Deeply ConflictedCorrecting, or “rolling back,” conflicting STIGs is an unfortunate reality in the testing and implementation process. Administrators apply a set of STIGs and test the application stack to ensure that they don’t conflict with application operation. Manual rollback is even more of a tedious process than manual remediation because it’s not always clear where the conflict is or which control or con-trols are the culprit. Resolving conflicts requires time, individual policy rollbacks, and more testing. Always, always more testing.

Manual rollback of conflicting STIGs can be as dangerous as implementing conflicting controls. Take care when performing a rollback of any changes. Careful documentation regarding every control that is set or corrected must be maintained if the pro-cess repeats on other systems. And yes, that means more than a scribbled sticky note of reminders.

Automated remediation and rollback greatly simplifies the STIG application, testing, and correction process. And at this point, we could all use a little more simplicity. Additionally, documenta-tion is system-produced as a byproduct of the automated process. After testing is complete, the updated STIG policies are associ-ated with systems or groups of systems. The environment is then updated and remediated. No scripts or GPOs need to be written or deployed. Time for a break!

CHAPTER 5 Ten Reasons to Automate STIG Implementation 25


Chapter 5

IN THIS CHAPTER

» Automating for speed

» Minimizing training requirements

» Securing baselines

» Reducing costs

» Responding to changing conditions

Ten Reasons to Automate STIG Implementation

In this chapter, you get ten reasons to choose automated Security Technical Implementation Guide (STIG) implementation over traditional STIG implementation.

Faster Implementation SpeedTraditional STIG implementation can take from several hours to several weeks, while automated STIG implementation generally completes in one hour or less. For administrators, this reduc-tion in time reduces also frustration. STIG compliance automa-tion speed may not be the determining factor for those who only have a handful of systems, but the time and effort savings add up quickly for those who manage 100 or more systems.



Immediate Compliance FeedbackRather than waiting for hours, days, or weeks for feedback on whether the hours spent on STIG controls were successful, auto-mation makes this feedback available within minutes. Most sys-tems can be fully hardened, the first time, within one hour, and in less than three minutes for ongoing remediation. With STIG automation, compliance feedback is virtually immediate.

Easy Compliance ScanningCompliance scanning isn’t particularly difficult, but that tradi-tional scanning requires a significant manual effort. The user runs a vulnerability scanning tool after ingesting updated STIGs. This step produces volumes of compliance reports. Unfortu-nately, that’s just the start of the journey. Now, the admin needs to make all the corrections and consider any waivers that have been approved for each system. Automation combines all these activities into a single process with an all-purpose tool that scans, remediates, and reports as a single step with all the waivers already built in. The admin can still enjoy another cup of coffee, though.

Minimal Training RequiredTraditional STIG compliance work usually requires an experi-enced mid- to senior-level administrator to perform the changes to critical system configuration files, to Active Directory (AD), and to any in-house developed scripts that are used for compli-ance. Those administrators may be rare, aren’t cheap, and may be a little grumpy as well. Alternatively, automation requires no special skills or training. Junior-level administrators can scan, remediate, and report on STIG compliance after a single, short training session with a simple GUI interface.

Create New Secure BaselinesCreating a new baseline establishes a standard within an environ-ment for an application stack. That standard can then be cloned when creating new systems. Manually creating secure baselines

CHAPTER 5 Ten Reasons to Automate STIG Implementation 27


for IT systems is a tedious, time-consuming task. (It’s the bathtub cleaning or mudroom mopping of the IT world.) But, automated STIG implementation hardens every CAT I, CAT II, and CAT III STIG control around an application baseline in 60 minutes. That’s a single hour versus weeks or months in your accreditation time-line. And it streamlines the incorporation of documented policy waivers to ensure flawless automated STIG remediation and com-pliance reporting. Yeah, that sounds like a good amount of time and money saved. Check out Chapter 2 for more information on CAT I, CAT II, and CAT III vulnerability categories.

Maintain Secure BaselinesEven the best technology and most senior-level system adminis-trator can only guarantee a secure baseline for a few days. Config-uration drift from patches, updates, administrative changes, and new software installations constantly causes issues with compli-ance, because the world always changes, and we can’t have nice things. Attempting to maintain secure baselines with updated STIGs every quarter on every system is a daunting task. Quarterly STIGs applied via automated processes only require approximately 15 minutes to bring the baseline up to date. Subsequent scans to minimize drift are done in the same short period of time. And now you have time for your security research into that Solitaire app.

Centralized ManagementAs you may expect, manual STIG implementation has no central-ized management interface for the remediation process. While it’s possible to scan systems across the network, the standard recom-mendation is to install the Security Content Automation Protocol (SCAP) tool and the STIG viewer (check out Chapter 1 for more information) on each individual system and to scan locally.

Automation provides the administrator with a “single pane of glass,” or a single interface from which to manage all systems. The process can scan and remediate multiple systems across the network through this single interface.



Reduce Service Delivery CostsWhile we’d all like free two-day delivery on our regular shipment of snacks, that’s not what we’re talking about here. Touching every system in a network to perform hardening tasks and apply controls raises delivery costs by dedicating one or more senior system administrators to the job. And, as we may have men-tioned before, those admins can be a little grumpy sometimes. For example, if an organization has 100 systems that need STIG hardening and each system requires two days to scan, remediate, test, and correct, the total human resource requirement is basi-cally one full-time employee working for a year on nothing but STIGs. In the meantime, the other systems still need patching and ongoing support.

By reducing individual “touch” on every system in a network, service delivery costs are significantly reduced by only interacting with a single system’s automation interface. Everything is han-dled by the automation software, thereby reducing service deliv-ery costs in labor and in time.

Increased AgilityAgility, in information technology terms, is a measure of how quickly an organization can respond to changes, threats, or opportunities. Consider the application of a quarterly STIG update where each of 100 systems requires 4 hours to scan, remediate, and test. The total time required is 400 hours — and that’s if nothing goes wrong and no troubleshooting, waivers, or rollbacks are required on any system. Do you think that’s really going to happen? If the applied STIG is a response to a new security threat, a month or even a week isn’t agile. An automated solution can scan and remediate from 3,000 to 5,000 systems per hour. Those 100 systems can be fully scanned and remediated within minutes.

Better Quality and ConsistencyAutomation delivers consistency by mitigating human error. The automation tools apply controls the same way, every time, to each system. Automation delivers continuous, drift-free compliance!


http://steelcloud.com/stigmagic

http://Dummies.com

WILEY END USER LICENSE AGREEMENTGo to www.wiley.com/go/eula to access Wiley’s ebook EULA.

http://www.wiley.com/go/eula

these materials are © 2020 john wiley & sons, inc. any … · 2020. 5. 18. · stigs for...

Documents