US20070033635A1 - Method, apparatus, and program product for autonomic patch deployment based on autonomic patch risk assessment and policies - Google Patents

Method, apparatus, and program product for autonomic patch deployment based on autonomic patch risk assessment and policies Download PDF

Info

Publication number
US20070033635A1
US20070033635A1 US11/195,023 US19502305A US2007033635A1 US 20070033635 A1 US20070033635 A1 US 20070033635A1 US 19502305 A US19502305 A US 19502305A US 2007033635 A1 US2007033635 A1 US 2007033635A1
Authority
US
United States
Prior art keywords
patch
risk
policy
level
deploying
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/195,023
Inventor
Praveen Hirsave
Puthukode Ramachandran
Edmund Troche
Minto Tsai
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US11/195,023 priority Critical patent/US20070033635A1/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: HIRSAVE, PRAVEEN PRASANNA KUMAR, RAMACHANDRAN, PUTHUKODE G., TROCHE, EDMUND, TSAI, MINTO
Publication of US20070033635A1 publication Critical patent/US20070033635A1/en
Priority to US12/131,562 priority patent/US8261353B2/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577Assessing vulnerabilities and evaluating computer system security
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning

Definitions

  • the present invention relates to data processing and, in particular, to patching applications in a managed computer environment. Still more particularly, the present invention provides a method, apparatus, and program for automatic patch deployment based on an assessed risk and policies in a managed computer environment.
  • a large computer organization may employ a data center, which is a room full of servers.
  • Each server may run several applications that provide services to customers or other applications within the organization. Often, these servers run continuously, providing services to users throughout the world around the clock. As a result, any downtime experienced by a server is potentially costly or damaging to the reputation of the organization. For example, the organization may have service level agreements with customers that may not be met due to server downtime.
  • a managing server In a managed computer environment, deployment of software is controlled by a managing server.
  • an update also referred to as a “patch,” for an application is available
  • an administrator may determine whether to push the update to the managed endpoints.
  • Managed endpoints may be any device within the managed computer environment, such as end user client devices, servers, routers, and the like.
  • a patch may disrupt the operation of the device. Therefore, the administrator must assess the risk of executing the update and deploy the patch accordingly.
  • patch deployment is a manual process in which the data center administrator views patches that have been released, reads the documentation, and determines whether the patch is applicable to the data center.
  • patch deployment is not a trivial task, and the decision to install a patch, as well as when and how to install the patch, may be made with incomplete information. The administrator must exercise extreme caution when assessing the risk of a patch and scheduling deployment.
  • the present invention recognizes the disadvantages of the prior art and provides an automatic patch deployment system that deploys a patch according to an assessed risk and a policy.
  • the policy may specify actions to be taken to deploy the patch for different categories of risk.
  • the automatic patch deployment system receives a patch notification, an assessment of the risk, and the policy and deploys the patch accordingly. For example, installation of a patch may be indefinitely delayed for high risk patches, rescheduled for medium risk patches, or installed immediately for low risk patches.
  • FIG. 1 depicts a pictorial representation of a network of data processing systems in which aspects of the present invention may be implemented
  • FIG. 2 is a block diagram of a data processing system that may be implemented as a server in accordance with an illustrative embodiment of the present invention
  • FIG. 3 is a block diagram of a data processing system in which aspects of the present invention may be implemented
  • FIG. 4 is a visual diagram illustrating the operational flow of an automatic risk assessment system in accordance with exemplary aspects of the present invention
  • FIG. 5 is a visual diagram illustrating the operational flow of an automatic patch deployment system in accordance with exemplary aspects of the present invention
  • FIG. 6 is a flowchart illustrating operation of an automatic patch deployment system in accordance with exemplary aspects of the present invention.
  • FIG. 7 is a flowchart illustrating operation of automatic patch deployment system in accordance with an example policy in accordance with an exemplary embodiment of the present invention.
  • FIGS. 1-3 are provided as exemplary diagrams of data processing environments in which embodiments of the present invention may be implemented. It should be appreciated that FIGS. 1-3 are only exemplary and are not intended to assert or imply any limitation with regard to the environments in which aspects or embodiments of the present invention may be implemented. Many modifications to the depicted environments may be made without departing from the spirit and scope of the present invention.
  • FIG. 1 depicts a pictorial representation of a network of data processing systems in which aspects of the present invention may be implemented.
  • Network data processing system 100 is a network of computers in which embodiments of the present invention may be implemented.
  • Network data processing system 100 contains a network 102 , which is the medium used to provide communications links between various devices and computers connected together within network data processing system 100 .
  • Network 102 may include connections, such as wire, wireless communication links, or fiber optic cables.
  • servers 122 , 124 , 126 connect to network 102 along with storage unit 106 .
  • clients 112 , 114 , 116 connect to network 102 .
  • These clients 112 , 114 , 116 may be, for example, personal computers or network computers.
  • server 126 for example, provides data and/or applications to clients 112 , 114 , 116 .
  • Clients 112 , 114 , 116 are clients to server 122 .
  • Network data processing system 100 may include additional servers, clients, and other devices not shown.
  • server 124 provides management services for devices in network data processing system 100 .
  • server 126 and client 116 may be managed nodes in the managed computer environment.
  • Server 122 provides application monitoring to determine the status of an application that is to be patched.
  • Server 122 may collect from an application running on, for example, server 126 , metrics that indicate a level of activity.
  • managing server 124 and application monitoring server 122 may be server applications or processes running on the same machine or different machines.
  • server 124 automatically assesses the risk of installing the patch on a managed endpoint.
  • a patch metadata may contain a list of files that are “touched” by the patch.
  • the term “touched,” as used herein, refers to when a file is modified, updated, or deleted by a patch.
  • the patch may replace a file with a newer version of a file, modify attributes of the file, or delete the file.
  • Application monitoring server 122 may collect data about the application to be patched, such as the amount of memory being used, which may indicate that the application is under heavy use, or whether one or more touched files are locked by the application to be patched or another application. Using the list of touched files, the information collected by application monitoring server 122 , and other information, such as time of patch deployment and the like, managing server 124 determines a measure of risk for deploying the patch.
  • the level of risk represents likelihood that the patch will disrupt activity of the server. For example, if a touched file is locked by an application, the server will require a reboot to gain access to the file. A reboot is a very disruptive action. As another example, if a large amount of memory is being used by the server, then there is a high likelihood that the patching the application will negatively affect the productivity of the server.
  • network data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another.
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational and other computer systems that route data and messages.
  • network data processing system 100 also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN).
  • FIG. 1 is intended as an example, and not as an architectural limitation for different embodiments of the present invention.
  • Data processing system 200 may be a symmetric multiprocessor (SMP) system including a plurality of processors 202 and 204 that connect to system bus 206 . Alternatively, a single processor system may be employed. Also connected to system bus 206 is memory controller/cache 208 , which provides an interface to local memory 209 . I/O bus bridge 210 connects to system bus 206 and provides an interface to I/O bus 212 . Memory controller/cache 208 and I/O bus bridge 210 may be integrated as depicted.
  • SMP symmetric multiprocessor
  • Peripheral component interconnect (PCI) bus bridge 214 connects to I/O bus 212 provides an interface to PCI local bus 216 .
  • PCI local bus 216 A number of modems may be connected to PCI local bus 216 .
  • Typical PCI bus implementations will support four PCI expansion slots or add-in connectors.
  • Communications links to clients 108 - 112 in FIG. 1 may be provided through modem 218 and network adapter 220 connected to PCI local bus 216 through add-in connectors.
  • Additional PCI bus bridges 222 and 224 provide interfaces for additional PCI local buses 226 and 228 , from which additional modems or network adapters may be supported. In this manner, data processing system 200 allows connections to multiple network computers.
  • a memory-mapped graphics adapter 230 and hard disk 232 may also be connected to I/O bus 212 as depicted, either directly or indirectly.
  • FIG. 2 may vary.
  • other peripheral devices such as optical disk drives and the like, also may be used in addition to or in place of the hardware depicted.
  • the depicted example is not meant to imply architectural limitations with respect to the present invention.
  • the data processing system depicted in FIG. 2 may be, for example, an IBM eServerTM pSeries® computer system, running the Advanced Interactive Executive (AIX®) operating system or LINUX operating system (eServer, pSeries and AIX are trademarks of International Business Machines Corporation in the United States, other countries, or both while Linux is a trademark of Linus Torvalds in the United States, other countries, or both).
  • AIX Advanced Interactive Executive
  • LINUX LINUX operating system
  • Data processing system 300 is an example of a computer, such as client 108 in FIG. 1 , in which code or instructions implementing the processes for embodiments of the present invention may be located.
  • data processing system 300 employs a hub architecture including a north bridge and memory controller hub (MCH) 308 and a south bridge and input/output (I/O) controller hub (ICH) 310 .
  • MCH north bridge and memory controller hub
  • I/O input/output
  • ICH input/output controller hub
  • Processor 302 , main memory 304 , and graphics processor 318 are connected to MCH 308 .
  • Graphics processor 318 may be connected to the MCH through an accelerated graphics port (AGP), for example.
  • AGP accelerated graphics port
  • local area network (LAN) adapter 312 audio adapter 316 , keyboard and mouse adapter 320 , modem 322 , read only memory (ROM) 324 , hard disk drive (HDD) 326 , CD-ROM drive 330 , universal serial bus (USB) ports and other communications ports 332 , and PCI/PCIe devices 334 connect to ICH 310 .
  • PCI/PCIe devices may include, for example, Ethernet adapters, add-in cards, PC cards for notebook computers, etc. PCI uses a card bus controller, while PCIe does not.
  • ROM 324 may be, for example, a flash binary input/output system (BIOS).
  • BIOS binary input/output system
  • Hard disk drive 326 and CD-ROM drive 330 may use, for example, an integrated drive electronics (IDE) or serial advanced technology attachment (SATA) interface.
  • a super I/O (SIO) device 336 may be connected to ICH 310 .
  • IDE integrated drive electronics
  • SATA serial advanced technology
  • An operating system runs on processor 302 and coordinates and provides control of various components within data processing system 300 in FIG. 3 .
  • the operating system may be a commercially available operating system such as Microsoft® Windows® XP (Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both).
  • An object oriented programming system such as the JavaTM programming system, may run in conjunction with the operating system and provides calls to the operating system from JavaTM programs or applications executing on data processing system 300 (Java is a trademark of Sun Microsystems, Inc. in the United States, other countries, or both).
  • Instructions for the operating system, the object-oriented programming system, and applications or programs are located on storage devices, such as hard disk drive 326 , and may be loaded into main memory 304 for execution by processor 302 .
  • the processes for embodiments of the present invention are performed by processor 302 using computer implemented instructions, which may be located in a memory such as, for example, main memory 304 , memory 324 , or in one or more peripheral devices 326 and 330 . These processes may be executed by any processing unit, which may contain one or more processors.
  • FIGS. 1-3 may vary depending on the implementation.
  • Other internal hardware or peripheral devices such as flash memory, equivalent non-volatile memory, or optical disk drives and the like, may be used in addition to or in place of the hardware depicted in FIGS. 1-3 .
  • the processes of the present invention may be applied to a multiprocessor data processing system.
  • data processing system 300 may be a personal digital assistant (PDA), which is configured with flash memory to provide non-volatile memory for storing operating system files and/or user-generated data.
  • PDA personal digital assistant
  • a bus system may be comprised of one or more buses, such as system bus 206 , I/O bus 212 and PCI buses 216 , 226 , 228 , as shown in FIG. 2 .
  • the bus system may be implemented using any type of communications fabric or architecture that provides for a transfer of data between different components or devices attached to the fabric or architecture.
  • a communications unit may include one or more devices used to transmit and receive data, such as modem 218 or network adapter 220 of FIG. 2 or modem 322 or LAN 312 of FIG. 3 .
  • a memory may be, for example, local memory 209 or cache, such as found in memory controller/cache 208 of FIG. 2 , or main memory 304 of FIG. 3 .
  • a processing unit may include one or more processors or central processing units, such as processor 202 or processor 204 of FIG. 2 or processor 302 of FIG. 3 .
  • processors or central processing units such as processor 202 or processor 204 of FIG. 2 or processor 302 of FIG. 3 .
  • FIGS. 1-3 and above-described examples are not meant to imply architectural limitations.
  • data processing system 300 also may be a tablet computer, laptop computer, or telephone device in addition to taking the form of a PDA.
  • FIG. 4 is a visual diagram illustrating the operational flow of an automatic risk assessment system in accordance with exemplary aspects of the present invention.
  • a new patch is released by a vendor and patch notification 410 is received at managing server 420 .
  • a patch may be released, for example, to update functionality of an application, to fix bugs, or to update a device driver.
  • the patch itself may replace files with newer files, modify attributes of a file, or delete files, for instance.
  • the patch may be associated with a particular application, an operating system component, or a device driver, for example.
  • Patch notification 410 may include the patch files and metadata describing the patch. Patch notification 410 may also include a list of touched files or, in other words, files affected by the patch.
  • managing server 420 performs patch risk assessment. Managing server 420 checks the applicability of the patch based on the files affected by the patch, activity of the node being patched from metrics collected by application monitoring server 430 , and other factors.
  • managing server 420 applies the patch to managed endpoint 440 . Based on the risk assessment from step 2 , managing server 420 can apply the patch immediately, schedule deployment of the patch for a later time, or notify the administrator of a high risk so the administrator may take appropriate measures. Managing server 420 also communicates with policy engine 450 , which identifies policies from policy storage 460 that apply to the patch being deployed. Managing server 420 then applies the identified policies when deploying the patch.
  • managing server 420 may send patch information to policy engine 450 indicating that the patch updates an application associated with a service level agreement and is to be deployed in China.
  • Policy engine 450 identifies the policies that apply to patches that affect applications associated with a service level agreement and policies that apply to scheduling patch deployment in China.
  • Managing server 420 may then apply those policies to the patch based on the risk assessment and schedule installation of the patch accordingly.
  • FIG. 5 a visual diagram is shown illustrating the operational flow of an automatic patch deployment system in accordance with exemplary aspects of the present invention.
  • Automatic patch deployment system 520 is illustrated using a MAPE (monitor, analyze, plan, execute) loop diagram.
  • the system begins by monitoring individual files and assigning weights, shown as 502 . Files may be assigned higher lower weights based on how frequently, or recently, they are accessed, for example. In the depicted example, the file MSVC.DLL is assigned a weight of 20, the file Kernel.DLL is assigned a weight of 20, and the file XXX.DLL is assigned a weight of 5.
  • Monitor component 522 monitors activity on the endpoint on which the patch is to be installed.
  • the endpoint is shown as element 536 , although element 536 may represent an application, operating system component, device driver or any other element that is to be affected by the patch.
  • monitor component 522 collects usage metrics 504 to monitor activity, such as a percentage of usage of resources being used, for example, via sensors 532 .
  • sensors 532 may be an application monitor component of an application being patched and receive a metric indicating a percentage of memory being used by the application.
  • sensors 532 may be an application monitor component of an application being patched and receive a metric indicating a percentage of memory being used by the application.
  • Analysis component 524 analyzes the patch based on weights 502 , metrics 504 , and policy 506 to assess the risk of the patch. Analysis component 524 may determine a percentage risk that the patch will result in a hang or reboot or will significantly degrade productivity of the endpoint. Policy 506 may, for example, define how the percentage risk is categorized into high risk, medium risk, or low risk. In the depicted example, policy 506 defines a 50% or greater risk as high risk, less than 50% and greater than or equal to 20% as medium risk, and less than 20% as low risk. High risk may indicate, for example, that the risk is likely to require a reboot, while low risk may indicate that the patch can be installed immediately without significantly affecting productivity of the managed endpoint.
  • Policy 506 may be specific to a particular patch, specific to a particular endpoint, or universal to all patches being deployed to all endpoints. For example, a policy for an end user client device may be more tolerant than a policy for a server providing critical services to customers under a service level agreement. As another example, a policy for a non-critical patch may allow a greater distribution within the medium risk category because productivity of the endpoint may be more important than the timeliness of the patch.
  • Planning component 526 determines how to install the patch based on the risk assessment from analysis component 524 . More particularly, planning component 526 may make a determination of whether to install the patch and when to install the patch based on policy 508 .
  • policy 508 indicates that installation of a patch with high risk shall be delayed, while a patch with medium risk shall be installed when the endpoint is idle and a patch with low risk may be installed immediately.
  • planning component 526 determines that a patch is to be installed
  • execution component 528 effectuates plan from planning component 526 to install the patch 510 via effectors 534 .
  • Effectors 534 apply the patch to element 536 by replacing files, updating files, modifying attributes, altering configurations, deleting files, and the like.
  • Monitor component 522 , analysis component 524 , planning component 526 , and execution component 528 operate based on knowledge 530 .
  • Knowledge 530 is the engine that drives the MAPE loop. Knowledge 530 schedules and analyzes the monitoring data. Knowledge 530 executes based on the policies and applies policies based on the data.
  • FIG. 6 is a flowchart illustrating operation of an automatic patch deployment system in accordance with exemplary aspects of the present invention. Operation begins and the automatic patch deployment system receives a patch notification (block 602 ). Then, the automatic patch deployment system loads a policy for patch deployment (block 604 ) and monitors application activity (block 606 ). Next, the automatic patch deployment system analyzes the patch (block 608 ) and determines a level of risk for the patch (block 610 ). Thereafter, the automatic patch deployment system deploys the patch according to the policy (block 612 ) and operation ends.
  • FIG. 7 is a flowchart illustrating operation of automatic patch deployment system in accordance with an example policy in accordance with an exemplary embodiment of the present invention. More particularly, FIG. 7 illustrates deployment of a patch according to the policy shown as element 508 in FIG. 5 . Operation begins and the automatic patch deployment system determines whether the patch risk is high, medium, or low (block 702 ). If the patch risk is high, the automatic patch deployment system delays the patch install (block 704 ) and notifies the administrator (block 706 ) of the delayed patch install. The administrator may then manually assess the situation and determine whether activity of the endpoint machine should be interrupted to deploy the patch.
  • the automatic patch deployment system determines whether the application is idle (block 708 ). If the application is not idle, the automatic patch deployment returns to block 708 to wait until the application is idle. If the application is idle in block 708 , the automatic patch deployment system installs the patch (block 710 ) and operation ends.
  • the patch risk is low in block 702 , then the patch is not likely to interrupt activity of the endpoint machine, and the automatic patch deployment system proceeds directly to block 710 to install the patch and operation ends.
  • the example flow of operation shown in FIG. 7 is specific to one example policy.
  • the deployment of a patch may be fully customized using a policy file, such as policy 508 shown in FIG. 5 . That is, an administrator, when creating the policy, may determine that a patch with high risk may be installed when the application is idle.
  • a policy may specify that when a patch having a medium risk is deployed, the patch may be installed immediately with a notification being sent to the administrator so the administrator may monitor completion of the patch.
  • the policy may vary depending upon the endpoint device, the element being patched, whether there is a service level agreement, etc.
  • the policy may also be based on more or fewer categories of risk or even other representations of risk, such as percentage values, types of risk (reboot, hang, high memory consumption, low disk space, etc.), and the like.
  • FIG. 5 depicts separate components 502 , 504 , 506 , 508 , that specify policy information for assessing and deploying a patch; however, all of these components may be stored in a single policy file.
  • the policy file may take the form of a table, text file, or other file type.
  • the policy file may take the form of a markup language document, such as an extensible markup language (XML) document or the like.
  • the present invention solves the disadvantages of the prior art by providing an automatic patch deployment system that deploys the patch according to the assessed risk and a policy.
  • the policy may specify actions to be taken to deploy the patch for different categories of risk.
  • the automatic patch deployment system receives a patch notification, an assessment of the risk, and the policy and deploys the patch accordingly. For example, installation of a patch may be indefinitely delayed for high risk patches, rescheduled for medium risk patches, or installed immediately for low risk patches.
  • the invention can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment containing both hardware and software elements.
  • the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
  • the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system.
  • a computer-usable or computer-readable medium may be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with an instruction execution system, apparatus, or device.
  • the medium may be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium.
  • Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk.
  • Current examples of optical disks include compact disk—read only memory (CD-ROM), compact disk—read/write (CD-R/W) and digital video disk (DVD).
  • a data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus.
  • the memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
  • I/O devices including but not limited to keyboards, displays, pointing devices, etc. may be coupled to the system either directly or through intervening I/O controllers.
  • Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks.
  • Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.

