All software is subject to possible bugs or design
flaws that may introduce security vulnerabilities or other defects into
your environment. Software vendors, including Microsoft, regularly
release updates, or patches, to their software to address these
problems. Software updates may also introduce new or enhanced
functionality to software products. Testing software updates and
deploying them to a large number of systems in a timely manner is an
increasingly important challenge for all IT organizations.
The next sections
present an overview of how Configuration Manager components can work
together to support your enterprise patch management requirements. They
also discuss the infrastructure requirements for Configuration Manager
patch management.
Software Updates Solution Planning
Patch management
is a vital component of an enterprise security policy. The average time
from the publication of a vulnerability to the appearance of an exploit
has gone from several months in the 1990s to just several days. Zero-day
exploits, which appear before a patch is released, are increasingly
common. You should therefore plan for both standard releases and
emergency releases of software updates.
To test patches
prior to production implementation, create test collections of machines
with a representative cross-section of your hardware and software
configurations. Your test plan should include procedures to deploy
updates to test collections and monitor both the deployment process and
the impact on test machines.
Note: About the Risk of Delaying Software Updates
Some organizations,
including at least one branch of the U.S. armed forces, have determined
that the risk for them of postponing patches even briefly outweighs the
risk of deploying untested patches. For this reason, they immediately
push all newly released patches. You need to carefully evaluate what is
right for your security and availability needs.
In addition
to the Software Updates capability integrated into Configuration
Manager, the following Configuration Manager features are available to
support a good patch management and patch compliance solution:
Collections—
In addition to test collections, you should create and maintain
collections for systems that have special considerations for software
updates. For example, you
may decide to handle software updates to a collection of systems in
scope for Sarbanes-Oxley Act (SOX) or HIPAA controls differently due to
change control requirements.
Reports.
Maintenance Windows—
A new feature of Configuration Manager—maintenance windows—gives you
the ability to specify times during which Configuration Manager will
apply changes to systems. If a system belongs to a collection with
defined maintenance windows, then software updates, operating system
(OS) deployments, and software distribution are suppressed during times
that fall outside a maintenance window. For emergency deployments,
distributions can be set to ignore maintenance windows.
Wake On LAN and Intel Active Management Technology (AMT)—
These features allow you to send software updates, advertisements, and
OS deployments to systems that are online but powered down. You should
consider deploying these services to support your Software Updates
solution.
Your patch management solution should also integrate with the following IT processes:
Change management—
Deploying software updates on a scheduled or emergency basis should be
subject to the controls of your change management process. The use of
maintenance windows makes it simpler for you to comply with many change
management policies.
Configuration management and release management—
Inputs from these two processes should help you to systematically
identify vulnerabilities that may apply to your environment. They can
also help you identify baselines against which patches need to be tested
and to determine which systems and software store and process regulated
data.
Security risk management—
Prioritizing risks and maintaining and staying current with known
vulnerabilities and exploits are essential to effective patch management
practices. An effective security risk management program will also help
in identifying mitigating factors that may allow some patches to be
deferred until regular maintenance or the release of a new build.
Software Updates Architecture
Each Configuration
Manager primary site that provides software update services to clients
must have an active SUP. ConfigMgr clients use the active SUP as
follows:
The SUP is an optional
system role in a secondary site. If a secondary site does not have an
active SUP, clients residing in the boundaries of the site will use the
SUP at the parent site. The advantage of configuring an active SUP at a
secondary site is that it reduces network bandwidth consumption on the
link between the site and its parent. The SUP system role is configured
on a server with WSUS 3.0 installed.
How Software Updates Work
The active SUP
at the central site synchronizes with the Microsoft Updates Internet
site. The active SUP in every other site synchronizes with the active
SUP at its parent site.
Intranet
clients run vulnerability scans from the active SUP at their local site.
If the site is in native mode and the active SUP is accessible from the
Internet, you can configure the active SUP to accept connections from
clients on the Internet as well as intranet clients. If your active SUP
does not accept Internet connections, you can configure a separate
Internet-based SUP. Internet-based SUPs at secondary sites are not
supported and do not work, although the user interface allows you to configure them. Figure 1 shows some options for Software Updates synchronization and client support.
In Figure 6.6,
the active SUP for the Brussels (BXL) primary site is configured to
accept both Internet and intranet access. Katmandu does not have an
active SUP, so clients synchronize with the parent site. The LAB site
shown is a separate hierarchy on an isolated network. Software updates
are exported to an external hard drive and imported in the lab.
Note: About Environments with Standalone WSUS
Do
not configure the WSUS functionality on your SUP outside of ConfigMgr.
ConfigMgr will overwrite any settings configured in WSUS. You also
should remove any group policy for WSUS that might affect ConfigMgr
clients. Clients with WSUS settings established by group policy cannot
be managed by ConfigMgr software updates.
The storage
requirements for software update points depend on the software update
point component properties. You choose which products, classifications,
and languages to support:
Currently
supported products include all supported versions of Windows (Windows
2000 and higher), Microsoft Office products, server products such as
Exchange, ISA, and SQL Server, and Microsoft security products.
Microsoft does not currently provide updates for third-party products as
part of the catalog. Independent software vendors and application
developers can use the System Center Updates Publisher (SCUP) to
integrate their updates with ConfigMgr. For information about SCUP, go
to the Microsoft Downloads Center (http://www.microsoft.com/downloads) and search for System Center Updates Publisher (SCUP) 4.0.
Here are the classifications:
Critical Updates (non-security-related patches fixing major defects)
Definition Updates (for items such as virus signatures)
Drivers
Feature Packs (for new or enhanced functionality)
Security Updates
Service Packs (major rollups with full regression testing)
Tools
Update Rollups (combine multiple fixes with basic regression testing)
Updates (all other non-security fixes)
Approximately 25 language versions are available
Note: About Managing Malware Signature Files
The
minimum synchronization time for ConfigMgr software updates is 24
hours. The 24-hour time period is not suitable for virus definition
files and similar updates required by anti-malware programs, because
these files may need to be updated on a more urgent basis. ConfigMgr
Software Updates is therefore not a supported solution for managing
signature files for Forefront Client Security and other anti-malware
products.
Using WSUSutil
An alternative to
configuring an SUP to participate in a synchronization hierarchy is
scheduling or manually initiating export and import operations using the
WSUSutil utility. See http://technet.microsoft.com/en-us/library/bb680473.aspx
for procedures to synchronize updates using WSUSutil. You might choose
to use WSUSutil to synchronize software update points in an isolated lab
without network connectivity, or to take advantage of third-party
replication tools in a SAN environment.