Product Blog

11 Posts authored by: Lawrence Garvin

Each of the products in the SolarWinds portfolio of products brings unique capabilities to the table to make I.T. management in your organization a much less painful process.

  • Server & Application Monitor (SAM) provides the ability to monitor servers and the applications running on them, and display status and generate alerts based on that status.
  • Log & Event Manager (LEM) provides the ability to collect log events from servers and network devices, and correlate those events.

Combining these two products in a cooperative effort can have exponential impacts on reducing the effort involved in managing I.T. those improvements. Let's look at two examples of scenarios where these products can enhance each other.

 

SQL Server performance loss

In our first example, consider the scenario where you have configured SAM to monitor an instance of SQL Server. SAM tracks a number of state and performance values on a SQL Server instance. One of the performance values that can be tracked is the amount of time consumed in running queries. If the queries exceed the defined performance threshold, SAM generates an alert that the condition exists. This information, however, requires further action. By itself it might require involvement of additional people, other tools, and will likely take some time to track down.

 

Adding LEM into the mix allows us to leverage the ability to correlate that performance metric with actual events that have occurred in that SQL database, SQL instance, and the server hosting the database engine. In addition to displaying the alert on the SAM console, we configure SAM to send that alert direct to LEM. LEM receives the alert, and through LEM's event log analyzer and the use of correlation rules, it can help to identify specific events that correlate to the performance degradation. In this example we discover that a configuration change made to the database by a DBA has resulted in the observed performance changes reported by SAM.

 

Exchange server farm reliability

In another example, consider the volume of log messages that are generated by an Exchange server farm. These log messages involve logons, logoffs, mail receipt, mail sends, distribution list expansions, and a whole host of other activities. The amount of events generated by a busy Exchange farm is really extensive. LEM allows us to use these correlation rules to identify issues on a more macro-scale than individual events. In our example the LEM correlation rule on a collection of Exchange events identifies a potential reliability issue with the Exchange server farm. LEM generates an automated alert to SAM, which results in a single Exchange monitor alert displayed on the SAM NOC view, and a technician can be dispatched to begin the investigation before the actual outage occurs.

 

Cooperative benefits

In both of these examples, SAM and LEM provide complimentary features that play to their own strengths. SAM has a great reporting dashboard that can focus on high-level status information, and LEM has a powerful correlation rules engine that allows for the automated interpretation of thousands of discrete events that represent trends in the state of an application or system.

SAM-LEM Cooperation.png

Both products are available for download today [SAM][LEM] with a 30-day evaluation. If you’re already using one of these great products, explore the benefits of enhancing your environment with the other.

Today I am happy to announce the general availability of Patch Manager v1.8. All current Patch Manager customers under active maintenance can download the upgrade immediately through their customer portal.

 

What's new in Patch Manager

  • Most notable in this release, which we've been discussing since June in this Product Blog, is the integration with the Configuration Manager 2012 console for third-party update management and the client management toolset.
  • The other significant component of this release is the addition of a web console as part of the SolarWinds Orion family of products. Take a look at the web console in this online demo.
  • For those of you involved in package creation, particularly with our PackageBoot functionality, you'll be happy to see the new PackageBoot Graphical Editor, which will eliminate the need to edit the PackageBoot.XML file manually, plus we've enhanced the capabilities of PackageBoot to do even more than before.

 

The product also rolls up a number of incremental changes that have been made over the past six months:

  • Integration with the SolarWinds Customer Portal providing self-service product activation codes
  • Removal of activation codes for secondary application servers
  • Change of authentication methodology from LogOnInteractive to LogOnAsBatch, which eliminates UAC complications
  • Certificate enhancements in preparation for KB2661254
  • Upgrade of certificates to 2048 bits

 

For new installations, we've added the third-party update wizards to the auto-launch sequence that runs after the first console launch, and we now give you the option to not auto-deploy the WMI Providers on first-use, protecting your systems from accidental unwanted software installations.

 

 

System Center Configuration Manager 2012 console integration

Configuration Manager 2012 Console - 3rd Party Updates View.png

 

 

All of the third-party updates functionality is now available directly from the Software Library page of the Configuration Manager console. Drilling into the Third-Party Updates node, we provide a handy filter list by synchronization date, so you can quickly get to this week's updates, or this month's updates, and no longer have to filter through the hundreds of legacy packages you may no longer need. Within the update view, the same multi-pane navigation that you are already familiar with is still used, with the dynamically generated vendor subnodes. Selecting the Sun node, for example, allows you to focus directly on the latest Java update packages. All package functionality is available from the context menu, or from the ribbon bar at the top of the console.

 

On the Asset & Compliance page, in the Devices node, we've integrated all of the client monitoring and management functionality: Client Actions, Agent Configuration, and the Computer Explorer.

Configuration Manager 2012 Console - Client Tools.png

Patch Manager Web Console

Patch Manager Web Console - Summary.pngPatch Manager Web Console - WSUS Client Info.pngPatch Manager Web Console - Update Details.png

Brand new functionality in the form of a web interface will be very useful for getting quick looks at the state of your environment, or for sharing information with managers, executives, or other system administrators, but eliminating the need to create, schedule, and distribute reports. The Home Page of the web console shows a user-customizable view of important patch management status information, and each update or computer item can be drilled into via hyperlink to get detailed per-update or per-computer status information.

 

PackageBoot Graphical Editor

Patch Manager PackageBoot Editor.png

 

One of the most powerful tools in Patch Manager is PackageBoot. Unfortunately, though, until now it's also been one of the most complicated to use. Nobody likes editing XML by hand, and nobody should have to know and understand an XML schema just to use the functionality it provides. We heard you loud and clear and this release introduces the PackageBoot Graphical Editor. Now, rather than focusing on the how something gets done (and fighting with the predictable syntax errors), you can focus on the what that needs to get done.

 

Addiitionally we've enhanced the operational functionality within PackageBoot.

  • We've added the ability to configure the service startup options. Previously you could stop or start a service, now you can disable it, set it to manual, or ensure it's set to automatic.
  • Previously an event could only trigger a stop or continue action when encountering a failure; now you can also configure a failed event to skip ahead to the postexecution phase. For example, if you're unable to stop a service, terminate a process, or unlock a file, you can skip over the attempt to install the update, and just do the cleanup.
  • We've extended the ability to run local programs (e.g. WUSA, CScript) into the pre-execution phase, and the ability to terminate processes and manage file locks into the postexecution phase.

 

And more new resources!

 

Finally, we've been hard at work developing a new series of product videos

 

and a few of the older popular ones are now available on the Thwack Patch Manager Resource Library along with a brand new Patch Manager Administration Guide on the Patch Manager Documentation webpage that consolidates everything you need or want to know about Patch Manager into a single document.

 

We've added two content exchanges to allow us all to collaborate on report templates and update packages.

 

We also recently launched a new community for patch administrators everywhere.. checkout the new PatchZone.

 

For more information about Patch Manager, or to download a free 30-day evaluation, see the Patch Manager page.

Patch Manager now patches Windows Server 2012 and Windows 8 systems.

 

Today, August 24, 2012, Microsoft posted an update for WSUS, KB2734608, that enhances WSUS (when installed on Windows Server 2003/2008/2008R2) to provide the ability to patch Windows 8 and Windows Server 2012 systems. With this update, it is no longer necessary to deploy a WSUS-on-Win2012 server to patch Windows 8 or Windows Server 2012 systems.

 

About The Update

After applying KB2734608 to your WSUS server, you will be able to use Patch Manager to deploy Microsoft and third-party updates to Windows 8 and Windows Server 2012 client systems. In addition, all of the previous fixes from KB2720211 are included, particularly the new Windows Update Agent v7.6.7600.256 and the update to create 2048-bit publishing certificates. If you have not yet installed KB2720211, there is no need to install that older update, you can simply install KB2734608.

 

Installing The Update

Like KB2720211, there are special considerations for installing this update to your WSUS server, and a review of the Microsoft KB article and a full system backup are highly encouraged prior to installing this update. Be sure to install KB2734608 to any Patch Manager servers, as you will also need to update all instances of the WSUS Administration Console, as well.

 

Post-Installation Considerations

Finally, as with KB2720211, be sure to create a new WSUS Publishing Certificate and distribute to your client systems before installing KB2661254, which is available now via the Microsoft Download Center, and will be distributed to WSUS in October, 2012. For more information about the WSUS Publishing Certificate requirements, please see

·         Update Patch Manager and WSUS before you apply Microsoft KB2661254

·         3rd Party Updates with WSUS & Local Publishing

 

How To Get the Update

The KB2734608 update is not currently available for deployment using WSUS, so you will need to download it from the Microsoft Download Center. [x86] [x64]

 

For more information on WSUS updates, administrative tips and patch management best practices, check out PatchZone.org

For more information about Patch Manager, please visit the Patch Manager page on the SolarWinds website.

Patch Manager Architecture – Deploying Application & Management Role Servers

 

This is part two of a two part article discussing scenarios for implementing additional Patch Manager servers. In part one of this article I described some of the common scenarios for using additional Patch Manager Automation Role servers that may be beneficial to your environment. In this part I will discuss scenarios for using additional Application Role and Management Role servers.

Again, I would like to emphasize the fact that because Patch Manager is licensed by the number of managed nodes in your organization, there are no additional Patch Manager licensing costs associated with implementing additional Patch Manager servers.

 

As previously discussed, the Application Role is the component of Patch Manager that interfaces with the console user. The Management Role is the component of Patch Manager that stores inventory data and oversees the delegation of task execution events to the Automation Role servers. . A Management Role server hosts a Management Group, which is defined by one or more of one of the following: a workgroup, an Active Directory domain, a WSUS server.

 

Why implement additional Application Role servers?

Implementing additional Application Role servers is done to provide redundancy or additional load capacity for console connections, or to create isolated sandboxes in which a console user manages an environment. An Application Role server has its own credentials, user profiles, and security roles.

 

Why implement additional Management Role servers?

Implementing additional Management Role servers is done to physically segregate the Patch Manager data into multiple data stores. Multiple data stores might be appropriate where segments of an organization have data sensitivity or confidentiality concerns about their managed systems, or where reporting is typically done at a more granular level, perhaps by department or site.

 

Scenario 1: Using an Application Role server to manage console connections

A scenario where multiple application servers would be appropriate is when managing a large number of Patch Manager console users, or where high-availability requirements exist. In a High Availability (HA) scenario, there would be three Application Role servers implemented:

  • The primary server (PAS) is not used for console connections, but only as a control system for the Patch Manager environment. It should be backed up regularly.
  • At least two Secondary Application Role servers (SAS) would be implemented. These servers primarily handle console connections and task management. Consoles can be split across the servers for rudimentary load balancing and individual console users would connect to the alternate server if their home server was offline, or the servers can be designated as an active/standby pair, and the consoles would only connect to the standby server if the active server is offline and immediate access is required.

ApplicationServersForHighAvailability.png

This HA scenario can scale to as many Application Role servers as are required. Theoretically, each console user could have their own dedicated Application Role server installed on their personal systems.

 

Scenario 2: Using a Management Role server to segregate patch and asset data

One use for an additional Management Role server is to physically segregate the patch data collected from the WSUS server from the asset inventory data collected from the Managed Computer Inventory (WMI) task. This might be done for performance reasons, providing better report generation from smaller databases, or because an organization has a large dataset and does not want to invest in a licensed instance of SQL Server.

 

For some environments, the 10GB database size limitation of SQL Server 2008 R2 Express Edition may not be sufficient for both WSUS (patch) data and WMI (inventory) data. The primary Patch Manager server can be used to hold the data for the WSUS inventory, and a second Management Role server can be configured with a management group just for managing domain and asset inventory data collected via WMI. This implementation would look something like this:

AdditionalMgmtServerForDataSegregation.png

Because the data is physically segregated, this significantly reduces the size of the database that must be accessed for generating reports. Patch management reports come from the database server containing patch data, and asset management reports come from the database server containing asset inventory data. The smaller datasets will result in faster rendering of reports.

 

Finally, security controls can also be applied in this scenario, so users who should only have access to patch data, can be physically and logically isolated from the asset inventory data, or vice versa, and users who need access to both can still have full access.

 

Scenario 3: Using an Application and Management Role server in a testing lab

One scenario in which an additional Application and Management Role server might be implemented is for an installation of Patch Manager in a testing lab. Many organizations test patches before deployment in a lab setting. Configuring an additional Patch Manager server in the lab allows that environment to be completely isolated from the production environment.

 

In this particular lab scenario, we are able to implement a second Management Role server, as our lab environment operates in a subdomain of the primary domain. We will define a separate Management Group for this subdomain and the WSUS server in our lab, so that we can physically isolate any inventory data we might choose to collect, as well as manage all task execution completely within the lab environment.

 

This scenario might also apply to a special business unit that has confidentiality considerations, or even to a perimeter network (DMZ), where communication into the primary network is not possible and all management resources must also be on the DMZ.

 

Deploying additional Application Role servers or Management Role servers can provide enhancements to your Patch Manager infrastructure in the areas of redundancy, load-balancing, data distribution, and improved report performance.

 

For more information about Patch Manager Automation Role servers, and advanced deployment scenarios, please see the Patch Manager Deployment Guide. For general product information, please visit the Patch Manager page on the SolarWinds website.

Patch Manager has some very rich capabilities for scalability that are quite often not utilized. In part one of this article I’m going to describe some of the common scenarios for using additional Patch Manager Automation Role servers that may be beneficial to your environment. In part two I will discuss scenarios for using additional Application Role and Management Role servers.

 

As a starting point I would like to emphasize the fact that because Patch Manager is licensed by managed nodes, there are no additional Patch Manager licensing costs associated with implementing additional Patch Manager servers.

 

Let’s do a quick overview of the three roles that exist in a Patch Manager environment. The Automation Role is the component of Patch Manager that initiates communications sessions and manages the task execution on a specific target system. The Application Role is the component of Patch Manager that interfaces with the console user. The Management Role is the component of Patch Manager that stores inventory data and oversees the delegation of task execution events to the Automation Role servers. A Management Role server hosts a Management Group, which is defined by one or more of the following: a workgroup, an Active Directory domain, a WSUS server.

 

When the initial Patch Manager server is installed, all three roles are installed automatically and they share an instance of SQL Server. A simple block diagram of the relationship between the various components of a Patch Manager server looks like this:

PatchManagerPASArchitecture.png

 

Let’s start with the most common additional server scenario – adding an extra Automation Role server. Automation Role servers are used to initiate the RPC/WMI connections to a managed system, so more Automation Role servers means more clients can be targeted in a task simultaneously, and Automation Role servers closer to the client means RPC/WMI does not have to be transported across WAN connections. Also note that each additional instance of a Patch Manager server (regardless of the roles selected for installation) requires its own instance of SQL Server.

 

Scenario 1: Using an Automation Role server to manage a dedicated target

We’re going to look at two scenarios involving additional Automation Role servers. The first scenario is deploying an Automation Role server to manage a specific device. One typical scenario is managing the primary Patch Manager server. There are certain types of actions that a Patch Manager server cannot perform on itself – most notably, being able to do a pre-installation reboot in an Update Management task. A second Automation Role server can be used to manage all tasks performed TO the server hosting Patch Manager.

AutoServerForPAS.png

 

Generally speaking, an Automation Role server would be a dedicated system, but in this particular scenario because this Automation Role server has a very light-duty, special purpose intent (managing only one system), it’s also possible to install this Automation Role on a desktop machine – perhaps the desktop where you’ve installed your Patch Manager console – or even on the WSUS server.

 

Automation Server Routing Rules