Abstract

An automatic patch deployment system is provided that deploys a patch according to an assessed risk and a policy. The policy may specify actions to be taken to deploy the patch for different categories of risk. The automatic patch deployment system receives a patch notification, an assessment of the risk, and the policy and deploys the patch accordingly. For example, installation of a patch may be indefinitely delayed for high risk patches, rescheduled for medium risk patches, or installed immediately for low risk patches.

Description

    BACKGROUND OF THE INVENTION
  • 1. Field of the Invention
  • The present invention relates to data processing and, in particular, to patching applications in a managed computer environment. Still more particularly, the present invention provides a method, apparatus, and program for automatic patch deployment based on an assessed risk and policies in a managed computer environment.
  • 2. Description of the Related Art
  • A large computer organization may employ a data center, which is a room full of servers. Each server may run several applications that provide services to customers or other applications within the organization. Often, these servers run continuously, providing services to users throughout the world around the clock. As a result, any downtime experienced by a server is potentially costly or damaging to the reputation of the organization. For example, the organization may have service level agreements with customers that may not be met due to server downtime.
  • In a managed computer environment, deployment of software is controlled by a managing server. When an update, also referred to as a “patch,” for an application is available, an administrator may determine whether to push the update to the managed endpoints. Managed endpoints may be any device within the managed computer environment, such as end user client devices, servers, routers, and the like. In the case of servers, a patch may disrupt the operation of the device. Therefore, the administrator must assess the risk of executing the update and deploy the patch accordingly.
  • Currently, deployment of a patch is a manual process in which the data center administrator views patches that have been released, reads the documentation, and determines whether the patch is applicable to the data center. However, patch deployment is not a trivial task, and the decision to install a patch, as well as when and how to install the patch, may be made with incomplete information. The administrator must exercise extreme caution when assessing the risk of a patch and scheduling deployment.
  • SUMMARY OF THE INVENTION
  • The present invention recognizes the disadvantages of the prior art and provides an automatic patch deployment system that deploys a patch according to an assessed risk and a policy. The policy may specify actions to be taken to deploy the patch for different categories of risk. The automatic patch deployment system receives a patch notification, an assessment of the risk, and the policy and deploys the patch accordingly. For example, installation of a patch may be indefinitely delayed for high risk patches, rescheduled for medium risk patches, or installed immediately for low risk patches.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
  • FIG. 1 depicts a pictorial representation of a network of data processing systems in which aspects of the present invention may be implemented;
  • FIG. 2 is a block diagram of a data processing system that may be implemented as a server in accordance with an illustrative embodiment of the present invention;
  • FIG. 3 is a block diagram of a data processing system in which aspects of the present invention may be implemented;
  • FIG. 4 is a visual diagram illustrating the operational flow of an automatic risk assessment system in accordance with exemplary aspects of the present invention;
  • FIG. 5 is a visual diagram illustrating the operational flow of an automatic patch deployment system in accordance with exemplary aspects of the present invention;
  • FIG. 6 is a flowchart illustrating operation of an automatic patch deployment system in accordance with exemplary aspects of the present invention; and
  • FIG. 7 is a flowchart illustrating operation of automatic patch deployment system in accordance with an example policy in accordance with an exemplary embodiment of the present invention.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
  • FIGS. 1-3 are provided as exemplary diagrams of data processing environments in which embodiments of the present invention may be implemented. It should be appreciated that FIGS. 1-3 are only exemplary and are not intended to assert or imply any limitation with regard to the environments in which aspects or embodiments of the present invention may be implemented. Many modifications to the depicted environments may be made without departing from the spirit and scope of the present invention.
  • With reference now to the figures, FIG. 1 depicts a pictorial representation of a network of data processing systems in which aspects of the present invention may be implemented. Network data processing system 100 is a network of computers in which embodiments of the present invention may be implemented. Network data processing system 100 contains a network 102, which is the medium used to provide communications links between various devices and computers connected together within network data processing system 100. Network 102 may include connections, such as wire, wireless communication links, or fiber optic cables.
  • In the depicted example, servers 122, 124, 126 connect to network 102 along with storage unit 106. In addition, clients 112, 114, 116 connect to network 102. These clients 112, 114, 116 may be, for example, personal computers or network computers. In the depicted example, server 126, for example, provides data and/or applications to clients 112, 114, 116. Clients 112, 114, 116 are clients to server 122. Network data processing system 100 may include additional servers, clients, and other devices not shown.
  • In accordance with an illustrative aspect of the present invention, server 124 provides management services for devices in network data processing system 100. For example, server 126 and client 116 may be managed nodes in the managed computer environment. Server 122 provides application monitoring to determine the status of an application that is to be patched. Server 122 may collect from an application running on, for example, server 126, metrics that indicate a level of activity. Although depicted in the example shown in FIG. 1 as separate computer devices in network data processing system 100, managing server 124 and application monitoring server 122 may be server applications or processes running on the same machine or different machines.
  • In accordance with an illustrative aspect of the present invention, server 124 automatically assesses the risk of installing the patch on a managed endpoint. A patch metadata may contain a list of files that are “touched” by the patch. The term “touched,” as used herein, refers to when a file is modified, updated, or deleted by a patch. For example, the patch may replace a file with a newer version of a file, modify attributes of the file, or delete the file.
  • Application monitoring server 122 may collect data about the application to be patched, such as the amount of memory being used, which may indicate that the application is under heavy use, or whether one or more touched files are locked by the application to be patched or another application. Using the list of touched files, the information collected by application monitoring server 122, and other information, such as time of patch deployment and the like, managing server 124 determines a measure of risk for deploying the patch.
  • The level of risk represents likelihood that the patch will disrupt activity of the server. For example, if a touched file is locked by an application, the server will require a reboot to gain access to the file. A reboot is a very disruptive action. As another example, if a large amount of memory is being used by the server, then there is a high likelihood that the patching the application will negatively affect the productivity of the server.
  • In the depicted example, network data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational and other computer systems that route data and messages. Of course, network data processing system 100 also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN). FIG. 1 is intended as an example, and not as an architectural limitation for different embodiments of the present invention.
  • Referring to FIG. 2, a block diagram of a data processing system that may be implemented as a server, such as server 104 in FIG. 1, is depicted in accordance with an illustrative embodiment of the present invention. Data processing system 200 may be a symmetric multiprocessor (SMP) system including a plurality of processors 202 and 204 that connect to system bus 206. Alternatively, a single processor system may be employed. Also connected to system bus 206 is memory controller/cache 208, which provides an interface to local memory 209. I/O bus bridge 210 connects to system bus 206 and provides an interface to I/O bus 212. Memory controller/cache 208 and I/O bus bridge 210 may be integrated as depicted.
  • Peripheral component interconnect (PCI) bus bridge 214 connects to I/O bus 212 provides an interface to PCI local bus 216. A number of modems may be connected to PCI local bus 216. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to clients 108-112 in FIG. 1 may be provided through modem 218 and network adapter 220 connected to PCI local bus 216 through add-in connectors.
  • Additional PCI bus bridges 222 and 224 provide interfaces for additional PCI local buses 226 and 228, from which additional modems or network adapters may be supported. In this manner, data processing system 200 allows connections to multiple network computers. A memory-mapped graphics adapter 230 and hard disk 232 may also be connected to I/O bus 212 as depicted, either directly or indirectly.
  • Those of ordinary skill in the art will appreciate that the hardware depicted in FIG. 2 may vary. For example, other peripheral devices, such as optical disk drives and the like, also may be used in addition to or in place of the hardware depicted. The depicted example is not meant to imply architectural limitations with respect to the present invention.
  • The data processing system depicted in FIG. 2 may be, for example, an IBM eServer™ pSeries® computer system, running the Advanced Interactive Executive (AIX®) operating system or LINUX operating system (eServer, pSeries and AIX are trademarks of International Business Machines Corporation in the United States, other countries, or both while Linux is a trademark of Linus Torvalds in the United States, other countries, or both).
  • With reference now to FIG. 3, a block diagram of a data processing system is shown in which aspects of the present invention may be implemented. Data processing system 300 is an example of a computer, such as client 108 in FIG. 1, in which code or instructions implementing the processes for embodiments of the present invention may be located. In the depicted example, data processing system 300 employs a hub architecture including a north bridge and memory controller hub (MCH) 308 and a south bridge and input/output (I/O) controller hub (ICH) 310. Processor 302, main memory 304, and graphics processor 318 are connected to MCH 308. Graphics processor 318 may be connected to the MCH through an accelerated graphics port (AGP), for example.
  • In the depicted example, local area network (LAN) adapter 312, audio adapter 316, keyboard and mouse adapter 320, modem 322, read only memory (ROM) 324, hard disk drive (HDD) 326, CD-ROM drive 330, universal serial bus (USB) ports and other communications ports 332, and PCI/PCIe devices 334 connect to ICH 310. PCI/PCIe devices may include, for example, Ethernet adapters, add-in cards, PC cards for notebook computers, etc. PCI uses a card bus controller, while PCIe does not. ROM 324 may be, for example, a flash binary input/output system (BIOS). Hard disk drive 326 and CD-ROM drive 330 may use, for example, an integrated drive electronics (IDE) or serial advanced technology attachment (SATA) interface. A super I/O (SIO) device 336 may be connected to ICH 310.
  • An operating system runs on processor 302 and coordinates and provides control of various components within data processing system 300 in FIG. 3. The operating system may be a commercially available operating system such as Microsoft® Windows® XP (Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both). An object oriented programming system, such as the Java™ programming system, may run in conjunction with the operating system and provides calls to the operating system from Java™ programs or applications executing on data processing system 300 (Java is a trademark of Sun Microsystems, Inc. in the United States, other countries, or both).
  • Instructions for the operating system, the object-oriented programming system, and applications or programs are located on storage devices, such as hard disk drive 326, and may be loaded into main memory 304 for execution by processor 302. The processes for embodiments of the present invention are performed by processor 302 using computer implemented instructions, which may be located in a memory such as, for example, main memory 304, memory 324, or in one or more peripheral devices 326 and 330. These processes may be executed by any processing unit, which may contain one or more processors.
  • Those of ordinary skill in the art will appreciate that the hardware in FIGS. 1-3 may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash memory, equivalent non-volatile memory, or optical disk drives and the like, may be used in addition to or in place of the hardware depicted in FIGS. 1-3. Also, the processes of the present invention may be applied to a multiprocessor data processing system. As some illustrative examples, data processing system 300 may be a personal digital assistant (PDA), which is configured with flash memory to provide non-volatile memory for storing operating system files and/or user-generated data.
  • A bus system may be comprised of one or more buses, such as system bus 206, I/O bus 212 and PCI buses 216, 226, 228, as shown in FIG. 2. Of course the bus system may be implemented using any type of communications fabric or architecture that provides for a transfer of data between different components or devices attached to the fabric or architecture. A communications unit may include one or more devices used to transmit and receive data, such as modem 218 or network adapter 220 of FIG. 2 or modem 322 or LAN 312 of FIG. 3. A memory may be, for example, local memory 209 or cache, such as found in memory controller/cache 208 of FIG. 2, or main memory 304 of FIG. 3. A processing unit may include one or more processors or central processing units, such as processor 202 or processor 204 of FIG. 2 or processor 302 of FIG. 3. The depicted examples in FIGS. 1-3 and above-described examples are not meant to imply architectural limitations. For example, data processing system 300 also may be a tablet computer, laptop computer, or telephone device in addition to taking the form of a PDA.
  • FIG. 4 is a visual diagram illustrating the operational flow of an automatic risk assessment system in accordance with exemplary aspects of the present invention. In step 1, a new patch is released by a vendor and patch notification 410 is received at managing server 420. A patch may be released, for example, to update functionality of an application, to fix bugs, or to update a device driver. The patch itself may replace files with newer files, modify attributes of a file, or delete files, for instance. The patch may be associated with a particular application, an operating system component, or a device driver, for example. Patch notification 410 may include the patch files and metadata describing the patch. Patch notification 410 may also include a list of touched files or, in other words, files affected by the patch.
  • In step 2, managing server 420 performs patch risk assessment. Managing server 420 checks the applicability of the patch based on the files affected by the patch, activity of the node being patched from metrics collected by application monitoring server 430, and other factors.
  • In step 3, managing server 420 applies the patch to managed endpoint 440. Based on the risk assessment from step 2, managing server 420 can apply the patch immediately, schedule deployment of the patch for a later time, or notify the administrator of a high risk so the administrator may take appropriate measures. Managing server 420 also communicates with policy engine 450, which identifies policies from policy storage 460 that apply to the patch being deployed. Managing server 420 then applies the identified policies when deploying the patch.
  • For example, managing server 420 may send patch information to policy engine 450 indicating that the patch updates an application associated with a service level agreement and is to be deployed in China. Policy engine 450 then identifies the policies that apply to patches that affect applications associated with a service level agreement and policies that apply to scheduling patch deployment in China. Managing server 420 may then apply those policies to the patch based on the risk assessment and schedule installation of the patch accordingly.
  • Turning to FIG. 5, a visual diagram is shown illustrating the operational flow of an automatic patch deployment system in accordance with exemplary aspects of the present invention. Automatic patch deployment system 520 is illustrated using a MAPE (monitor, analyze, plan, execute) loop diagram. The system begins by monitoring individual files and assigning weights, shown as 502. Files may be assigned higher lower weights based on how frequently, or recently, they are accessed, for example. In the depicted example, the file MSVC.DLL is assigned a weight of 20, the file Kernel.DLL is assigned a weight of 20, and the file XXX.DLL is assigned a weight of 5.
  • Monitor component 522 monitors activity on the endpoint on which the patch is to be installed. The endpoint is shown as element 536, although element 536 may represent an application, operating system component, device driver or any other element that is to be affected by the patch. In the depicted example, monitor component 522 collects usage metrics 504 to monitor activity, such as a percentage of usage of resources being used, for example, via sensors 532. For instance, sensors 532 may be an application monitor component of an application being patched and receive a metric indicating a percentage of memory being used by the application. A person of ordinary skill in the art will recognize that other types of monitoring and sensors may also be used within the scope of the present invention.
  • Analysis component 524 analyzes the patch based on weights 502, metrics 504, and policy 506 to assess the risk of the patch. Analysis component 524 may determine a percentage risk that the patch will result in a hang or reboot or will significantly degrade productivity of the endpoint. Policy 506 may, for example, define how the percentage risk is categorized into high risk, medium risk, or low risk. In the depicted example, policy 506 defines a 50% or greater risk as high risk, less than 50% and greater than or equal to 20% as medium risk, and less than 20% as low risk. High risk may indicate, for example, that the risk is likely to require a reboot, while low risk may indicate that the patch can be installed immediately without significantly affecting productivity of the managed endpoint.
  • Policy 506 may be specific to a particular patch, specific to a particular endpoint, or universal to all patches being deployed to all endpoints. For example, a policy for an end user client device may be more tolerant than a policy for a server providing critical services to customers under a service level agreement. As another example, a policy for a non-critical patch may allow a greater distribution within the medium risk category because productivity of the endpoint may be more important than the timeliness of the patch.
  • Planning component 526 determines how to install the patch based on the risk assessment from analysis component 524. More particularly, planning component 526 may make a determination of whether to install the patch and when to install the patch based on policy 508. In the depicted example, policy 508 indicates that installation of a patch with high risk shall be delayed, while a patch with medium risk shall be installed when the endpoint is idle and a patch with low risk may be installed immediately.
  • Once planning component 526 determines that a patch is to be installed, execution component 528 effectuates plan from planning component 526 to install the patch 510 via effectors 534. Effectors 534 apply the patch to element 536 by replacing files, updating files, modifying attributes, altering configurations, deleting files, and the like.
  • Monitor component 522, analysis component 524, planning component 526, and execution component 528 operate based on knowledge 530. Knowledge 530 is the engine that drives the MAPE loop. Knowledge 530 schedules and analyzes the monitoring data. Knowledge 530 executes based on the policies and applies policies based on the data.
  • FIG. 6 is a flowchart illustrating operation of an automatic patch deployment system in accordance with exemplary aspects of the present invention. Operation begins and the automatic patch deployment system receives a patch notification (block 602). Then, the automatic patch deployment system loads a policy for patch deployment (block 604) and monitors application activity (block 606). Next, the automatic patch deployment system analyzes the patch (block 608) and determines a level of risk for the patch (block 610). Thereafter, the automatic patch deployment system deploys the patch according to the policy (block 612) and operation ends.
  • FIG. 7 is a flowchart illustrating operation of automatic patch deployment system in accordance with an example policy in accordance with an exemplary embodiment of the present invention. More particularly, FIG. 7 illustrates deployment of a patch according to the policy shown as element 508 in FIG. 5. Operation begins and the automatic patch deployment system determines whether the patch risk is high, medium, or low (block 702). If the patch risk is high, the automatic patch deployment system delays the patch install (block 704) and notifies the administrator (block 706) of the delayed patch install. The administrator may then manually assess the situation and determine whether activity of the endpoint machine should be interrupted to deploy the patch.
  • If the patch risk is medium in block 702, the automatic patch deployment system determines whether the application is idle (block 708). If the application is not idle, the automatic patch deployment returns to block 708 to wait until the application is idle. If the application is idle in block 708, the automatic patch deployment system installs the patch (block 710) and operation ends.
  • If the patch risk is low in block 702, then the patch is not likely to interrupt activity of the endpoint machine, and the automatic patch deployment system proceeds directly to block 710 to install the patch and operation ends.
  • The example flow of operation shown in FIG. 7 is specific to one example policy. The deployment of a patch may be fully customized using a policy file, such as policy 508 shown in FIG. 5. That is, an administrator, when creating the policy, may determine that a patch with high risk may be installed when the application is idle. A policy may specify that when a patch having a medium risk is deployed, the patch may be installed immediately with a notification being sent to the administrator so the administrator may monitor completion of the patch. Thus, the policy may vary depending upon the endpoint device, the element being patched, whether there is a service level agreement, etc.
  • While the example policy is based on three discrete categories of risk, the policy may also be based on more or fewer categories of risk or even other representations of risk, such as percentage values, types of risk (reboot, hang, high memory consumption, low disk space, etc.), and the like.
  • Furthermore, FIG. 5 depicts separate components 502, 504, 506, 508, that specify policy information for assessing and deploying a patch; however, all of these components may be stored in a single policy file. The policy file may take the form of a table, text file, or other file type. In a more specific embodiment, the policy file may take the form of a markup language document, such as an extensible markup language (XML) document or the like.
  • Thus, the present invention solves the disadvantages of the prior art by providing an automatic patch deployment system that deploys the patch according to the assessed risk and a policy. The policy may specify actions to be taken to deploy the patch for different categories of risk. The automatic patch deployment system receives a patch notification, an assessment of the risk, and the policy and deploys the patch accordingly. For example, installation of a patch may be indefinitely delayed for high risk patches, rescheduled for medium risk patches, or installed immediately for low risk patches.
  • The invention can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment containing both hardware and software elements. In one preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
  • Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium may be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with an instruction execution system, apparatus, or device.
  • The medium may be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk—read only memory (CD-ROM), compact disk—read/write (CD-R/W) and digital video disk (DVD).
  • A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) may be coupled to the system either directly or through intervening I/O controllers.
  • Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
  • The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims (20)

1. A method for automatic patch deployment, the method comprising:
receiving a patch to be installed for a software component on an endpoint device;
receiving a risk assessment for the patch identifying a level of risk for installing the patch on the endpoint device;
retrieving a policy; and
deploying the patch according to the level of risk and the policy.
2. The method of claim 1, wherein the level of risk is one of high, medium, or low.
3. The method of claim 2, wherein deploying the patch includes delaying installation of the patch and notifying an administrator if the level of risk is high.
4. The method of claim 2, wherein deploying the patch includes installing the patch when the software component is idle if the level of risk is medium.
5. The method of claim 2, wherein deploying the patch includes installing the patch immediately if the level of risk is low.
6. The method of claim 1, wherein the policy is retrieved from a policy file.
7. The method of claim 6, wherein the policy file is an extensible markup language file.
8. An automatic patch deployment system comprising:
a managing server, wherein the managing server receives a patch to be installed for a software component on an endpoint device and receives a risk assessment for the patch identifying a level of risk for installing the patch on the endpoint device;
a policy engine that identifies one or more policies for the patch and sends the one or more policies to the managing server, wherein the managing server deploys the patch at the endpoint device according to the level of risk and the one or more policies.
9. The automatic patch deployment system of claim 8, wherein the level of risk is one of high, medium, or low.
10. The automatic patch deployment system of claim 9,
wherein deploying the patch includes delaying installation of the patch and notifying an administrator if the level of risk is high.
11. The automatic patch deployment system of claim 9, wherein deploying the patch includes installing the patch when the software component is idle if the level of risk is medium.
12. The automatic patch deployment system of claim 9, wherein deploying the patch includes installing the patch immediately if the level of risk is low.
13. The automatic patch deployment system of claim 8, wherein the policy is retrieved from a policy storage.
14. A computer program product comprising:
a computer usable medium having computer usable program code for automatic patch deployment, the computer program product including:
computer usable program code for receiving a patch to be installed for a software component on an endpoint device;
computer usable program code for receiving a risk assessment for the patch identifying a level of risk for installing the patch on the endpoint device;
computer usable program code for retrieving a policy; and
computer usable program code for deploying the patch according to the level of risk and the policy.
15. The computer program product of claim 14, wherein the level of risk is one of high, medium, or low.
16. The computer program product of claim 15, wherein the computer usable program code for deploying the patch includes computer usable program code for delaying installation of the patch and notifying an administrator if the level of risk is high.
17. The computer program product of claim 15, wherein the computer usable program code for deploying the patch includes computer usable program code for installing the patch when the software component is idle if the level of risk is medium.
18. The computer program product of claim 15, wherein the computer usable program code for deploying the patch includes computer usable program code for installing the patch immediately if the level of risk is low.
19. The computer program product of claim 14, wherein the policy is retrieved from a policy file.
20. The computer program product of claim 19, wherein the policy file is an extensible markup language file.
US11/195,023 2005-08-02 2005-08-02 Method, apparatus, and program product for autonomic patch deployment based on autonomic patch risk assessment and policies Abandoned US20070033635A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/195,023 US20070033635A1 (en) 2005-08-02 2005-08-02 Method, apparatus, and program product for autonomic patch deployment based on autonomic patch risk assessment and policies
US12/131,562 US8261353B2 (en) 2005-08-02 2008-06-02 Method, apparatus, and program product for autonomic patch deployment based on autonomic patch risk assessment and policies

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/195,023 US20070033635A1 (en) 2005-08-02 2005-08-02 Method, apparatus, and program product for autonomic patch deployment based on autonomic patch risk assessment and policies

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/131,562 Continuation US8261353B2 (en) 2005-08-02 2008-06-02 Method, apparatus, and program product for autonomic patch deployment based on autonomic patch risk assessment and policies

Publications (1)

Publication Number Publication Date
US20070033635A1 true US20070033635A1 (en) 2007-02-08

Family

ID=37719039

Family Applications (2)

Application Number Title Priority Date Filing Date
US11/195,023 Abandoned US20070033635A1 (en) 2005-08-02 2005-08-02 Method, apparatus, and program product for autonomic patch deployment based on autonomic patch risk assessment and policies
US12/131,562 Expired - Fee Related US8261353B2 (en) 2005-08-02 2008-06-02 Method, apparatus, and program product for autonomic patch deployment based on autonomic patch risk assessment and policies

Family Applications After (1)

Application Number Title Priority Date Filing Date
US12/131,562 Expired - Fee Related US8261353B2 (en) 2005-08-02 2008-06-02 Method, apparatus, and program product for autonomic patch deployment based on autonomic patch risk assessment and policies

Country Status (1)

Country Link
US (2) US20070033635A1 (en)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070033445A1 (en) * 2005-08-02 2007-02-08 Hirsave Praveen P K Method, apparatus, and program product for autonomic patch risk assessment
US20080005778A1 (en) * 2006-07-03 2008-01-03 Weifeng Chen System and method for privacy protection using identifiability risk assessment
US7516367B1 (en) 2008-05-30 2009-04-07 International Business Machines Corporation Automated, distributed problem determination and upgrade planning tool
US20090204946A1 (en) * 2008-02-12 2009-08-13 International Business Machines Corporation Intelligent software code updater
WO2009114823A1 (en) * 2008-03-14 2009-09-17 Terix Computer Service Operating system patch metadata service and process for recommending system patches
US20100235823A1 (en) * 2009-03-12 2010-09-16 International Business Machines Corporation Computer implemented api management mechanism for generating upgrade risk level handling
US7870547B2 (en) 2005-08-10 2011-01-11 Cisco Technology, Inc. Method and apparatus for managing patchable software systems
US20110022841A1 (en) * 2009-07-27 2011-01-27 Vonage Network Llc Authentication systems and methods using a packet telephony device
US20110022844A1 (en) * 2009-07-27 2011-01-27 Vonage Network Llc Authentication systems and methods using a packet telephony device
US20130179479A1 (en) * 2012-01-06 2013-07-11 International Business Machines Corporation Intelligent file management
US8677348B1 (en) * 2005-10-17 2014-03-18 Cisco Technology, Inc. Method and apparatus for determining least risk install order of software patches
US20150089488A1 (en) * 2013-09-26 2015-03-26 International Business Machines Corporation Analytics based patch management and distribution
US20150205965A1 (en) * 2014-01-22 2015-07-23 Lexisnexis, A Division Of Reed Elsevier Inc. Systems and methods for determining overall risk modification amounts
US10824413B2 (en) * 2018-07-23 2020-11-03 International Business Machines Corporation Maintenance of computing nodes concurrently in a number updated dynamically
US11556650B2 (en) * 2019-04-30 2023-01-17 International Business Machines Corporation Methods and systems for preventing utilization of problematic software

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9418040B2 (en) * 2005-07-07 2016-08-16 Sciencelogic, Inc. Dynamically deployable self configuring distributed network management system
US20070033635A1 (en) * 2005-08-02 2007-02-08 Hirsave Praveen P K Method, apparatus, and program product for autonomic patch deployment based on autonomic patch risk assessment and policies
US8417737B2 (en) 2010-10-20 2013-04-09 Microsoft Corporation Online database availability during upgrade
US8386501B2 (en) 2010-10-20 2013-02-26 Microsoft Corporation Dynamically splitting multi-tenant databases
US8799453B2 (en) 2010-10-20 2014-08-05 Microsoft Corporation Managing networks and machines for an online service
US20120102480A1 (en) * 2010-10-20 2012-04-26 Microsoft Corporation High availability of machines during patching
US8850550B2 (en) 2010-11-23 2014-09-30 Microsoft Corporation Using cached security tokens in an online service
US9721030B2 (en) 2010-12-09 2017-08-01 Microsoft Technology Licensing, Llc Codeless sharing of spreadsheet objects
US8972963B2 (en) * 2012-03-28 2015-03-03 International Business Machines Corporation End-to-end patch automation and integration
JP2014013457A (en) * 2012-07-03 2014-01-23 Fujitsu Ltd Patch determination program, patch determination method, and information processing device
US9705744B2 (en) 2013-07-05 2017-07-11 International Business Machines Corporation Updating hardware and software components of cloud computing environment at optimal times
US9348585B2 (en) 2013-08-20 2016-05-24 Red Hat, Inc. System and method for estimating impact of software updates
EP3063634A4 (en) * 2013-10-30 2017-06-28 Hewlett-Packard Enterprise Development LP Software commit risk level
US9450974B2 (en) * 2014-03-20 2016-09-20 International Business Machines Corporation Intrusion management
US9319430B2 (en) 2014-06-17 2016-04-19 International Business Machines Corporation Managing software deployment
US9645806B2 (en) * 2014-09-30 2017-05-09 International Business Machines Corporation Method to convey an application's development environment characteristics to the hosting provider to facilitate selection of hosting environment or the selection of an optimized production operation of the application
US9787709B2 (en) * 2015-06-17 2017-10-10 Bank Of America Corporation Detecting and analyzing operational risk in a network environment
US10148489B2 (en) 2015-09-01 2018-12-04 At&T Intellectual Property I, L.P. Service impact event analyzer for cloud SDN service assurance
WO2017099477A1 (en) * 2015-12-08 2017-06-15 삼성전자 주식회사 Method for operating mobile device having plurality of card modules installed therein and mobile device therefor
CN106855812A (en) 2015-12-08 2017-06-16 北京三星通信技术研究有限公司 The method and apparatus for configuring user terminal
US9696985B1 (en) 2016-01-06 2017-07-04 International Business Machines Corporation Patching of virtual machines within sequential time windows
US10374930B2 (en) 2016-01-28 2019-08-06 Microsoft Technology Licensing, Llc Off-peak patching for enterprise stability
US10341465B2 (en) * 2016-04-03 2019-07-02 Microsoft Technology Licensing, Llc Policy driven flight management
US10102376B2 (en) 2016-08-22 2018-10-16 International Business Machines Corporation Implementing locale management on PaaS: locale replacement risk analysis
US9910666B1 (en) 2016-08-22 2018-03-06 International Business Machines Corporation Implementing locale management on PaaS: live locale object update
US11023812B2 (en) 2017-08-28 2021-06-01 Bank Of America Corporation Event prediction and impact mitigation system
US10810006B2 (en) 2017-08-28 2020-10-20 Bank Of America Corporation Indicator regression and modeling for implementing system changes to improve control effectiveness
US10877443B2 (en) 2017-09-20 2020-12-29 Bank Of America Corporation System for generation and execution of improved control effectiveness
US10552140B2 (en) * 2018-01-31 2020-02-04 Oracle International Corporation Automated identification of deployment data for distributing discrete software deliverables
US11119751B2 (en) 2019-07-16 2021-09-14 International Business Machines Corporation Self-learning optimized patch orchestration
US11636212B2 (en) * 2020-01-15 2023-04-25 International Business Machines Corporation Predicting exploitability of software vulnerabilities and recommending alternate software packages
JP6915183B1 (en) * 2021-02-04 2021-08-04 株式会社システムサポート Security inspection system and security inspection method

Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6219805B1 (en) * 1998-09-15 2001-04-17 Nortel Networks Limited Method and system for dynamic risk assessment of software systems
US6327706B1 (en) * 1998-04-08 2001-12-04 Dell Usa, L.P. Method of installing software on and/or testing a computer system
US6347398B1 (en) * 1996-12-12 2002-02-12 Microsoft Corporation Automatic software downloading from a computer network
US6477703B1 (en) * 1999-06-29 2002-11-05 Hewlett-Packard Company Software patch selection tool
US20030009696A1 (en) * 2001-05-18 2003-01-09 Bunker V. Nelson Waldo Network security testing
US20030115511A1 (en) * 2001-12-13 2003-06-19 Nec Corporation Method, apparatus and program for diagnosing system risk
US20030212909A1 (en) * 2002-01-18 2003-11-13 Lucent Technologies Inc. Tool, method and apparatus for assessing network security
US20040139312A1 (en) * 2003-01-14 2004-07-15 General Instrument Corporation Categorization of host security levels based on functionality implemented inside secure hardware
US20050097547A1 (en) * 2003-10-30 2005-05-05 International Business Machines Corporation Autonomic auto-configuration using prior installation configuration relationships
US6912676B1 (en) * 1999-09-02 2005-06-28 International Business Machines Automated risk assessment tool for AIX-based computer systems
US20060080656A1 (en) * 2004-10-12 2006-04-13 Microsoft Corporation Methods and instructions for patch management
US7073172B2 (en) * 1998-09-21 2006-07-04 Microsoft Corporation On demand patching of applications via software implementation installer mechanism
US20060230042A1 (en) * 2005-03-30 2006-10-12 Butler Mark H Database security structure
US20070033445A1 (en) * 2005-08-02 2007-02-08 Hirsave Praveen P K Method, apparatus, and program product for autonomic patch risk assessment
US7278163B2 (en) * 2005-02-22 2007-10-02 Mcafee, Inc. Security risk analysis system and method
US7366892B2 (en) * 2003-01-28 2008-04-29 Cellport Systems, Inc. Secure telematics
US20080263534A1 (en) * 2005-08-02 2008-10-23 International Business Machines Corporation Method, apparatus, and program product for autonomic patch deployment based on autonomic patch risk assessment and policies

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7669180B2 (en) * 2004-06-18 2010-02-23 International Business Machines Corporation Method and apparatus for automated risk assessment in software projects
US20070033586A1 (en) * 2005-08-02 2007-02-08 International Business Machines Corporation Method for blocking the installation of a patch

Patent Citations (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6347398B1 (en) * 1996-12-12 2002-02-12 Microsoft Corporation Automatic software downloading from a computer network
US6327706B1 (en) * 1998-04-08 2001-12-04 Dell Usa, L.P. Method of installing software on and/or testing a computer system
US6219805B1 (en) * 1998-09-15 2001-04-17 Nortel Networks Limited Method and system for dynamic risk assessment of software systems
US7073172B2 (en) * 1998-09-21 2006-07-04 Microsoft Corporation On demand patching of applications via software implementation installer mechanism
US6477703B1 (en) * 1999-06-29 2002-11-05 Hewlett-Packard Company Software patch selection tool
US6912676B1 (en) * 1999-09-02 2005-06-28 International Business Machines Automated risk assessment tool for AIX-based computer systems
US20030009696A1 (en) * 2001-05-18 2003-01-09 Bunker V. Nelson Waldo Network security testing
US20030115511A1 (en) * 2001-12-13 2003-06-19 Nec Corporation Method, apparatus and program for diagnosing system risk
US20030212909A1 (en) * 2002-01-18 2003-11-13 Lucent Technologies Inc. Tool, method and apparatus for assessing network security
US20040139312A1 (en) * 2003-01-14 2004-07-15 General Instrument Corporation Categorization of host security levels based on functionality implemented inside secure hardware
US7366892B2 (en) * 2003-01-28 2008-04-29 Cellport Systems, Inc. Secure telematics
US20050097547A1 (en) * 2003-10-30 2005-05-05 International Business Machines Corporation Autonomic auto-configuration using prior installation configuration relationships
US20060080656A1 (en) * 2004-10-12 2006-04-13 Microsoft Corporation Methods and instructions for patch management
US7278163B2 (en) * 2005-02-22 2007-10-02 Mcafee, Inc. Security risk analysis system and method
US20060230042A1 (en) * 2005-03-30 2006-10-12 Butler Mark H Database security structure
US20070033445A1 (en) * 2005-08-02 2007-02-08 Hirsave Praveen P K Method, apparatus, and program product for autonomic patch risk assessment
US20080222626A1 (en) * 2005-08-02 2008-09-11 International Business Machines Corporation Method, Apparatus, and Program Product for Autonomic Patch Risk Assessment
US20080263534A1 (en) * 2005-08-02 2008-10-23 International Business Machines Corporation Method, apparatus, and program product for autonomic patch deployment based on autonomic patch risk assessment and policies

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080222626A1 (en) * 2005-08-02 2008-09-11 International Business Machines Corporation Method, Apparatus, and Program Product for Autonomic Patch Risk Assessment
US20070033445A1 (en) * 2005-08-02 2007-02-08 Hirsave Praveen P K Method, apparatus, and program product for autonomic patch risk assessment
US7870547B2 (en) 2005-08-10 2011-01-11 Cisco Technology, Inc. Method and apparatus for managing patchable software systems
US8677348B1 (en) * 2005-10-17 2014-03-18 Cisco Technology, Inc. Method and apparatus for determining least risk install order of software patches
US20080005778A1 (en) * 2006-07-03 2008-01-03 Weifeng Chen System and method for privacy protection using identifiability risk assessment
US8332959B2 (en) * 2006-07-03 2012-12-11 International Business Machines Corporation System and method for privacy protection using identifiability risk assessment
US20090228990A1 (en) * 2006-07-03 2009-09-10 Weifeng Chen System and method for privacy protection using identifiability risk assessment
US20090204946A1 (en) * 2008-02-12 2009-08-13 International Business Machines Corporation Intelligent software code updater
WO2009114823A1 (en) * 2008-03-14 2009-09-17 Terix Computer Service Operating system patch metadata service and process for recommending system patches
US20100017794A1 (en) * 2008-03-14 2010-01-21 Terix Computer Company, Inc. d/b/a Terix Computer Service Operating system patch metadata service and process for recommending system patches
US7516367B1 (en) 2008-05-30 2009-04-07 International Business Machines Corporation Automated, distributed problem determination and upgrade planning tool
US20100235823A1 (en) * 2009-03-12 2010-09-16 International Business Machines Corporation Computer implemented api management mechanism for generating upgrade risk level handling
US8423963B2 (en) * 2009-03-12 2013-04-16 International Buysiness Machines Corporation Computer implemented API management mechanism for generating upgrade risk level handling
US20110022841A1 (en) * 2009-07-27 2011-01-27 Vonage Network Llc Authentication systems and methods using a packet telephony device
US8635454B2 (en) 2009-07-27 2014-01-21 Vonage Network Llc Authentication systems and methods using a packet telephony device
US20110022844A1 (en) * 2009-07-27 2011-01-27 Vonage Network Llc Authentication systems and methods using a packet telephony device
US20130179479A1 (en) * 2012-01-06 2013-07-11 International Business Machines Corporation Intelligent file management
US9594762B2 (en) * 2012-01-06 2017-03-14 International Business Machines Corporation Intelligent file management
US20150089488A1 (en) * 2013-09-26 2015-03-26 International Business Machines Corporation Analytics based patch management and distribution
US9760362B2 (en) * 2013-09-26 2017-09-12 International Business Machines Corporation Analytics based patch management and distribution
US20150205965A1 (en) * 2014-01-22 2015-07-23 Lexisnexis, A Division Of Reed Elsevier Inc. Systems and methods for determining overall risk modification amounts
US10824413B2 (en) * 2018-07-23 2020-11-03 International Business Machines Corporation Maintenance of computing nodes concurrently in a number updated dynamically
US11556650B2 (en) * 2019-04-30 2023-01-17 International Business Machines Corporation Methods and systems for preventing utilization of problematic software

Also Published As

Publication number Publication date
US20080263534A1 (en) 2008-10-23
US8261353B2 (en) 2012-09-04

Similar Documents

Publication Publication Date Title
US8261353B2 (en) Method, apparatus, and program product for autonomic patch deployment based on autonomic patch risk assessment and policies
US20070033445A1 (en) Method, apparatus, and program product for autonomic patch risk assessment
US10735345B2 (en) Orchestrating computing resources between different computing environments
US7950007B2 (en) Method and apparatus for policy-based change management in a service delivery environment
US9264296B2 (en) Continuous upgrading of computers in a load balanced environment
US20210406079A1 (en) Persistent Non-Homogeneous Worker Pools
EP2008400B1 (en) Method, system and computer program for the centralized system management on endpoints of a distributed data processing system
US8566391B2 (en) System and method for evaluating application suitability in execution environment
US8108855B2 (en) Method and apparatus for deploying a set of virtual software resource templates to a set of nodes
US8635618B2 (en) Method and system to identify conflicts in scheduling data center changes to assets utilizing task type plugin with conflict detection logic corresponding to the change request
US7779402B2 (en) System and method for fine grain method update of an application to provide continuous availability
US20080196024A1 (en) Method and Apparatus for Changing Software Components in an Information Handling System
US9170806B2 (en) Software discovery by an installer controller
JP2007128521A (en) Method and apparatus for provisioning software on network of computer
US8627327B2 (en) Thread classification suspension
US7890952B2 (en) Autonomic peer-to-peer computer software installation
US8306995B2 (en) Inter-organizational and intra-organizational repository for operating system images
US8234644B2 (en) Selecting a system management product for performance of system management tasks
US11750451B2 (en) Batch manager for complex workflows
US8949423B2 (en) Autonomically co-locating first and second components on a select server
US20120072916A1 (en) Future system that can participate in systems management activities until an actual system is on-line
US20230097733A1 (en) Methods and systems to automatically deploy vulnerability fixes for software and firmware components
US8818945B2 (en) Targeted maintenance of computing devices in information technology infrastructure
US11743188B2 (en) Check-in monitoring for workflows

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HIRSAVE, PRAVEEN PRASANNA KUMAR;RAMACHANDRAN, PUTHUKODE G.;TROCHE, EDMUND;AND OTHERS;REEL/FRAME:016646/0367

Effective date: 20050801

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION