LANDesk Patch Manager. Strategic and Tactical Implementation Guide

Transcription

1 LANDesk Patch Manager Strategic and Tactical Implementation Guide

2 Contents Using this Guide... 4 Quick Start... 4 Technical High-Level Overview... 5 Discovering your environment... 5 Using Inventory... 6 Using Queries... 7 Using Reporting... 7 Determining Your Patching Strategy... 7 Know Your Environment... 8 Understand the Available Patches... 8 Using a test environment... 8 Determine Patching Methods... 8 Push Based Tasks... 9 Policy Based Tasks... 9 Policy Supported Push... 9 Autofix... 9 When to use Autofix When to not use Autofix Download Your Patch Content Downloading Patch Content: Tactical Schedule You Definitions to Be Automatically Downloaded Define Your Scan and Repair Settings Scan and Repair Setting Tactical Implementation General Options Configure you Patching Strategy Task Based Deployments Autofix Run a Security Scan On Your Devices Creating a Security Scan Deploy Your Patching Strategy

3 3

4 LANDesk Patch Management: Strategic and Tactical Implementation Using this Guide This guide is designed to give the reader both a strategic and tactical perspective in implementing LANDesk Software Patch Manager. The strategic portion is meant to guide the user through why and when to use specified aspects of Patch Manager. The tactical sections are designed to walk the reader through how to implement specified features. As every environment is different, this guide is not intended to give specific guidelines to specific environments. However, the goal of this guide is to assist the reader develop a patching strategy that is comprehensive and sustainable. This document is written solely to address Patch Manager. There may be instances where features not included in Patch Manager are alluded too. This guide does not cover any of these features with any comprehensiveness. Future whitepapers will address other LANDesk Management Suite and LANDesk Security Suite features. The best use of this guide it to simply read in through from start to end. However, each major topic has a quick start portion to it. The quick start sections are meant to give a high level overview of the best-known methods for deploying Patch Manager. As a general guideline the below graphic will be used to guide you through the patch deployment. Each section will highlight where in the patching process the guide is at. Quick Start This section contains the steps required to set up Patch Manager to patch clients. It is intended to be used by experienced LANDesk administrators as a reference and does not go into detail on the process. The details will be covered later in this document. Following are the steps required to set up Patch Manager: 1. Download patch content to the Core Server through the Download Updates window. The Download Updates window is accessed through the Patch and Compliance tool in the LANDesk Management Console. 2. Move downloaded vulnerabilities to be scanned by the clients Scan folder in the Patch and Compliance tool. Only vulnerabilities in the Scan folder will be scanned for on the clients when the Security Scan is executed. 3. Check the Scan and Repair settings assigned to the clients to verify the options have been set correctly for detection. This can be done in the Agent Configuration under Security and Compliance Patch and Compliance Scan or in the Patch and Compliance window by clicking the Configure settings toolbar icon and select the Scan and repair settings item from the drop-down list. 4. Run a Security Scan on all clients to detect what patches they need. 5. Create and run a repair task to install the patches on the clients. Do not rely solely on the repair task status to determine the success of patching. Continue with the remaining steps to fully determine the success of patching. Note: Only patches that have 4

5 been detected by a Security Scan on a client can be patched with a repair task. Trying to install a patch on a client that has not been detected will result in the patch failing to install with the message NO_PATCHES_AVAILABLE. 6. Reboot the clients after the patches have installed if any of the patches require a reboot. If a patch requires a reboot it is not completely installed until the client is rebooted. Failure to reboot the client will result in the patch still being detected as not being installed. 7. Run a Security Scan on all of the clients. 8. Check the Security and Patch information for a specific client to see what patches are still needed or check the affected computers list for a specific vulnerability to determine which computers still need the patch. Technical High-Level Overview Understanding how Patch Manager works is helpful when developing a patching strategy. This section will provide a high-level overview of patch manager. Vulscan.exe is the executable that runs on the client and is the heart-and-soul of Patch Manager. Vulscan.exe (referred to as vulscan) is responsible for managing the patching process on the client. When LANDesk documentation, or employees, reference running a security scan they are referring to vulscan in fact the terms are often used interchangeably. When the LANDesk agent triggers vulscan to run a security scan vulscan sets in motion several events. Once vulscan is triggered it makes a web call back to the LANDesk Core Server to check for any changes in the Scan and Repair settings. The Scan and Repair settings provide vulscan with a set of instructions on how to behave (user interaction, reboot options, and scanner settings). Detailed explanations of the Scan and Repair settings will be provided later in this document. Based on the Scan and Repair settings vulscan will download the detection rules, in the form of an XML document, from the Core Server and initiate a security scan using those rules. If the client device is vulnerable for a patch it gets reported back to the Core Server. If the vulnerability is set to Autofix and Autofix is enabled in the agent and in Scan and Repair settings vulscan will attempt to remediate the vulnerability in accordance with the Scan and Repair settings (more on Autofix later in this document). If vulscan was initiated as part of a remediation task (more on this later in this document) and the device is vulnerable to the vulnerability then vulscan will attempt to remediate the vulnerability according to the Scan and Repair settings associated with the task. The vulnerability will be reported as detected in Patch Manager until the client reports back to the core that the vulnerability has been remediated. Discovering your environment 5

6 When developing a patching strategy as a part of your organizational security policy it is imperative to understand the type of machines and applications deployed in your environment. Having this knowledge will help you address the specific risks posed to your environment. Using LANDesk you can collect data on: - Subnets - Hardware and Operating System - Wireless Access Points - Applications - Malware/Spyware and Antivirus usage Quick Start 1- Deploy the LANDesk Agent 2- Run an Inventory Scan 3- Using device inventory, custom queries, or reports to view device data Strategic A patching strategy will primarily address operating systems and applications. In many environments subnets can be used to determine the location of your machines. When deploying patches this information can be useful. If not using LANDesk for your spyware/malware or Antivirus LANDesk can be used to patch and enforce you security policies for the vendor that you have selected. Through out this guide the data collect as a part of the discovery processes will be referenced in greater detail. LANDesk provides several tools that can be utilized to accomplish these tasks. All of the LANDesk tools require a LANDesk agent to be deployed to and workstations. Once the agent is on the end devices LANDesk Inventory Manager, commonly referred to as to as Inventory, can be utilized for data collection from end devices. This guide does not cover agent deployment or inventory collection, but getting the agent and having the agent run full periodic inventory scans is a critical step in patching your environment. When an inventory scan runs on a client machine critical data is collected and sent back to the LANDesk core server. From the core server you are then able to report on environmental details like the types of operating systems and applications in your environment. Tactical When a device with the LANDesk agent completes an inventory scan the results are sent to the core server. The results are viewable by going into a devices inventory. However, viewing this data on a singular device is not practical. Using custom queries and the built-in reporting modules offer quick and detailed information regarding your environment. Using Inventory To view a devices inventory find the device you would like to view the inventory, right-click that device, and select Inventory This will open up the inventory view of the specific device. The three main sections we are concerned with for patch management are Network, OS, and Software. These three sections allow you to gather details about the types of devices in your network. As you deploy your patching strategy you will also be able to see the system vulnerability information and the patch levels of the device. 6

7 Using Queries Queries are a powerful tool. In the context of device discovery, queries can be used as a reporting and classification tool. Devices can be grouped on a variety of criteria. Common groupings are by operating system type (for example, Windows, Mac, or Linux), device type (for example, Servers, Workstations, and Laptop), and device location. This is helpful when using Patch Manager for device targeting purposes. Devices can also be grouped by applications and vulnerability status. Additionally, Patch Manager has the ability to automatically create a query representing all devices vulnerable to a selected vulnerability. To create a new query: 1- In the console s network view, right-click the My queries group (or Public queries, if you have the public query management right), and then click New query. 2- Enter a unique name for the query 3- Select a component from the inventory attributes list. 4- Select a relational operator. 5- Select a value from the values list. You can edit a value. 6- Click Insert to add the statement to the query list. 7- If you want to query for more than one component, click a logical operator (AND, OR) and repeat steps (Optional) To group query statements so they are evaluated as a group, select two or more query statements and click Group(). 9- When you are finished adding statements, click Save. Using Reporting Reporting is similar to queries in that it displays device information categorically. As a point of fact, any query can be used as a report. There are several built-in reports that can be used to assess your environment. For device discovery there are a few reports that can be helpful to assess your environments. Under Reports Inventory there are three reports that will be of most use: - Operating Systems - IP address and subnet summary - Installed Programs Under Report Security there are several reports that are helpful when addressing the security of your environment. However, for patch management the reports that will be of must use is under the Vulnerabilities folder. These reports will be important when assessing the vulnerabilities in your environment. These reports will also be important when monitoring the progress of your patch deployments. Determining Your Patching Strategy An important step in being successful with a patching strategy is understanding the available tools and having a strategy on how to implement the toolset to accomplish your patching requirements. Quick Start 1- Develop a Test Strategy 2- Determine patching methods 7

8 Testing Strategy One of the primary goals of a security policy in an environment is to maintain stability. The more stable users machines are the more they are available for usability. When a users machine is compromised in some fashion (i.e., exploitation of vulnerability) that machine becomes unavailable for the user(s) of that machine while the machine is repaired. However, from time to time a patch that addresses a given vulnerability actually causes significant problems on the end users machine. While these scenarios are relatively rare they occur with enough frequency that a comprehensive testing strategy should be implemented. It is important that LANDesk does not test each vendor patch. LANDesk only tests the patch detection and remediation rules. The goal of this section is to provide some guidance to get you started with your testing strategy. A full testing strategy should be well thought out and tailored to your specific environment. Testing methodology: 1- Know your environment 2- Understand the available patches 3- Using a test environment Know Your Environment Using LANDesk knowing your environment is a relatively simple process. For this step follow the information provided earlier in this document on discovering your environment. Understand the Available Patches This can be a daunting task in and of itself. Microsoft has taken great efforts to minimize this for patches for their Operating Systems and Office Suite products. Microsoft releases the majority of their patches on the second Tuesday of each month (the few exceptions are typically critical zero day vulnerabilities). Regardless of when they release them it is advisable to subscribe to their Security Bulletin Notifications and Security Advisories. You can subscribe to these notifications at Microsoft s website: Many third party software companies have similar notification systems. It is recommended to review these notifications for the patches that you are deploying in your environment. LANDesk Patch Manager also provides vulnerability information. To view this information open Patch and Compliance find the patch that you want to review and right-click it and go to Properties. This will open up the properties of the patch. The Description tab shows you the details of each patch where available. Using a test environment Setting up a test environment is important. It is a best practice to have your test environment match as closely as possible your production environment. Hardware and software environments should be duplicated to best of your organizations ability. Once you have identified devices for your test environment you can use LANDesk to deploy patches to this group. Determine Patching Methods There three primary methods of delivering patches: 1- Push Based Tasks 8

9 2- Policy Based Tasks 3- Autofix Push Based Tasks Push based tasks are initiated by the core server using a deployment task. If you are familiar with Software Distribution you will recognize this process. To start tasks they can either started by scheduling them to start at a specified time or by manually starting the task. Once the task starts the core server attempts to contact the LANDesk agent on the targeted device. If the LANDesk agent does not respond the task will fail (for example, if the targeted device is not on). If the LANDesk agent responds the repair task is initiated on the client device. Push based tasks are good for targeting devices and scheduling the remediation to occur at a predicable time. Pros: - Quickly distribute repair tasks to devices on the network. - Predictable distribution time frames. Cons: - If a device is not on the network the task will fail. - Requires more administrative attention when re-targeting devices that fail due to not being on the network. Policy Based Tasks Policy based tasks are schedule on the core similarly to push based tasks. Once the task initiates the task is made available to user devices. User devices periodically (daily by default) check into the core server to see if there are any distribution tasks that specifically target the machine that is checking in. Once the client machine discovers the task the task is then initiated on the client machine. This type of task is good for devices that are commonly offline (such as laptop devices). Pros: - Good for targeting mobile devices. Cons: - Slower deployment since it requires the client to check-in. Policy Supported Push Policy supported pushes are a hybrid between policy based tasks and push based tasks. With policy supported push tasks once the task is started a push will be initiated identically to a standard push based task. Devices that fail the initial push will be switched from a push-based task to a policy-based task. When the client checks in with the core the device will try the policy-based task. This is a good method to use when you want the speed of an initial push with coverage of a policy-based task. Autofix vulnerable for. Autofix is a feature that will automatically repair any patches marked as Autofix that a vulnerability scan finds a machine 9

10 When to use Autofix The answer as to when your organization should use Autofix can be a complicated one. The most common usage of Autofix is as a closing phase of a more complete patch deployment strategy. Typically a customer will determine the saturation point that they will target with traditional patching methods. Once that saturation point is met then Autofix is enabled to target the remaining machines. The saturation point should be set to a relatively high percentage of targeted machines. For networks with many remote machines or machines that are often off of the network the saturation point may be a lower percentage of total machines. For organizations with a single location with few roaming devices the saturation can be set as a high percentage of devices. A common saturation point is 80%, but this number varies based on some of the notes above. As a starting point, follow these three steps: 1- Test the patch (see Testing Strategy) 2- Schedule a Repair Task for the patch (either push, policy, or policy-supported push). 3- Once you have successfully reached your patch saturation point enable Autofix to reach the hard to get machines. When to not use Autofix Autofix is a valuable tool in your patching strategy. However, Autofix should be used with a bit of caution. When utilizing the Autofix feature is important to remember that when Autofix is enabled for a patch that it is enabled globally for LANDesk agents with Autofix enabled in the Agent Settings. It is possible for an environment to have different Agents deployed and thus giving you the ability to control what physical devices have and do not have Autofix enabled. Autofix enabled patches will target any device with Autofix enabled in the Agent Configuration. Since Autofix is considered to be a global setting if your environment is not tolerant to unscheduled patching or unscheduled reboots. There are ways to configure your scan and repair settings to accommodate timing of patches and controlling system reboots. However, Autofix does not give you as much control and flexibility as other methods. Download Your Patch Content 10

11 Downloading your patch content is essentially a four-step process: 1- Select you patch content to download 2- Define vulnerability download groups 3- Select you patch download location 4- Automate patch downloads This section if fairly straightforward from a strategic standpoint. Select the content that you want to scan your client machines for. By selecting the content you are telling LANDesk to download the specified content. The process that is used is called vaminer.exe. You can select as much content as you would like. However, there are two things to keep in mind. The first, if you select content that you are not licensed for vaminer.exe will validate the content against your licenses and remove content that your core server is not licensed for. The second point is that if you are downloading all associated patches with definitions the more content selected in this window the more patches that you will download thus more space will be used on your content servers. Additionally, downloading a large amount of content will cause your download process to take longer. Downloading Patch Content: Tactical Select Content and languages to Download. To access the Download update window go to Patch and Compliance click Tools Security and Compliance Patch and Compliance. From here you will see the Patch and Compliance window. Click the Download Updates toolbar icon. Download Updates When selecting Download Updates the Download Updates screen will appear. This screen displays all content available for download. From this screen select the vulnerabilities that you would like to scan for in your environment. 11

12 Select the required Definition types and Languages for the environment. Microsoft Windows Vulnerabilities are the most commonly downloaded vulnerability type. Microsoft Windows Vulnerabilities contain the patches for the Windows Operating Systems as well as the patches for common applications for the Windows Operating System (such as Adobe Reader, ITUNES and Microsoft Office). Key Note: Definitions not in the scan folder will not be scanned against. Proxy Settings If the company uses a proxy server then the information should be entered on the Proxy Settings tab to allow the content to be downloaded. The vulnerabilities (detection logic) are downloaded from the LANDesk websites. The patches for the vulnerabilities are downloaded from the vendor's website. For example, Microsoft patches are downloaded from Microsoft's websites. Ensure the proxy will allow the Core Server to access the appropriate website to get the patch. Changing the Patch Location The patch location is where the patches are physically stored upon downloading. By default this location is core server s \LDLogon\Patch folder. There are situations where it is desired to move this location from the default to another location. Two common reasons for moving the default patch location are: - If there is limited space on the drive that the Core Server is installed on. - For administrative purposes. Click the Patch Location tab if the location needs to be moved. 12

13 Use this page to specify where patch executable s are downloaded. - UNC path where patches are stored: Specifics where patch files are downloaded. The default location is the core server s \LDLogon\Patch folder. You can enter the different UNC path to download patches, but you must ensure access to that location by entering valid authentication credentials in the fields below. - Credentials to store patches: Identifies a valid username and password for accessing a location other than the core server. If you re downloading patches to the default location on the core server, the username and password fields are not applicable. - Web URL where clients access patches: Specifies a Web address where devices can access downloaded patches for deployment. The default location is the core server s \LDLogon\Patch folder. This location will normally be the same as the UNC path specified above. - Test settings: Performs a connectivity test to the specified Web URL. - Reset to default: Restores both the UNC path and the Web URL to the default location, which is the core server s \LDLogon\Patch folder. Schedule You Definitions to Be Automatically Downloaded To ensure that your patch content is up to date you can set up a task to automatically download patch content. To create a task to download patch content click the Schedule download button 13

14 This will create a scheduled task and can be scheduled to be a reoccurring scheduled task by clicking the Change button under the Scheduled time section of the task. You can then select the time you would like the task to launch at. If you select Start now or Start later you will be able to select how often you would like the task to reoccur (to re-download patch content). It is generally recommended to set this to reoccur on a weekly basis during off hours. Environmental requirements may change the frequency that you will want to set this task too. Define Your Scan and Repair Settings The Scan and Repair settings are at the core of the patching process. Great care should be taken when considering the proper settings for your environment. Since every environment is different there is no singular best practice. It simply depends on your environment. However, there are some steps that can be taken to guide your decisions. 14

15 Before configuring your Scan and Repair settings document the answers the following questions (I will list the questions here and provide some additional commentary below): 1- How do you want to handle reboots in your environment? 2- Do you want the end users to see when a patch is going to be installed? 3- What types of patch content do you want to scan for? 4- What priority do you want the patch scanner (vulscan) to take on the end users system? 5- How do you want to handle repairing? 6- Do you have any MSI patches that require direct access to the original MSI in order to patch? How do you want to handle reboots? This is of the most important question to understand the answer to. When machines reboot there is a definite impact to the end users. It is best to never have to reboot machines, however, the fact of the matter is that many patches, especially regarding operating systems, do require a reboot in order to be effective. There is three reboot options: never reboot, reboot only if needed, and always reboot. More detail about these options is provided below. Take the time to consider the ramifications of the selection you make. If you select Never Reboot the effectiveness of a patch may not be in effect until that machine reboots. However, being too aggressive with reboots may cause user frustration. Find the balance that works for your environment. Do you want the end users to see when a patch is going to be installed? This is a basic question regarding what you want your end users to be able to see when there system is being patched. These settings involve three main areas of viability: 1- Notifications at the beginning of the patch process. When a security-scan starts, do you want to notify the user that a scan is running? Along with this option you need to consider if you want to give the user the ability to delay or cancel the scan. 2- Notification during patching. When the patch is deployed to an end users machine do you want to notify the user that a patch is being installed? 3- A notification after the patching is complete. Do you want to notify the user that a patch has been successful? If rebooting a machine, do you want to notify the user of a reboot? There are reasons for using or not using notifications. The key to a successful patching strategy when it comes to notifications is to understand the requirements of the environment you are working in and keeping a documented and consistent strategy. What types of patch content do you want to scan for? The answer to this question depends on what you licensed for and what content you want to scan for. Select the content that you want to scan for and deselect the content you don t use. For each content type the scanner connects to the Core Server to validate and download the detection rules. If there is a content type is not being used requests to the core can be reduced. This reduces the stress on the core server and speeds up the security scanner on the client. Scan and Repair Setting Tactical Implementation General Options Scan and Repair settings are stored on the core server and are updated automatically when vulscan runs. That means if you change the Scan and Repair settings that are configured for a device, the next time it runs vulscan it will update and use the new settings. Each client 15

16 machine has an "installed" Scan and Repair settings. That means that it is the default configuration that will be used on any tasks that don't have an assigned Scan and Repair settings. The currently "installed" settings can be found in the client machine inventory at: Computer - LANDesk Management - Vulnerability Scan - Settings - Scan and Repair Setting Name. The "installed" settings can be changed using a "Change settings..." task found the "Create a task" drop-down in the Patch Manager tool. Each of the settings and its effects can be found below. The settings described are from LANDesk Management Suite 9 so previous versions may be missing some options or present them slightly differently General Options Name: The name of the settings. If these are descriptive, or have names that make them easy to know where/how they apply it helps. Show progress dialog: This determines if the vulscan GUI will appear. Possible settings are always, never and only when repairing Hide if user is showing a presentation: This will hide the GUI if the client machine is running a full-screen presentation. Currently we only detect this condition with Microsoft Power Point. This WILL NOT prevent the scan or repair job from running, it will only hide the GUI. When no reboot is required: These settings apply when there is not a reboot. You can choose to wait for the user to close the GUI, or time out after a certain period of time and close. Recommendation: Always set this to "Close after timeout". Usually you are not required to wait for the user to just close the dialog, and it can cause tasks to timeout and return a bad/incorrect status. CPU utilization when scanning: This will attempt to control the CPU level when scanning. When set to low, the scans will take longer, but should have a reduced impact on the general computer use. High will result in the fastest scans. 16

17 Scheduled task status: This determines how much information is sent back to the core for a Scheduled Task run on the device, such as a repair job. Possible options here are: Send standard information, Send nothing, and Send debug information (not localized) Set as Default: This option sets the scan and repair setting to the default Scan and Repair setting. Scan Options Scan for: This pane allows you to set what should be scanned for when vulscan is run with these settings...group: A custom group of vulnerabilities can be set here. Groups can be created in the console and vulnerabilities can be added as needed. Vulnerabilities can be members of more than one group. Groups can have sub groups as well. If a parent group is selected here, all the child groups and vulnerabilities will be scanned. Immediately repair all detected items: This option can only be set if scanning for a group. It has the same effect as Autofix. Vulscan will scan for all the vulnerabilities in the group, then immediately request and install the patches for any detected items....type: If this option is selected, vulscan will scan for all definitions in each category checked below. It will only scan vulnerabilities that are in the Scan category on the core server. It WILL NOT scan for anything in the Do not scan, or Unassigned categories.... Vulnerabilities: This will scan for all definitions in the Scan group that are of the Vulnerability type. This is the most common definition. All of the Microsoft general, or "Patch Tuesday" patches will by this type.... Spyware: This will use the spyware engine to scan for any definitions in the Scan category that are Spyware definitions.... Security threats: This scans for Security threats definitions in the Scan category. These are things like firewall enabled, or telnet enabled. 17

18 ... Blocked applications: This scan will update the list of blocked applications that are blocked in real-time by softmon.exe when vulscan isn't running. You can select to put All blocked apps in the block list on the client or Only apps in group: an select a group of blocked apps.... Antivirus Updates: This will scan for needed AV updates. It can scan for updates on a variety of AV products besides LANDesk AV.... LANDesk Updates: This scans for any LANDesk updates in the scan group. This is limited to patches release as such by LANDesk, usually roll-ups and Service Packs. This is the only option available to customers that have not purchased LANDesk Patch Manager or Security Suite. All LANDesk customers can scan for and repair LANDesk vulnerabilities.... Software updates: This category is for a limited number of Software updates. Generally Lenovo ThinkVantage or Intel software.... Driver updates: This contains hardware and driver updates from some vendors such as Dell. It allows vulscan to scan for driver updates, BIOS updates and the like... Custom definitions: This category is for Custom definitions made by the end user. They can be used to do a number of things, including installing customized patches, or patches for internal software or software that LANDesk doesn't provide vulnerability data for. Repair Options Before repairing, installing, or uninstalling a patch: This setting determines when the patch will be installed. Once the job is run and started on the client, these options will be used to determine when the patch will be installed. The options are: o Immediately begin: The patch job will begin immediately, as soon as the client receives the job. o Notify user with message: The patch job will still begin immediately, but a message will be presented to the user indicating that the patching is happening. o Notify user, also allowing defer: The message is presented to the users. They can select to begin the patch installation, or they can defer it until the machine is locked or logged out. There is only one option and the user can't choose lock or logout, so the patch job will occur as soon as either condition is met. o Notify user, also allowing defer or cancel: This options presents the message to the user with the deferral option above, but also allows the user to cancel the job. If this option is selected the patches will not install and the console will report that the user canceled the job. o Wait to repair until machine is locked or screen saver is running: This will put the repair job on hold until the machine is either locked, or a screensaver starts. The patch job will continue after the machine is unlocked or the screensaver is canceled. o Wait to repair until user is logged off: This option will wait to install the patch until the user logs off. If the same user, or another user logs on during the repair job, it will continue patching until the job is complete. Message: This is the message that will display if an option is selected to notify user. If no end user response: This is what to do if a message is presented to the user and there is no response. 18

19 o Wait for user response before repair, install or uninstall: This will leave the message there until there is a response. As noted, this can cause scheduled tasks to timeout and/or fail o After timeout, automatically: If this option is selected, the message prompt will wait the specified time and then proceed with the action selected. The options are: Start install: This will just proceed to the patch installation Close: This will close the notification and not run the patch job Defer install till machine locked: This will defer the installation until the machine is locked or logged out. Start repair even if: This tells vulscan to start the repair job even when certain conditions are true o User is running a presentation: This will start the repair job even if a presentation is running. If this is unchecked the job will automatically be delayed until the machine is locked or logged out. Note: This only detects the machine as "running a presentation" for MS Power Point, full screen presentation at this time. o Reboot is already pending: A reboot is deemed to be already pending if there are any entries in the PendingFileRename key in the registry. Other applications can modify this key so if the machine is pending a reboot for ANY reason we will detect it and either continue or fail the job depending on this setting. Some AV applications are known to always set this key. Max bandwidth when downloading from source: This is the maximum bandwidth to be used when downloading files from the source (the core or preferred server). Max bandwidth when downloading from peer: This is the maximum bandwidth to use when downloading from a peer through the LANDesk Peer-Peer download technologies. Reboot Options These are the options used to configure when and how the machine is rebooted by vulscan. It can be configured to present a message, allow delays or cancels or to not reboot at all. When deciding whether to reboot o Never reboot: Once vulscan completes, regardless of what patches were installed the machine will not be rebooted by vulscan o Reboot only if needed: Once vulscan completes it will check the PendingFileRename key on the machine registry to determine if a reboot is needed. If it is the machine will be rebooted using the options configured 19

20 o Always reboot: When vulscan finishes, regardless of what it did, it will reboot the machine according to the reboot options configured When rebooting o Prompt user before rebooting: This will prompt the user before the reboot happens to let them know that it will happen o If no one is logged in, reboot immediately without prompting or delay: This allows vulscan to bypass the prompt if no one is logged in o Allow user to defer (snooze): These settings can be used to allow the user to defer or snooze the reboot for a period of time if needed Snooze time: This is how long the reboot will be delayed. Once the time is up the prompt will re-appear Max deferrals allowed: This is the maximum number of times that a reboot can be delayed. Once met, the Snooze button on the client will no longer be available. o Allow user to cancel reboot: When selected the user can cancel the reboot and it will not be re-attempted o Reboot message: This is the message that is presented to the user in the vulscan GUI when prompted to reboot o Wait for user response before rebooting (This can cause scheduled tasks to timeout): If this option is selected, the prompt to reboot will wait until there is a user response. If it takes too long, the scheduled task will timeout and report a failure to the core server o After timeout, automatically: If this option is selected, vulscan will automatically perform the selected action after the specified timeout period without user interaction. Snooze: This will snooze the reboot as configured Reboot: This will reboot the machine Close: This will close the dialog and cancel the reboot Network Settings These settings can be used to allow the machine to communicate with an alternate core server. Communicate with alternate core server. If this is enabled, vulscan will attempt to communicate with an alternate core server as specified below. o Server name: Put the alternate core server name here. It MUST be resolvable by the CLIENT systems. Note: The syntax for the Sever Name field should be ServerName:PortNumber where port number is the secure port 443 for SSL transmission. If you enter only a server name, without specifying port 443, it defaults to port 80 which is the standard HTTP port. By default vulscan operates on port 80. Pilot Configuration This setting can be used to tell machines using this Scan and Repair settings to additionally scan a certain group. This is used to test patches or vulnerabilities before general release. For example new patches can be added to a custom "Pilot" group and through these pilot settings be rolled out to a test group to make sure the new patches don't cause any problems with business applications. 20

21 Periodically scan and repair definitions in the following group. This enables the client machines with this setting to scan and AUTOMATICALLY repair all definitions in a custom group. Make sure to select a group Schedule This is the schedule that the machines will scan the pilot group on. This is configured the same way as other locally scheduled tasks on the client machine. Pro Tip: You can use this as the opposite of pilot group. If you have a set of patches that MUST be installed on client machines, you can add them to a custom group, and then specify it as the 'pilot' group. You can then set an independent schedule for it to run. Another example would be to have a normally scheduled scan that scans everything during the day, then set the 'pilot' group to run at night or during maintenance periods. Patches added to the custom group will be repaired. As you work through approving patches, simply add them to the custom group and you know that the next time the 'pilot' scan runs they will be installed on the clients. Be careful and test this to make sure it works the way you expect, because any patches in the 'pilot' group will be AUTOMATICALLY repaired when the scan runs. Spyware Scanning These settings can be used to override and modify the settings set in the client configuration for real-time spyware scanning. That means you can use it to enable or disable real-time scanning on a device. Normally this setting is part of the client setting, but if a Scan and Repair setting is set on a machine that has the Spyware override set, then it will change to whatever the Scan and Repair settings is configured to. Override settings from client configuration Select this if you want to override the real-time spyware scanning settings configured in the client configuration Settings o Enable real-time spyware blocking Set to enable real-time spyware scanning and blocking Notify user when spyware has been blocked Setting this will notify the user that spyware has been blocked. If it is not set, the spyware will still be blocked, but the user will not be notified. The core server will still have a record of the block If an application is not recognized as spyware, require user's approval before it can be installed If this is enabled, any application that attempts to install must be approved by the user even if it is not recognized as spyware. 21

22 Configure you Patching Strategy By the time you get to this point your patching strategy should be well planned out and documented. Now it is time to implement your strategy. Deploying patch comes down to two high-level strategies. As mentioned earlier, you can either use task based deployments or you can use Autofix. Regardless of the strategy chosen there are two important aspects to consider. First, make sure the actual patch is downloaded, not just the patch definition. Second, only definitions in the scan folder are scanned for. If the patch definition is not in the scan folder the patch cannot be deployed to the target device. Task Based Deployments Task based deployment can be configured one of two methods. The first method is generally preferred. Create a new custom group by right clicking in the Custom groups area and selecting New Group. By using custom groups it is easier to classify the patches. For example, you can set up a Test Patches group that would contain patches that are in testing. Once the patches pass the testing phase they can be moved into a different custom group representing patches that are to be deployed. To schedule the patches in the repair group right click on the custom group and select Repair Secondly, by highlighting the vulnerability, multiple vulnerabilities can be selected, to be deployed and right-clicking and selecting Repair. Regardless of the method used once Repair is selected the Create repair task window will appear. 22

23 When the Repair as a scheduled task box is check the task will be ran as a push-based task. If the Repair as a policy box is checked the task will run as a policy. If both the Repair as a scheduled task and the Repair as a policy are checked then the task will be set up as a policy supported push. General page Task name: Identifies the repair task with a unique name. The default is the name of the selected definition or the custom group. You can edit this name if you prefer. Repair as a scheduled task: Creates a security repair task in the Scheduled tasks window when you click OK. Split into staging task and repair task: (Optional) Allows you to create to separate tasks in the Scheduled tasks tool; one task for staging the required patch files in the target device's local cache; and one task for actually installing those patch files on the affected devices. Select computers to repair: Specifies which devices to add to the scheduled repair task. You can choose no devices, all affected devices (devices where the definition was detected by the last security scan), or only the affected devices that are also selected (this last option is available only when you access the Schedule repair dialog box from within a device Security and Patch Information dialog box). Use Multicast: Enables Targeted Multicast for patch deployment to devices. Click this option, and click Multicast Options if you want to configure multicast options. For more information, see About the Multicast options dialog box. Repair as a policy: Creates a security repair policy when you click OK. Add query representing affected devices: Creates a new query, based on the selected definition, and applies it to the policy. This query-based policy will search for devices affected by the selected definition, and deploy the associated patch. 23

24 Download patch only from local peers: Restricts patch deployment so that it will only take place if the patch file is located in the device local cache or on a peer on the same subnet. This option conserves network bandwidth, but note that for the patch installation to be successful, the patch file must currently reside in one of these two places. Download patch only (Do not repair): Downloads the patch file to the patch repository but does not deploy the patch. You can use this option if you want to retrieve the patch file in a staging scenario for testing purposes before actual deployment. Scan and repair settings: Specifies which scan and repair settings are used for the repair task to determine whether the security scanner displays on devices when it is running. Select a scan and repair settings from the drop-down list, or click Configure to create a new scan and repair settings. Patches page Use this page to show either required patches only or all associated patches for the selected vulnerability. (NOTE: The fields on this page are the same as the fields on the About the Download associated patches dialog box.) To download patches directly from this page, if they have not already been downloaded and placed in the patch repository, click Download. Multicast options dialog box Use this dialog box to configure the following Targeted Multicast options for a scheduled security repair task. Multicast Domain Discovery: Use multicast domain discovery: Select this option if you want Targeted Multicast to do a domain discovery for this job. This option won't save the domain discovery results for reuse. Use multicast domain discovery and save results: Select this option if you want Targeted Multicast to do a domain discovery for this job and save the results for future use, saving time on subsequent multicasts. Use results of last multicast domain discovery: Use this option once you've had Targeted Multicast do a domain discovery that saved the results. Have domain representative wake up computers: Use this option if you want computers that support Wake On LAN technology to turn on so they can receive the multicast. Number of seconds to wait after Wake on LAN: How long domain representatives wait to multicast after the Wake On LAN packet has been sent. The default waiting period is 120 seconds. If some computers on your network take longer than 120 seconds to boot, you should increase this value. The maximum value allowed is 3600 seconds (one hour). The options below let you configure task-specific Targeted Multicast parameters. The defaults should be fine for most multicasts. Here is what the options do: Maximum number of multicast domain representatives working simultaneously: No more than this number of representatives will be actively doing a multicast at one time. Limit the processing of machines that failed multicast: When a device fails to receive the file through multicast, it will download the file from the Web or file server. This parameter can be used to limit the number of devices that will obtain the file at one time. For example, if the maximum number of threads was 200 and the maximum number of multicast 24

25 Autofix failure threads was 20, the Custom Job dialog box would process no more than 20 computers at a time that failed the multicast. The Custom Job dialog box will process up to 200 devices at a time if they successfully received the multicast, but no more than 20 of the 200 threads will be processing devices that failed the multicast task. If this value is set to 0, the Custom Job dialog box won't perform the distribution portion of the task for any computer that failed multicast. Number of days the files stay in the cache: Amount of time that the file being multicast can stay in the cache on each target computer. After this period of time, the file will be automatically purged. Number of days the files stay in multicast domain representative cache: Amount of time that the file being multicast can stay in the cache on the multicast domain representative. After this period of time, the file will be automatically purged. Minimum number of milliseconds between packet transmissions (WAN or Local): Minimum amount of time to wait between sending out multicast packets. This value is only used when the domain representative isn't multicasting a file from its own cache. If this parameter isn't specified, then the default minimum sleep time stored on the subnet/domain representative computer will be used. You can use this parameter to limit bandwidth usage across the WAN. Maximum number of milliseconds between packet transmissions (WAN or Local): Maximum amount of time to wait between sending out multicast packets. For more information, see Minimum number of milliseconds between packet transmissions above. Enabling Autofix requires three steps: 1- Enable Autofix in the Agent Configuration 2- Enable Autofix in the Scan and repair settings 3- Enable Autofix on the vulnerability In the Agent Configuration Tool Never Autofix: If this option is set in the Agent Configuration tool the end device will not Autofix regardless of the settings in the Scan and repair settings. This is a global setting for all devices with this particular Agent Configuration. In order to enable Autofix ensure the box contains a check mark. Never Reboot: This option is also global. If it is selected the agent will not reboot the device with this particular agent configuration deployed. Left unchecked the reboots will be handled by the Scan and Repair settings associated with a repair task. When Autofix is being used the agents default Scan and repair settings will be used. 25