Patch Manager uses a feature called Automation Server Routing Rules to help manage the distribution of tasks to the appropriate Automation Role server. In the absence of any rules, each Automation Role server is a member of a single pool, and tasks are assigned to an Automation Role server based on resource availability on those servers. Generally, however, an Automation Role server is deployed for one or more specific reasons, and an Automation Server Routing Rule allows for the enforcement of that reason.

 

Creating Automation Server Routing Rules for Scenario 1

In our first scenario, we would create a rule that says “For any task targeted to the Patch Manager server, execute it on the secondary Automation Role server, but if that server is offline, then execute it on the primary server.

 

Automation Server Routing Rules are created from the tab of that name, on the management group node of the console where the rules should be applied. In most implementations this will be the Managed Enterprise node of the console.

AutomationServerRoutingRules.png

The Automation Server Routing Rule for our first scenario, where we are managing a single machine, would be configured like this:

AutoServerRoutingRuleForPAS.png

In this example, our secondary Automation Role server, named TR-AUTO, is configured to handle all tasks for, and only tasks for, the primary Patch Manager server, named TR-EP. If TR-AUTO is unable to handle the task, TR-EP will attempt to run the task itself.

RoutingRuleDialogForPAS.png

 

To create this rule we perform three steps:

  1. Define an Automation Server Routing Rule – Computer Rule for TR-EP.
  2. Assign TR-AUTO as the Automation Server to handle those tasks.
  3. Uncheck the Absolute Rule to allow any other Automation Role server to execute the task; since the primary server is the only other Patch Manager server, it will get the task.

 

Scenario 2: Using additional Automation Role servers for load-sharing

A second scenario for additional Automation Role servers is to offload work from the primary server. You would do this if the primary server is unable to complete tasks in the desired time interval because number of managed systems in the local network is exceeding the capacity of the primary server. This diagram shows a second Automation Role server configured in a pool with the primary server to provide additional capacity.

AutoServerForLocalNetwork.png

 

 

You would also do this if you have geographically distributed systems, and do not want to maintain RPC/WMI sessions across your Wide Area Network (WAN), or the capacity of the primary server is not sufficient to manage local systems and remote systems.

 

AutoServersForRemoteNetworks.png

 

 

You can also build pools of Automation Role servers for very large networks, or to have redundancy.

 

Creating Automation Server Routing Rules for Scenario 2

In our second scenario, we might typically manage that distribution by IP subnet with a rule that says, “For any task targeted to IP Subnet 192.168.100.0/24, execute it on the Automation Role server that is located in the 192.168.100.0/24 subnet, but if that server is offline, don’t perform the task.”

 

If we deploy multiple Automation Role servers in a subnet, we can explicitly list those individual Automation Role servers and build a sub-pool to handle those tasks by building a rule that says “For any task targeted to IP Subnet 192.168.100.0/24, execute it on any of these Automation Role servers that are located in the 192.168.100.0/24 subnet, but if all of those servers are offline, don’t perform the task.” This allows us to guarantee that tasks are only initiated from local servers, and not across the WAN.

 

The Automation Server Routing Rule for our second example, and assuming the subnet has multiple Automation Role servers, would be configured like this:

AutoServerRoutingRuleForRemoteNetwork.png

In this example, our additional Automation Role servers, named TR-AUTO and TR-APP, are configured to handle any tasks for any system in the 192.168.90.0/24 subnet, and if both servers are unavailable, then the task will fail to execute.

RoutingRuleDialogForRemoteNetwork.png

To create this rule we perform four steps:

  1. Define an Automation Server Routing Rule – Subnet Rule for 192.168.90.0/24.
  2. Assign TR-AUTO as an Automation Role server to handle those tasks.
  3. Add TR-APP as an additional Automation Role server to handle those tasks.
  4. Check the Absolute Rule to prevent any other Automation Role server from executing that task.

 

Automation Role servers can be deployed in a myriad of ways to manage where data communications are initiated from, to provide scalable resources to manage more clients or reduce the time it takes to complete a task. Automation Server Routing Rules can be defined to manage tasks for individual computers or IP subnets, as we’ve seen here, but can also be defined for Active Directory domains, organizational units, or workgroups, as well as an individual WSUS server (for only WSUS Administration tasks) or a Configuration Manager Site Server (for retrieval of Configuration Manager client data).

 

For more information about Patch Manager Automation Role servers, and advanced deployment scenarios, please see the Patch Manager Deployment Guide. For general product information, please visit the Patch Manager page on the SolarWinds website.

For all Patch Manager customers with active maintenance, we have posted an update to your customer portal and to the product download page. This update, v1.73, is designed to ensure continued functionality of all Patch Manager installations, which will be adversely affected by the installation of the Microsoft update KB2661254. KB2661254 is scheduled for release on Patch Tuesday - August 14, 2012.

 

KB2661254 will invalidate all RSA-based certificates with key lengths of less than 1024 bits and has been discussed in several Microsoft postings of late, most notably the following:

 

How does Microsoft KB2661254 affect my Patch Manager installation?

This affects all existing Patch Manager installations, as all versions are currently based on 512-bit key lengths. Certificates are used in Patch Manager to authenticate console-to-server connections, as well as to authenticate server-to-server connections when additional Patch Manager servers have been deployed in the environment. Patch Manager v1.73 replaces the existing 512-bit certificate with 2048-bit certificates.

 

What do I need to do to address this issue?

You should defer deploying KB2661254 to your Patch Manager servers and console systems until they have been successfully updated to Patch Manager v1.73.

 

The Patch Manager v1.73 update must be applied to your Primary Application Server (PAS) first, and then to any additional servers or console installations. Once the v1.73 update is applied to the PAS, and until the v1.73 update is applied to the additional servers, the entire Patch Manager environment will be offline, as the additional servers will be unable to communicate with the updated PAS.

 

Furthermore, until the Patch Manager v1.73 update is applied to the remote consoles, those consoles will be unable to connect to any Patch Manager v1.73 Application Server.

 

To be specific -- any Patch Manager server or console prior to v1.73 cannot communicate with a Patch Manager server upgraded to v1.73.

 

We are providing this update as soon as we were able to complete testing so that you will have sufficient time to plan and implement this update prior to deploying KB2661254.

 

In addition to this certificate subsystem update, Patch Manager v1.73 also includes a roll-up of a fix we released in May that changes how we authenticate with remote systems using credentials. This will provide more reliable authentication with Patch Manager clients, and eliminate many issues that were previously encountered as a result of User Account Control (UAC) interference.

patchzone.jpg

Since SolarWinds acquired Eminentware earlier this year, we have been interested in all things patch.  The product team noticed there is lack of an organized community focused on the topic of patch management, and decided we would create one.  Last week, we announced PatchZone, which is a new space in thwack where IT pros can go to get news and tips on patching Microsoft & 3rd party applications – regardless of whether you are patching with Patch Manager.  Expert guidance is provided by Microsoft MVPs, and our very own Lawrence Garvin (Patch Manager product manager).  You will also see guest blogs by subject matter experts who have implemented vulnerability management solutions in both very large and small IT shops.  Some of the topics you will see on PatchZone, now and in the future include:

  • Patching virtual machines & off line systems
  • Where do application vulnerabilities lurk and which apps should be prioritized for patching
  • Patching, testing & application compatibility
  • Best practices for scheduling your systems’ patching
  • The difference between patching 3rd party apps with SCCM & a third party patching solution
  • Table of 3rd party app updates – with critical updates noted in red with Security Bulletin

 

We hope you find this community educational.  If you have a topic you would like to see covered, please let us know.

YOU'RE INVITED TO A FREE WEBCAST

Sneak Peek: SolarWinds Patch Manager - 7/18/12

 

In this webcast we will cover:

 

  • Orion Integration – Now in your Orion console, you'll be able to view important patch management data alongside other SolarWinds products in the integrated web console.  You'll be able to see information like the latest available patches, top 10 missing patches in your environment, and general health overview of your environment based on which patches have been applied.
  • Integration with System Center Configuration Manager 2012.  Today, Patch Manager is integrated with System Center Configuration Manager 2007.
  • Improved configuration – This next release will automatically install WMI providers on Patch Manager servers, automatically launch wizards to setup 3rd party updating, and provide remediation suggestions for commonly encountered WSUS errors.

 

Presenters: Lawrence Garvin & Brandon Shopp

 

WHEN:            July 18th,  2012

TIME:               10:00 am CDT

REGISTER:       www1.gotomeeting.com/register/184100168

 

As a Product Manager for SolarWinds, I get the opportunity to influence the development of products, and sometimes the opportunity to create new products, and as a WSUS MVP I’m very familiar with the everyday challenges of WSUS Administrators. So, I’m happy to announce the immediate availability of the FREE SolarWinds® Diagnostic Tool for the WSUS Agent.

 

This tool is an alternative to the Client Diagnostic Tool, which many of us have relied on over the years to help troubleshoot client connectivity issues, but we’ve made some significant enhancements to the new version of this tool

 

. • The Diagnostic Tool runs on x64 and x86 systems

. • Additional validation tests on key configuration options, such as syntax checking on the WSUS URL, and validating the installed version of the Windows Update Agent against the installed version of Windows

. • Extended connectivity checks to the WSUS server, translation of error codes to human-readable messages, and suggestions for known resolutions to those issues

. • Both GUI and Command-Line interfaces

 

The tool is a ZIP download with a single EXE installer. Upon installation on the client, the tool automatically launches and initiates the diagnostic scan. You can download the tool today and try it out, or we also posted a video to YouTube that describes and demonstrates the tool if you’d like to have a sneak peek.

It’s been a busy few days for malware and security developments. On Friday I was listening to the TWIT Security Now podcast (recorded Wed May 30th), and the discussion about the Flame malware product. For a great explanation of the backstory of this malware, check out the TWIT episode.

 

This morning I learned from SysAdmin1138’s blog post that Microsoft published a Security Advisory which contains a fix designed to help protect you from being infested with this malware, assuming you are not already infested -- apparently there is evidence that portions of this malware have been around for a few years!

 

The short story of this situation is that a defect in Microsoft’s Terminal Server Licensing Service allows code to be exploited to create a code-signing certificate that is then used to sign code, making it appear as if it came from Microsoft. The Flame malware exploited that defect. Additional details are available from Microsoft in a TechNet blog post published on June 3rd.


While the Flame malware appears to be primarily a cyber-warfare tool, and may not directly impact organizations that are not likely targets of cyber-warfare interests, it’s also worthy of note that the same vulnerability could also be used to code-sign just about anything else and inject it into your systems. You may not consider yourself at risk for Flame, but everybody is at risk of some sort of malware that could be signed using this exploit. You absolutely need to install this update as soon as you can.

 

The update contains a modification to the Certificate Revocation List that makes it impossible for code signed in such a manner to be authenticated. In addition, make sure you have the latest version of the Terminal Server Licensing Service running (if you’re using it), as it has updated cryptography code that no longer contains this defect.

 

If you have WSUS or SCCM, deploy KB2718704 immediately.  If you have Solarwinds Patch Manager you can deploy this out-of-band update today to your entire enterprise as a single, on-demand, monitored task which will provide you immediate feedback on which systems have been secured and which have not.  If you are using another 3rd party patching tool, like Shavlik / VMware, you will need to wait for the patch to be made available for download – likely tomorrow.

This past weekend, Skype was added to the collection of regularly published content available in the Patch Manager 3rd party updates catalog. Skype is a regularly updated product, and organizations that use Skype will likely benefit significantly from centralized management of these updates. For the current v5.x product, there have been at least 11 updates in 19 months since the release of 5.0 in October, 2010. There were 16 updates in 27 months for the v4.x product from July, 2008, to September, 2010.

 

Skype joins the other recent additions of Firefox ESR, Opera and Thunderbird, along with the staples of Reader, Flash, Java, Shockwave, Quicktime, iTunes, and Chrome.

 

You can download SolarWinds Patch Manager from here.

Filter Blog

By date:
By tag: