Windows Security: Patch Management Strategy

Recently, at work, I nominated myself to begin a “Windows Security” course for IT Professionals that I work with.  Being a former IT Pro, and now part of our security department as an Incident Responder, I thought I would create a course surrounding security.  So, i’m going to use my blog to layout my plans for this “Windows Security” course – which will hopefully be useful for others as well.

My first post is going to focus on “Patch Management”.  Many IT Pro’s, SysAdmins, etc. deploy assets (systems, applications, services, etc.) and join them to their domain, all while not being patched.  Having assets that are not fully patched is a major security risk for your organization.  Imagine, you have server that’s not fully patched you’ve deployed (or someone else) on a Friday afternoon and then you become busy because of another incident.  Monday comes along and your slammed again – once again you forget about this server for some period of time.  We’ve all seen this happen or know of someone who does this.

In this situation, your Patch Management strategy is of the utmost importance.  Having this server on your network is a major security risk, but not if you have a fully patched image.  Whether you are using a fat, thin, zero-touch imaging solution, you need to make sure that your images are up to date and ready to deploy.

Using Microsoft Deployment Toolkit or SCCM (System Center Configuration Manager), can solve this problem with little to no interaction needed.  I’m personally a fan of MDT (check out my walk-through) in an large, decentralized, environment.  Utilizing MDT for your servers is extremely easy and gives your “System Administrators” a flexible and reliable solution for the many configurations your environment demands.

You can also use SCCM, if your environment can justify the cost, to automate this process to a complete “Zero-Touch” solution.  My environment does not allow this because we are not a centralized IT department with a standard “image” across all departments.  Setting up SCCM is cumbersome unless you have full access to the SCCM “site server(s)”.  Never-the-less, SCCM is extremely powerful and can manage all systems (servers, workstations, etc.) in an automated way – but again, it’s pricey.

If you choose to solely use a “fat” image and decide to just use a WinPE disc or even Windows Deployment Servers (WDS), just make sure that you update your image every month or at-least quarterly – and do not, I repeat, do not, join it to your domain/network without it being fully patched.

Deploying Operating Systems is a fairly complicated affair, and we need to utilize the tools available to us – but don’t forget about our third party applications as well.  In my environment, most malware outbreaks are caused by either two types of incidents:

  • Third party products are out of date and malware droppers are taking advantage (either in advertising sites or plan malicious sites) of these exploits.
  • Phishing attempts

Maintaining our applications is also a crucial step that cannot be overlooked.  Again, you can utilize SCCM for this process (if you can justify it) or you can use additional third party products (Ninite, Secunia PSI, WSUS, etc.).  No matter what you use, you need to make sure that all of your systems are updated, and be able to report on this.

Having the ability to view your network/systems is a crucial part of a proper “Patch Management” strategy, so you need to have continual scanning on your network (with the ability to report on systems).  You can either use Nessus, SCCM, QualysGuard, etc., but no matter what, you need this data.  Again, utilize the tools you have – LEARN POWERSHELL!  PowerShell can give you crazy amounts of data – use it, love it, live it.

The last part of this discussion is about anti-virus/malware software.  Depending on the solution, your organization is using, you should be able to alert on infected systems.  If you’re using Microsoft ForeFront Endpoint Protection, then well you may not be able to (besides using PowerShell to gather the log files). It would be preferred if you have a anti-virus/malware solution that has an administrative console or the ability to run reports.

If you don’t have a A/V solution that has this capability, then you need to rely on your Windows Logs and parse them with either Splunk or LogStash or something similar.  Utilizing a system that can correlate this data for you is of immense help – especially if this repository is the same repository as your IDS/IPS logs, Windows Event Logs, etc.

Having the ability to fully patch a system before it is deployed is crucial in every environment.  One piece of malware (with a C2) can scan your entire network for a new server and then as soon as a “SysAdmin” logs in…… well, the game is over – time to rebuild.

MDT 2013: Installing MDT 2013

Now we are going to install MDT 2013. This is a simple process but I wanted to show you anyways.

After you have downloaded MDT 2013 from Microsoft (See This Post)

When you first Launch the MDT 2013 Installer, you should see the following screen:


Click Next to Continue


Accept the License Agreement and click Next:


Choose the Location that you want MDT 2013 to be installed.  This is typically left alone but you are more than welcome to install it on a separate partition/drive.  Once you’ve chosen the appropriate location, Click Next:


I typically choose not to join their CEIP but it’s up to you.  Click Next:


Now, Click Install

That’s It!  It’s pretty straight forward….  Now onto the good stuff!  We will be setting up our MDT 2013 Deployment Share in the next post.

Also, I am in the process of making a video that will explain and show all of these steps


MDT 2013: Installing ADK for 8.1

Once you have all of the necessary files downloaded and saved on your Windows Server 2012 R2 box, then begin by installing the “adksetup.exe”.

The first screen that should pop-up is this one:


The Following Screenshots are all based on your own needs but these are the options that I have chosen for this setup:

I choose to download the ADK instead of installing it.  The reason I do this is because I like to keep a backup of the original file, just in case the server crashes or something else happens.

Click Next


I typically choose to not accept the CEIP, mostly because it adds a little database file in AppData that i’ve seen become corrupt and cause log in issues. If you choose to, it should be fine.

Click Next


Wait until the adksetup has been downloaded then proceed to the location that you save it to.


Click Close and then run the downloaded ADK


Specify the location that you want to install the ADK files.  I personally like to store them on a separate drive than the OS but it’s up to you.

Click Next


Click Accept


Again, it’s up to you but I always select No.

Click Next


Below are the features that I install but you could install all of them.  Here is why I choose why I install the following.

Deployment Tools:  You need to install Deployment Tools as this holds DISM and other tools that are needed by MDT

Windows PE: You need to install this for MDT to work

USMT: This is User State Migration Toolkit.  Think of this as a tool to migrate user data (Migwiz)

SQL Server: I mostly install this because you can use it to setup a backed database for MDT, it’s not necessary unless you plan on using it.

Click Install


Once the installation is complete, click Close


Congratulations, you’ve installed ADK on your Windows Server 2012 R2 box.  Next we will install MDT 2013.