Unified patch management method compatible with multiple operating systems and related equipment

Abstract

The invention provides a unified patch management method compatible with multiple operating systems and related equipment. The method comprises the following steps: acquiring a plurality of first patches, and storing the plurality of first patches based on a preset unified data model to obtain a plurality of second patches; the plurality of first patches are used for updating various types of operating systems and / or application programs matched with the various types of operating systems; determining a deployment updating strategy of the plurality of second patches in the operating system matched with the plurality of second patches; and based on the deployment update strategy, deploying and updating the plurality of second patches to the corresponding plurality of device groups respectively. According to the method and the device, the patches of multiple types of operating systems can be managed, deployed and updated in a unified manner, the management complexity is greatly reduced, and the working efficiency is improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a unified patch management method and related equipment compatible with multiple operating systems. Background Technology

[0002] With the diversification of enterprise endpoint device ecosystems, the coexistence of multiple operating systems such as Windows, macOS, iOS, and iPadOS within enterprises has become the norm. At the same time, the increasing threat of hacker attacks and zero-day vulnerabilities poses a significant challenge to enterprise endpoint security management.

[0003] In related technologies, patch management is usually designed for a single operating system platform. Enterprise IT management teams often need to use multiple tools and execute multiple processes to manage patch updates for different platforms, which increases management complexity and cost. Moreover, traditional patch management tools usually adopt a one-time push method across the entire network, which makes it difficult to achieve refined risk control. Summary of the Invention

[0004] In view of this, the purpose of this disclosure is to propose a unified patch management method and related equipment that is compatible with multiple operating systems.

[0005] To achieve the above objectives, the first aspect of this disclosure provides a unified patch management method compatible with multiple operating systems, including:

[0006] Multiple first patches are obtained and stored based on a preset unified data model to obtain multiple second patches; the multiple first patches are used to update multiple types of operating systems and / or applications that match multiple types of operating systems.

[0007] Determine the deployment and update strategy for the plurality of second patches in the operating system that matches the plurality of second patches;

[0008] Based on the deployment and update strategy, the multiple second patches are deployed and updated to the corresponding multiple device groups respectively.

[0009] In some embodiments, the unified data model includes basic attribute information, version information, security attribute information, deployment attribute information, and operating system characteristic information.

[0010] In some embodiments, the method wherein

[0011] The basic attribute information includes at least one of the following: patch identifier, patch name, release date, release vendor, and a first operating system that matches the second patch; the first operating system is any one of the various types of operating systems.

[0012] The version information includes at least one of the following: version number, internal version number, and knowledge base number;

[0013] The security attribute information includes at least one of the following: a list of patched vulnerabilities, general vulnerability and disclosure code information, risk level score, and whether there are vulnerabilities that have been actually exploited by attackers.

[0014] The deployment attribute information includes at least one of the following: deployment status, number of installed devices, and installation success rate;

[0015] The operating system characteristic information includes patch attribute information for various types of operating systems.

[0016] In some embodiments, the method further includes:

[0017] Obtain the security attribute information of the plurality of second patches, and determine the risk assessment results of the plurality of second patches based on the security attribute information;

[0018] The step of determining the deployment update strategy for the plurality of second patches in the operating system that matches the plurality of second patches includes:

[0019] Based on the risk assessment results, the deployment and update strategy is determined.

[0020] In some embodiments, the security attribute information includes a risk level score, and the risk assessment result includes a risk level; determining the risk assessment result of the plurality of second patches based on the security attribute information includes:

[0021] The risk level of the plurality of second patches is determined based on the risk level score;

[0022] In response to the existence of a vulnerability in the third patch among the plurality of second patches that can be actually exploited by attackers, the risk level of the third patch is increased.

[0023] In some embodiments, determining the deployment update strategy based on the risk assessment results further includes:

[0024] Obtain the fourth patch from the plurality of second patches;

[0025] A first device group corresponding to the fourth patch is determined, wherein the first device group is the device group among the plurality of device groups that matches the operating system of the fourth patch;

[0026] The first equipment group is divided into multiple equipment subgroups;

[0027] Based on different delay times, the fourth patch is deployed and updated to the multiple device groups in sequence.

[0028] In some embodiments, dividing the first device group into multiple device groups includes at least one of the following:

[0029] According to the preset grouping ratio, devices are randomly selected from the first device group and assigned to the device group;

[0030] Based on the grouping request, the specified device is assigned to the device group.

[0031] In some embodiments, the method further includes at least one of the following:

[0032] Based on the risk assessment results of the fourth patch, the delay time between the device groups may be increased or decreased.

[0033] In response to a change request for a first device in the first device group, the device group to which the first device belongs is re-determined based on the change request;

[0034] Based on the deployment update status of the fourth patch in the preceding device group, the delay time of the fourth patch in the subsequent device group is modified.

[0035] In some embodiments, the deployment update strategy includes task deployment types; the method further includes:

[0036] The task deployment type of the plurality of second patches is determined based on at least one of the following: device type, device attribute, and work area where the device is located.

[0037] The task deployment types include automatic tasks and manual tasks; the automatic task is used to deploy and update the multiple second patches to the device group when the acquisition of the multiple second patches is detected, and the manual task is used to deploy and update the fifth patch among the multiple second patches to the device group based on a preset deployment time.

[0038] In some embodiments, the step of deploying and updating the plurality of second patches to corresponding plurality of device groups based on the deployment update strategy further includes:

[0039] Based on the interface that matches the type of the operating system, the multiple second patches are deployed to the corresponding multiple device groups respectively;

[0040] Based on preset device management policy parameters, the multiple second patches are updated to the multiple device groups;

[0041] The device management strategy parameters include at least one of the following: quality update, function update, forced installation deadline, installation time, and version-oriented update.

[0042] In some embodiments, the method further includes:

[0043] Obtain the installation status of the plurality of second patches in the device group;

[0044] The installation status of the multiple second patches in the device group is statistically analyzed and visualized.

[0045] In some embodiments, the method further includes:

[0046] For different types of operating systems, establish compliance standards for the deployment and update results of the multiple second patches;

[0047] Based on the aforementioned compliance standards, the deployment and update results of the multiple second patches are subjected to compliance checks to obtain compliance check results.

[0048] In some embodiments, the compliance check on the deployment and update results of the plurality of second patches based on the compliance standard to obtain the compliance check result includes:

[0049] The operating system version of the device group is compared with the operating system version in the compliance standard to determine the device compliance status;

[0050] Obtain vulnerability information for devices in the device group whose compliance status is unqualified;

[0051] Based on the device compliance status, determine the first compliance rate for devices with different types of operating systems;

[0052] Based on the device compliance status, determine the second compliance rate for all devices operating systems;

[0053] The compliance detection result is obtained based on at least one of the device compliance status, the device vulnerability information, the first compliance rate, and the second compliance rate.

[0054] The second aspect of this disclosure provides a unified patch management device compatible with multiple operating systems, comprising:

[0055] The acquisition module is configured to: acquire multiple first patches, and store the multiple first patches based on a preset unified data model; the multiple first patches are used to update various types of operating systems and / or applications that match the type of the operating system;

[0056] The strategy determination module is configured to: determine the deployment and update strategy of the multiple second patches in the operating system that matches the multiple second patches based on the patch information of the multiple second patches;

[0057] The deployment update module is configured to deploy and update the multiple second patches to the corresponding multiple device groups based on the deployment update strategy.

[0058] A third aspect of this disclosure provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements a unified patch management method compatible with multiple operating systems as described in the first aspect.

[0059] A fourth aspect of this disclosure provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the unified patch management method compatible with multiple operating systems described in the first aspect.

[0060] The fifth aspect of this disclosure provides a computer program product including computer program instructions that, when executed on a computer, cause the computer to perform a unified patch management method compatible with multiple operating systems as described in the first aspect.

[0061] As can be seen from the above, the unified patch management method and related equipment compatible with multiple operating systems provided in this disclosure store the first patch for multiple operating systems to obtain the second patch through a preset unified data model. This allows for the setting of a unified deployment and update strategy for each second patch, as well as the unified deployment and update of each second patch. This enables unified management and deployment of the first patch used to update multiple types of operating systems, significantly reducing management complexity and improving work efficiency. Attached Figure Description

[0062] To more clearly illustrate the technical solutions in this disclosure or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0063] Figure 1 A schematic diagram of an exemplary system provided by an embodiment of this disclosure is shown.

[0064] Figure 2 A flowchart illustrating an exemplary method provided by an embodiment of this disclosure is shown.

[0065] Figure 3 A schematic diagram of the framework of an exemplary system according to an embodiment of the present disclosure is shown.

[0066] Figure 4A schematic diagram of an exemplary apparatus provided by an embodiment of the present disclosure is shown.

[0067] Figure 5 A schematic diagram of the hardware structure of an exemplary computer device provided in an embodiment of this disclosure is shown. Detailed Implementation

[0068] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0069] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this disclosure should have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms "first," "second," and similar words used in the embodiments of this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0070] It is understood that before using the technical solutions of the various embodiments in this disclosure, users will be informed of the type, scope of use, and usage scenarios of the personal information involved in an appropriate manner, and user authorization will be obtained.

[0071] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose, based on the prompt message, whether to provide personal information to the software or hardware such as electronic devices, applications, servers, or storage media performing the operations of this disclosed technical solution.

[0072] As an optional but not limited implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0073] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0074] Figure 1 A schematic diagram of an exemplary system 100 provided in an embodiment of this disclosure is shown.

[0075] like Figure 1 As shown, system 100 can be used to implement patch management functions and may include terminal devices 102A and 102B, server 106, and database server 108. The terminal devices 102A and 102B may include a medium (e.g., a network) providing a communication link with server 106 and database server 108. This network may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0076] The terminal device 102A can have an operating system installed, such as Windows, macOS, iOS, iPadOS, Android, or other operating systems. It can also install various applications (APPs) or software, such as project management applications, collaborative office applications, image processing applications, video conferencing applications, reading applications, video applications, social networking applications, payment applications, web browsers, and instant messaging tools.

[0077] The terminal device 102B can be equipped with patch management software, which can be used to manage patches compatible with multiple operating systems in a unified manner.

[0078] The terminal devices 102A and 102B here can be either hardware or software. When terminal devices 102A and 102B are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, e-book readers, MP3 players, laptops, and desktop computers (PCs). When terminal devices 102A and 102B are software, they can be installed in the electronic devices listed above. They can be implemented as multiple software programs or software modules (e.g., to provide distributed services) or as a single software program or software module. No specific limitations are set here.

[0079] Server 106 can be a server providing various services, such as a backend server supporting various applications displayed on terminal device 102A, or a backend server supporting patch management software on terminal device 102B. Database server 108 can also be a database server providing various services. It is understood that if server 106 can implement the relevant functions of database server 108, database server 108 may not need to be configured in system 100.

[0080] The server 106 and database server 108 here can be either hardware or software. When they are hardware, they can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When they are software, they can be implemented as multiple software programs or software modules (e.g., used to provide distributed services), or as a single software program or software module. No specific limitations are made here.

[0081] It should be noted that the patch management method provided in this embodiment can be executed by server 106. It should be understood that... Figure 1 The number of terminal devices, users, servers, and database servers shown is merely illustrative. Depending on implementation needs, there can be any number of terminal devices, users, servers, and database servers.

[0082] As described in the background section, patch management in the prior art is typically designed for a single operating system platform. For example, Microsoft's Software Patch (Windows Server Update Services, WSUS) focuses on updates for the Windows operating system, while JamfPro primarily targets updates for Apple devices such as macOS, iOS, and iPadOS.

[0083] In this scenario, enterprise IT management teams typically need to use multiple tools and execute various processes to manage patch updates for different platforms. This not only increases management complexity and cost but also makes it difficult to establish a unified security baseline and compliance standards. Furthermore, traditional patch management tools have relatively simple patch deployment strategies, usually employing a one-time, network-wide push approach, which fails to effectively control potential risks caused by patch compatibility issues.

[0084] In view of this, embodiments of this disclosure provide a unified patch management method compatible with multiple operating systems to solve the above problems.

[0085] like Figure 2 As shown, the unified patch management method compatible with multiple operating systems includes:

[0086] Step S101: Obtain multiple first patches, store the multiple first patches based on a preset data model to obtain multiple second patches; the multiple first patches are used to update multiple types of operating systems and / or applications that match the multiple types of operating systems.

[0087] In this embodiment, multiple first patches can be obtained, which can be used to update the system software of various operating systems such as Windows, macOS, iOS, iPadOS, and Android to fix vulnerabilities in the system software of these operating systems and improve the security of the operating system.

[0088] In some embodiments, multiple first patches can also be used to update applications (APPs) that match various operating systems such as Windows, macOS, iOS, iPadOS, and Android. That is, the patch is used to update applications in the Windows, macOS, iOS, iPadOS, and Android ecosystems to fix vulnerabilities and improve the application's security. For example, a patch to update the Microsoft 365 office software on the Windows operating system; or client patches for the same application on different operating systems, etc. This embodiment does not limit this to any particular type.

[0089] In this embodiment, the first patch is obtained through multiple information channels. For example, the first patch for each operating system can be obtained based on a unified programming interface that matches the type of operating system.

[0090] In this embodiment, patch information of the first patch can also be obtained to standardize the first patch based on a unified data model, thereby obtaining the second patch.

[0091] The patch information may include, for example, patch metadata information, such as patch identifier, patch name and other basic patch information, release date, version identifier information, release vendor, and information on the vulnerabilities fixed. This embodiment does not limit this.

[0092] For example, the Windows Update API (Microsoft Graph API) can be used to obtain update information (Windows Update) or first patches for the Windows operating system and / or applications running on it, including quality updates and feature updates, and further, the revision information of the first patches. The Microsoft Graph API is a unified programming interface provided by Microsoft for accessing data and functionality in Microsoft 365, Azure Active Directory (Azure AD), and other Microsoft cloud services.

[0093] The Security Bulletin Interface (MSRC API) provides a way to programmatically access Microsoft security vulnerability information. Details of the latest Common Vulnerabilities and Exposures (CVEs) can be directly retrieved into Security Information and Event Management (SIEM) systems, GRC (Governance, Risk, and Compliance) platforms, or internal security dashboards. Simultaneously, scripts and IT management tools (such as SCCM, Intune, or third-party patching tools) can use this API to check for the latest patches relevant to their environment and trigger deployment workflows.

[0094] Obtain the first patch for updates to macOS, iOS, iPadOS, and / or applications running macOS, iOS, and iPadOS through the Apple Globally Distributed Malware Feed API (Apple GDMF API). The Apple GDMF API is a security-related interface provided by Apple, primarily used to provide enterprises and security vendors with malware threat intelligence data from the Apple ecosystem.

[0095] Vulnerability details, including Common Vulnerability Scoring System (CVSS) ratings and exploitation status, can be obtained from the vulnerability database via the NVD CVE API. The vulnerability database may refer to the National Vulnerability Database (NVD).

[0096] Obtain details of Common Vulnerabilities and Exposures (CVEs) related to macOS, iOS, iPadOS operating systems and / or applications in macOS, iOS, and iPadOS operating systems through the Sofafeed API.

[0097] Since the data structures of the data models for the first patches corresponding to various operating systems such as Windows, macOS, iOS, iPadOS, and Android are different, in order to achieve unified management of each first patch, each first patch is stored in the patch library according to a preset unified data model to obtain each second patch. This allows the stored second patches to adapt to the patch characteristics of different operating systems, realizes the standardized processing of patch information, and enables the first patches adapted to different operating system platforms to be uniformly stored, managed, and deployed.

[0098] In this embodiment, before storing each first patch according to a preset unified data model, the patch information of each first patch is subjected to standardization processing such as filtering and deduplication. After storing each first patch into the patch library according to the preset data model to obtain the second patch, an automatic data synchronization mechanism, data parsing logic, and exception handling mechanism can be established to ensure the real-time performance and integrity of each patch and its corresponding patch data in the patch library.

[0099] Step S103: Determine the deployment and update strategy of the plurality of second patches in the operating system that matches the plurality of second patches.

[0100] In this embodiment, after storing multiple first patches using a unified data model to obtain multiple second patches, the deployment and update strategies for each second patch can be set based on the same patch management system, so that each second patch can be deployed and updated to the corresponding operating system and / or applications that match the operating system.

[0101] Step S105: Based on the deployment update strategy, the multiple second patches are deployed and updated to the corresponding multiple device groups respectively.

[0102] In this embodiment, each second patch is deployed and updated to multiple corresponding device groups based on a deployment and update strategy. These multiple device groups can each correspond to different types of operating systems, completing the deployment and update operations of the second patch on devices running each operating system platform.

[0103] For example, if the second patch is a patch for updating the Windows operating system, then based on the deployment update policy, the second patch can be deployed to the device group with the Windows operating system installed.

[0104] If the second patch is for updating the macOS operating system, it can be deployed to the group of devices with macOS installed, based on the deployment update policy.

[0105] If the second patch is for updating the iOS operating system, it can be deployed to the group of devices that have the iOS operating system installed, based on the deployment update policy.

[0106] If the second patch is for updating the iPadOS operating system, it can be deployed to the group of devices that have iPadOS installed, based on the deployment update policy.

[0107] In this embodiment, a second patch is obtained by storing the first patch for multiple operating systems through a preset unified data model. This allows for the setting of a unified deployment and update strategy for each second patch, as well as the unified deployment and update of each second patch. This enables unified management and deployment of the first patch used to update multiple types of operating systems, significantly reducing management complexity and improving work efficiency.

[0108] In some embodiments, the unified data model includes basic attribute information, version information, security attribute information, deployment attribute information, and operating system characteristic information.

[0109] The basic attribute information includes basic attributes that all types of operating system patches have, including patch identifier (ID), patch name, release date, release vendor, and at least one of the first operating system that matches the second patch; the first operating system is any one of the multiple types of operating systems.

[0110] Version information includes version identification information for the second patch for each type of operating system, including at least one of the following: version number, build number, and knowledge base (KB) number. The KB number is a version identification information specific to the Windows operating system, a unique number assigned by Microsoft to each official support document, software update (patch), vulnerability fix, or driver it releases.

[0111] Security attribute information is used to represent the security-related attribute information of the second patch, including at least one of the following: a list of vulnerabilities that have been patched, Common Vulnerability and Exposure (CVE) coding information, Risk Level (CVSS) score, and whether there are vulnerabilities that have been actually exploited by attackers.

[0112] Deployment attribute information is used to represent the deployment-related attribute information of the second patch, including at least one of the deployment-related attribute information such as deployment status, number of installed devices, and installation success rate.

[0113] Operating system characteristic information is used to represent patch attribute information specific to each operating system, including patch attribute information for various types of operating systems, such as hot patch identifiers for Windows and SecurityInfo links for macOS.

[0114] In this embodiment, through this unified data model, the system can standardize the first patch from different channels to obtain the second patch, realize the unified management of the second patch across platforms, and at the same time retain the unique attributes of the first patch belonging to each operating system, ensuring the accuracy and completeness of patch management.

[0115] In this embodiment, because the second patch is obtained by standardizing the first patch using a unified data model, the first patches for each operating system can be managed through a unified patch management interface. This allows administrators to manage patches for multiple operating system devices, such as Windows, macOS, iOS, and iPadOS, from a single control plane, significantly reducing management complexity and improving work efficiency. It can reduce the enterprise's patch management workload by approximately 40%.

[0116] In some embodiments, the method further includes: obtaining security attribute information of the plurality of second patches, and determining the risk assessment result of the plurality of second patches based on the security attribute information.

[0117] In this embodiment, the security attribute information of each second patch can be obtained based on the second patch stored through a unified data model, and the risk assessment results of the multiple second patches can be determined based on the security attribute information.

[0118] In this embodiment, the security attribute information of each second patch can be obtained based on the unified data model of each second patch. Then, the risk assessment result of each second patch can be determined by combining the security attribute information of each second patch. Thus, the risk level of each second patch can be divided based on the security characteristics of each second patch, thereby reducing the decision-making burden of the administrator on the risk level of the patch and improving the security and efficiency of patch management.

[0119] The step S103 of determining the deployment and update strategy of the plurality of second patches in the operating system that matches the plurality of second patches includes: determining the deployment and update strategy based on the risk assessment results.

[0120] In this embodiment, after determining the risk assessment results of each second patch, the deployment and update strategy of the second patch can be determined based on the risk assessment results of each second patch, such as the risk level of each second patch, so as to realize an intelligent deployment and update strategy by combining the security features of the second patch.

[0121] In this embodiment, the risk assessment results of each second patch can be determined based on the security attribute information of the second patch, and then the deployment and update strategy of each second patch can be determined according to the risk assessment results of the second patch, so as to deploy and update the second patch according to the deployment and update strategy. This enables the intelligent deployment and update strategy to be realized by combining the security features of the second patch, thereby meeting the user's needs.

[0122] In some embodiments, the security attribute information includes a risk level score, and the risk assessment result includes a risk level. Step S103, which involves determining the risk assessment result of the plurality of second patches based on the security attribute information, includes:

[0123] Step S201: Determine the risk level of the plurality of second patches based on the risk level score.

[0124] In this embodiment, since the second patch is obtained by storing and managing each first patch based on a unified data model, the security attribute information of each second patch can be obtained based on the unified data model.

[0125] In some embodiments, the risk assessment result may be determined based on one or a combination of security attributes, such as the number of vulnerabilities patched, risk level score, and whether there are vulnerabilities that are actually exploited by attackers.

[0126] In some embodiments, the risk level of each second patch can be determined based on its risk level score. The risk level can be, for example, severe, high-risk, medium-risk, and low-risk. In this embodiment, the risk level score of the second patch can be mapped to the corresponding risk level. For example, a risk level score of 9.0-10.0 indicates a severe risk level, a risk level score of 7.0-8.9 indicates a high-risk risk level, a risk level score of 4.0-6.9 indicates a medium-risk risk level, and a risk level score of 0.1-3.9 indicates a low-risk risk level.

[0127] Step S203: In response to the fact that a third patch among the plurality of second patches has a vulnerability that can be actually exploited by an attacker, the risk level of the third patch is increased.

[0128] In this embodiment, the risk level of a patch can also be modified, for example, based on whether the patch contains a vulnerability that can be actually exploited by an attacker. For instance, if a third patch contains a vulnerability that can be actually exploited by an attacker, then the risk level of the third patch is increased.

[0129] In this embodiment, assuming that the risk level of the third patch is determined to be high based on the risk level score of the third patch; at the same time, if a vulnerability that can be actually exploited by an attacker is detected in the third patch, then the risk level of the third patch is changed from high risk to critical, and the third patch can be dealt with first.

[0130] In this embodiment, the second patches can be sorted according to their risk level, and high-risk second patches can be repaired first to ensure the security of the system.

[0131] In this embodiment, by conducting a risk assessment on the second patch, the decision-making burden of the patch administrator can be effectively reduced, and the security and efficiency of patch management can be improved.

[0132] In some embodiments, determining the deployment update strategy based on the risk assessment results further includes:

[0133] Step S301: Obtain the fourth patch from the plurality of second patches. The fourth patch can be any of the plurality of second patches.

[0134] Step S303: Determine the first device group corresponding to the fourth patch, wherein the first device group is the device group among the plurality of device groups that matches the operating system of the fourth patch.

[0135] In this embodiment, the target operating system of the fourth patch is determined by obtaining the matching first operating system from the basic attribute information of the fourth patch through a unified data model. Simultaneously, the first device group that is the same as the target operating system of the fourth patch is obtained based on the operating systems in each device group.

[0136] Step S305: Divide the first device group into multiple device groups.

[0137] Step S307: Based on different delay times, the fourth patch is deployed and updated sequentially to the multiple device groups of the first device group.

[0138] In this embodiment, a multi-ring deployment strategy can be implemented, that is, the first device group is divided into multiple device groups, each device group includes a different proportion of devices and a different latency time, and the patch deployment and update are implemented progressively according to the latency time of each device.

[0139] In some embodiments, the multiple device groups may include a test ring, a pilot ring, and a production ring.

[0140] The test ring can include approximately 5% of the devices with 0-day latency, used for rapid verification of patch compatibility; the pilot ring can include approximately 20% of the devices with 7-day latency, further expanding the testing scope; and the production ring can include approximately 75% of the devices with 14-day latency, targeting the majority of devices.

[0141] In this embodiment, the patch can be deployed and updated to 5% of the devices in the test ring first. Within 7 days after deployment, the patch deployment and update can be verified on the 5% of devices in the test ring to ensure compatibility and other issues. If problems are found, subsequent deployments can be paused, and problems can be identified and resolved in a timely manner to avoid significant losses caused by the patch update.

[0142] If no issues are found, the patch can be further deployed to 20% of the devices in the pilot ring to expand the scope of compatibility testing. If issues are found, subsequent deployments can be paused, and problems should be identified and resolved promptly to avoid undetected compatibility issues due to limited patch coverage, thus preventing significant losses.

[0143] If no issues are found, the patch can be deployed and updated to 75% of the production ring devices to complete the patch deployment and update.

[0144] In this embodiment, by progressively deploying and updating patches, compatibility issues can be identified in a timely manner, thus avoiding widespread losses.

[0145] In this embodiment, by conducting patch risk assessment and employing a multi-ring deployment strategy, high-risk patches can be quickly identified and prioritized. Simultaneously, progressive deployment controls risk and effectively shortens the vulnerability exposure window. For high-risk vulnerabilities, this embodiment can reduce patch deployment time by approximately 50%, significantly lowering security risks.

[0146] In some embodiments, dividing the first device group into multiple device groups in step S305 includes: randomly selecting devices from the first device group and assigning them to the device groups according to a preset grouping ratio.

[0147] In this embodiment, devices can be divided into groups by proportional sampling. That is, the patch management system can randomly select devices from each device in the first device group and assign them to each device group according to a preset grouping ratio, thus realizing the division of device groups.

[0148] In some embodiments, dividing the first device group into multiple device groups in step S305 includes: assigning a specified device to the device group based on a grouping request.

[0149] In this embodiment, equipment can be divided into groups by specifying specific equipment groups. This means assigning a particular equipment group to a specific equipment subgroup. For example, equipment that meets certain criteria such as equipment type, equipment attribute, and the work area where the equipment is located can be assigned to a specific equipment group, achieving precise control over equipment grouping.

[0150] In some embodiments, the method further includes: increasing or decreasing the latency time between the device groups based on the risk assessment results of the fourth patch.

[0151] In this embodiment, the latency between different device groups can be modified based on the risk assessment results of the fourth patch. For example, if the risk level of the fourth patch is high, the latency between the three device groups—the test ring, pilot ring, and production ring—will be reduced to improve the security of each operating system device.

[0152] In some embodiments, the method further includes: in response to a change request for a first device in the first device group, re-determining the device group to which the first device belongs based on the change request.

[0153] In this embodiment, if the equipment in each equipment group changes, the changed equipment is regrouped so that it can be assigned to a suitable group. For example, assuming that each equipment group is divided based on the work area where the equipment is located, when the work area of ​​the first equipment in a certain equipment group changes, the patch management system redetermines the group to which the first equipment belongs based on the work area where the first equipment is located after the change.

[0154] In some embodiments, the method further includes: modifying the delay time of the patch in subsequent device groups based on the deployment update status of the fourth patch in the preceding device group.

[0155] In this embodiment, the delay time of the fourth patch in subsequent device groups can be adjusted according to the deployment and update status of the fourth patch in the preceding device group.

[0156] In some embodiments, the deployment update strategy includes task deployment type. That is, in this embodiment, the deployment update strategy of the patch can be set according to the preset task deployment type so as to deploy and update the patch based on different task deployment types.

[0157] In some embodiments, the method further includes: determining the task deployment type of the plurality of second patches based on at least one of the device type, device attributes, and work area where the device is located in the device group.

[0158] The device type is used to identify the type of device, such as server equipment, network equipment, storage equipment, personal office equipment, testing equipment, and conference equipment.

[0159] Device attributes are used to identify the attribute information of a device, including desktop computers, laptops, mobile phones, large screens, etc.

[0160] The work area where the equipment is located is used to identify the equipment's location, which may include the floor, office, area, department, and local area network.

[0161] The task deployment types include automatic tasks and manual tasks.

[0162] The automatic task is used to deploy and update the multiple second patches to the device group upon detecting their availability. That is, when the latest patches released by each operating system vendor are detected, the patch management system obtains these multiple second patches and updates them to the device group, thereby continuously ensuring that the operating system is in the latest security state.

[0163] The manual task is used to deploy and update the fifth patch among the multiple second patches to the device group based on a preset deployment time. That is, when the latest patch released by each operating system vendor is detected, the patch management system will update the fifth patch to the device group according to the pre-set deployment and update strategy, thereby achieving precise control over the patch update content and timing.

[0164] In some embodiments, the fifth patch can be updated to the device group according to a preset deployment time, for example, a scheduled task can be set to perform the patch update at 3:00 AM.

[0165] In some embodiments, the deployment time of the fifth patch can also be controlled. The fifth patch can be one or more specified patches, or a patch that meets preset conditions, such as meeting a preset risk level or preset version information, and the fifth patch is updated to the device group according to a preset deployment time.

[0166] In some embodiments, step S107, which involves deploying and updating the plurality of second patches to the corresponding plurality of device groups based on the deployment update strategy, further includes:

[0167] Step S401: Based on the interface matching the type of the operating system, deploy multiple second patches to the corresponding multiple device groups respectively.

[0168] In this embodiment, the interface compatible with the Windows operating system includes the Policy Distribution Interface (Windows MDMAPI), which converts the second patch into a device-executable configuration for the device group. The Windows MDM API is a programming interface that allows applications (typically the Mobile Device Management Service) to interact with the management framework of the Mobile Device Management Service (MDM) in the Windows operating system, thereby enabling remote management and control of devices.

[0169] The interface compatible with macOS, iOS, and iPadOS operating systems includes the Declarative Management Interface (Apple DDMAPI), which enables patch deployment on devices running macOS, iOS, or iPadOS. Specifically, the Apple DDMAPI allows the patch management system server to issue a patch deployment declaration. Upon receiving this declaration, the device begins installing the application. After successful installation, the device proactively sends a status report to the server to indicate that the patch has been installed, allowing the patch management system to monitor the patch installation status in real time.

[0170] Step S403: Based on preset device management policy parameters, update the plurality of second patches to the plurality of device groups. The device management policy parameters include at least one of quality update, feature update, forced installation deadline, installation time, and version-oriented update.

[0171] In this embodiment, for the Windows operating system, the preset device management policy parameters may include quality updates, feature updates, forced installation deadlines, and installation time.

[0172] Among them, quality updates include the quality update delay period (DeferQualityUpdatesPeriodInDays), which is used to postpone quality update patches for a specified number of days.

[0173] Feature updates include a feature update delay period (DeferFeatureUpdatesPeriodInDays), which is the number of days after a feature update patch is obtained before receiving and installing it.

[0174] The forced installation deadline includes the forced automatic execution date (ConfigureDeadlineForQualityUpdates), which sets a final absolute deadline for delayed quality updates.

[0175] Installation time is used to enable the device to install patches outside of active times, or to enable the device to install patches at a specified time.

[0176] For macOS, iOS, and iPadOS operating systems, the default device management policy parameters may include forced installation deadlines, version-oriented updates, and pre-release version control policies.

[0177] The forced installation deadline includes TargetLocalDateTime, which specifies a future date and time based on the device's local time zone, allowing the device to automatically update at that time.

[0178] Version-targeted updates include TargetOSVersion and TargetBuildVersion. TargetOSVersion specifies an operating system version number and instructs the device to install or update to that version. TargetBuildVersion is used to specify a very precise operating system build version number and instructs the device to update or downgrade to that version.

[0179] The pre-release version (Beta) control policy is used to support the control of pre-release versions (Beta).

[0180] In this embodiment, during the deployment and update of multiple second patches, different technical paths are adopted to achieve unified management based on the differences in characteristics of various operating systems, ensuring the consistency of the management interface and the effectiveness of deployment execution.

[0181] In this embodiment, through flexible deployment time control and environment-specific deployment strategies, patch deployment can be completed with minimal business interruption. Especially for unmanned equipment such as conference rooms, the system can complete upgrades outside of working hours, reducing the impact on business operations.

[0182] In some embodiments, the method further includes:

[0183] Step S501: Obtain the installation status of the plurality of second patches in the device group.

[0184] In some embodiments, a client can be installed on each device in the device group to collect the installation status of multiple second patches on each device.

[0185] For devices running Windows, the installation status of each second patch can be identified by analyzing the device's build number and default fields. For Windows, the installation status of each second patch can include: installed, not started, awaiting installation, installing, installation failed, and installation aborted. The default field can be wu_history.

[0186] For devices running macOS, iOS, or iPadOS, the installation status of each second patch can be identified by analyzing the device's operating system version, build number, and Declarative Device Management Report (DDM Report). Specifically, for macOS, iOS, and iPadOS, the installation status of each second patch can include: installed, downloading, awaiting installation, installing, and installation failed.

[0187] In this embodiment, the installation status of each second patch on each device in the device group can be obtained periodically, that is, each device periodically uploads the installation status of each second patch to the patch management system. Alternatively, the patch management system can actively send status acquisition requests to each device to actively obtain the installation status of each second patch on each device. This embodiment does not limit this approach.

[0188] Step S503: Perform statistical analysis and visualization on the installation status of the multiple second patches in the device group.

[0189] In this embodiment, the installation status of multiple second patches in each device of the device group can be statistically analyzed, and the deployment and installation progress of multiple second patches and the distribution of the installation status of multiple second patches can be intuitively displayed based on visualization methods such as pie charts and progress bars.

[0190] In this embodiment, consistent management of patch status for devices on different operating systems is achieved through a unified status definition and display method, which greatly improves management efficiency.

[0191] In some embodiments, the method further includes:

[0192] Step S601: For different types of operating systems, set compliance standards for the deployment and update results of the multiple second patches.

[0193] In this embodiment, different compliance standards for the deployment and update results of patches can be set for different types of operating systems.

[0194] For Windows operating systems, both quality update compliance standards and feature update compliance standards can be set simultaneously. If both quality update compliance standards and feature update compliance standards are met, the patch deployment will meet the compliance standards.

[0195] For macOS, iOS, and iPadOS operating systems, compliance standards can be set according to major versions, allowing for the configuration of different compliance requirements for each version.

[0196] Step S603: Perform compliance testing on the deployment and update results of the multiple second patches based on the compliance standards to obtain compliance testing results.

[0197] In this embodiment, after setting compliance standards, compliance checks can be performed based on the deployment and update results of each second patch to determine whether the deployment and update results of each second patch meet the preset compliance standards.

[0198] In some embodiments, the compliance check performed on the deployment and update results of the plurality of second patches based on the compliance standard in step S603 to obtain the compliance check result includes:

[0199] Step S6031: Compare the operating system version of the device group with the operating system version compliance standard in the compliance standard to determine the device compliance status.

[0200] In this embodiment, the device's compliance status can be determined by comparing the device's operating system version with the operating system version in the compliance standard, and the device's compliance status can be used as the compliance test result.

[0201] Step S6033: Obtain vulnerability information of devices in the device group whose compliance status is not up to standard.

[0202] In this embodiment, for non-compliant devices, i.e. devices whose compliance status is not compliant, the number of unpatched vulnerabilities in the device can be calculated to obtain device vulnerability information, and the device vulnerability information can be used as a compliance detection result to assist in risk assessment.

[0203] Step S6035: Based on the device compliance status, determine the compliance rate for devices with different types of operating systems.

[0204] In this embodiment, based on the device compliance status of each device, a first compliance rate for each operating system can be calculated separately, and this first compliance rate can be used as the compliance detection result to provide intuitive compliance status display information.

[0205] Step S6037: Based on the device compliance status, determine the compliance rate of all operating system devices.

[0206] In this embodiment, based on the device compliance status of each device, the overall compliance rate can be calculated, that is, a second compliance rate can be calculated without distinguishing the operating system, and this second compliance rate can be used as the compliance detection result to provide intuitive compliance status display information.

[0207] Step S6039: Obtain the compliance detection result based on at least one of the device compliance status, the device vulnerability information, the first compliance rate, and the second compliance rate.

[0208] In this embodiment, unified patch compliance management enables the establishment of a cross-platform patch compliance baseline, achieving compliance assessment and reporting for all terminal devices and meeting security audit requirements. Simultaneously, it can automatically identify non-compliant devices and generate remediation suggestions, effectively improving the overall compliance level.

[0209] In this embodiment, patches can be automatically acquired, risk assessed, and deployed, significantly reducing the need for manual intervention. This allows the device to be kept in the latest security state without frequent manual operations, reducing the enterprise's patch management operation and maintenance costs by approximately 35%.

[0210] In this embodiment, key information such as patch risk ratings, deployment progress, and compliance status are displayed intuitively and visually, providing support for management decisions. Administrators can quickly understand the overall security situation and formulate more scientific patch management strategies.

[0211] Figure 3 An architecture diagram of a patch management system is shown. (For example...) Figure 3 As shown, the patch management system includes an external data source layer, a data collection and processing layer, a core function module layer, and a device interface layer.

[0212] The external data source layer has interfaces that match various operating systems such as Windows, macOS, iOS, iPadOS, and Android. These include the Windows update interface Microsoft Graph API, the security bulletin interface MSRC API, the Apple update interface Apple GDMF API, the vulnerability database interface NVD CVE API, and the general vulnerability and disclosure interface Sofafeed API. Patches that match various operating systems such as Windows, macOS, iOS, iPadOS, and Android can be obtained through these interfaces.

[0213] The data acquisition and processing layer includes a data standardization engine, a unified patch data model, a risk scoring engine, and an intelligent scheduling algorithm module.

[0214] Specifically, a data standardization engine parses multi-source data obtained from external data sources to obtain individual first patches. A unified patch data model then stores these first patches in a patch repository to generate second patches, thus achieving standardized processing of patch information across platforms. A risk scoring engine obtains the security attribute information of the second patches, such as risk level scores and whether any vulnerabilities have been exploited by attackers. An intelligent scheduling algorithm module implements a multi-ring deployment strategy for patches.

[0215] The core functional modules include a patch repository management module, a risk assessment module, a patch strategy engine, a deployment scheduling center, a status monitoring system, and a compliance management platform.

[0216] The system comprises several modules: a patch repository management module for managing all second patches in the repository, including version tracking; a risk assessment module for evaluating security attributes obtained from a risk scoring engine; a patch policy engine for determining deployment and update strategies for the second patches based on the risk assessment results; a status monitoring system for tracking and statistically analyzing the installation status of the second patches on various devices; and a compliance management platform for conducting compliance checks on the deployment and update results of the patches according to preset compliance standards.

[0217] The device interface layer includes the policy distribution interface Windows MDM API, the declarative management interface Apple DDMAPI, the device state collector, and the policy distribution engine.

[0218] Among them, the policy delivery interface Windows MDM API is an interface that matches the Windows operating system. Through the policy delivery interface Windows MDM API, patches that match the Windows operating system are deployed and installed on devices with the Windows operating system.

[0219] The Apple DDM API is a declarative management interface compatible with macOS, iOS, and iPadOS operating systems. It allows you to deploy and install patches compatible with macOS, iOS, and iPadOS onto devices running these operating systems.

[0220] The device status collector is used to collect the installation status of patches on each device and upload the installation status of the second patch on each device to the status monitoring system.

[0221] The policy distribution engine is used to distribute the deployment and installation policies of each patch to the device group.

[0222] It should be noted that the method of this disclosure embodiment can be executed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method of this disclosure embodiment, and the multiple devices will interact with each other to complete the method described.

[0223] It should be noted that the above description describes some embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0224] Based on the same inventive concept, corresponding to any of the above embodiments, this disclosure also provides a unified patch management device compatible with multiple operating systems.

[0225] refer to Figure 4 The device includes:

[0226] The acquisition module 11 is configured to: acquire multiple first patches, and store the multiple first patches based on a preset unified data model; the multiple first patches are used to update various types of operating systems and / or applications that match the type of the operating system;

[0227] The strategy determination module 13 is configured to: determine, based on the patch information of the plurality of second patches, the deployment and update strategy of the plurality of second patches in the operating system that matches the plurality of second patches.

[0228] The deployment update module 15 is configured to deploy and update the multiple second patches to the corresponding multiple device groups based on the deployment update strategy.

[0229] In some embodiments, the unified data model includes basic attribute information, version information, security attribute information, deployment attribute information, and operating system characteristic information.

[0230] In some embodiments, the method wherein

[0231] The basic attribute information includes at least one of the following: patch identifier, patch name, release date, release vendor, and the first operating system corresponding to the second patch; the first operating system is any one of the various types of operating systems.

[0232] The version information includes at least one of the following: version number, internal version number, and knowledge base number;

[0233] The security attribute information includes at least one of the following: a list of patched vulnerabilities, general vulnerability and disclosure code information, risk level score, and whether there are vulnerabilities that have been actually exploited by attackers.

[0234] The deployment attribute information includes at least one of the following: deployment status, number of installed devices, and installation success rate;

[0235] The operating system characteristic information includes patch attribute information for various types of operating systems.

[0236] In some embodiments, the device is further configured to:

[0237] Obtain the security attribute information of the plurality of second patches, and determine the risk assessment results of the plurality of second patches based on the security attribute information;

[0238] The strategy determination module 13 is further configured to:

[0239] Based on the risk assessment results, the deployment and update strategy is determined.

[0240] In some embodiments, the security attribute information includes a risk level score, and the risk assessment result includes a risk level; the risk assessment module 13 is further configured to:

[0241] The risk level of the plurality of second patches is determined based on the risk level score;

[0242] In response to the existence of a vulnerability in the third patch among the plurality of second patches that can be actually exploited by attackers, the risk level of the third patch is increased.

[0243] In some embodiments, the strategy determination module 15 is further configured to:

[0244] Obtain the fourth patch from the plurality of second patches;

[0245] A first device group corresponding to the fourth patch is determined, wherein the first device group is the device group among the plurality of device groups that matches the operating system of the fourth patch;

[0246] The first equipment group is divided into multiple equipment subgroups;

[0247] Based on different delay times, the fourth patch is deployed and updated to the multiple device groups in sequence.

[0248] In some embodiments, dividing the first device group into multiple device groups includes at least one of the following:

[0249] According to the preset grouping ratio, devices are randomly selected from the first device group and assigned to the device group;

[0250] Based on the grouping request, the specified device is assigned to the device group.

[0251] In some embodiments, the apparatus is further configured to perform at least one of the following:

[0252] Based on the risk assessment results of the fourth patch, the delay time between the device groups may be increased or decreased.

[0253] In response to a change request for a first device in the first device group, the device group to which the first device belongs is re-determined based on the change request;

[0254] Based on the deployment update status of the fourth patch in the preceding device group, the delay time of the fourth patch in the subsequent device group is modified.

[0255] In some embodiments, the deployment update strategy includes a task deployment type; the strategy determination module 15 is further configured to:

[0256] The task deployment type of the plurality of second patches is determined based on at least one of the following: device type, device attribute, and work area where the device is located.

[0257] The task deployment types include automatic tasks and manual tasks; the automatic task is used to deploy and update the multiple second patches to the device group when the acquisition of the multiple second patches is detected, and the manual task is used to deploy and update the fifth patch among the multiple second patches to the device group based on a preset deployment time.

[0258] In some embodiments, the deployment update module 17 is further configured to:

[0259] Based on the interface that matches the type of the operating system, the multiple second patches are deployed to the corresponding multiple device groups respectively;

[0260] Based on preset device management policy parameters, the multiple second patches are updated to the multiple device groups;

[0261] The device management strategy parameters include at least one of the following: quality update, function update, forced installation deadline, installation time, and version-oriented update.

[0262] In some embodiments, the device is further configured to:

[0263] Obtain the installation status of the plurality of second patches in the device group;

[0264] The installation status of the multiple second patches in the device group is statistically analyzed and visualized.

[0265] In some embodiments, the device is further configured to:

[0266] For different types of operating systems, establish compliance standards for the deployment and update results of the multiple second patches;

[0267] Based on the aforementioned compliance standards, the deployment and update results of the multiple second patches are subjected to compliance checks to obtain compliance check results.

[0268] In some embodiments, the compliance check on the deployment and update results of the plurality of second patches based on the compliance standard to obtain the compliance check result includes:

[0269] The operating system version of the device group is compared with the operating system version in the compliance standard to determine the device compliance status;

[0270] Obtain vulnerability information for devices in the device group whose compliance status is unqualified;

[0271] Based on the device compliance status, determine the first compliance rate for devices with different types of operating systems;

[0272] Based on the device compliance status, determine the second compliance rate for all devices operating systems;

[0273] The compliance detection result is obtained based on at least one of the device compliance status, the device vulnerability information, the first compliance rate, and the second compliance rate.

[0274] For ease of description, the above apparatus is described in terms of its functions, divided into various modules. Of course, in implementing this disclosure, the functions of each module can be implemented in one or more software and / or hardware.

[0275] The apparatus described above is used to implement the corresponding unified patch management method compatible with multiple operating systems in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0276] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this disclosure also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the unified patch management method compatible with multiple operating systems described in any of the above embodiments.

[0277] Figure 5 This embodiment illustrates a more specific hardware structure of an electronic device, which may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0278] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0279] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0280] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0281] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0282] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0283] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0284] The electronic devices described above are used to implement the corresponding unified patch management method compatible with multiple operating systems in any of the foregoing embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0285] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this disclosure also provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the unified patch management method compatible with multiple operating systems as described in any of the above embodiments.

[0286] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0287] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the unified patch management method compatible with multiple operating systems as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0288] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this disclosure also provides a computer program product, which includes a computer program. In some embodiments, the computer program is executable by one or more processors to cause the processors to perform the unified patch management method compatible with multiple operating systems. Corresponding to the execution entity for each step in each embodiment of the method, the processor executing the corresponding step may belong to the corresponding execution entity.

[0289] The computer program product of the above embodiments is used to cause the processor to execute the unified patch management method compatible with multiple operating systems as described in any of the above embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0290] Those skilled in the art will recognize that embodiments of this disclosure can be implemented as a system, method, or computer program product. Therefore, this disclosure can be implemented as entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, this disclosure can also be implemented as a computer program product contained in one or more computer-readable media, which includes computer-readable program code.

[0291] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example,, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (not exhaustive) of a computer-readable storage medium may include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0292] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0293] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0294] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0295] It should be understood that each block of a flowchart and / or block diagram, as well as combinations of blocks in a flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine that, when executed by a computer or other programmable data processing device, creates means for implementing the functions / operations specified in the blocks of the flowchart and / or block diagram.

[0296] These computer program instructions may also be stored in a computer-readable medium that enables a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce a product comprising an instruction apparatus that implements the functions / operations specified in the boxes of a flowchart and / or block diagram.

[0297] Computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, such that the instructions that execute on the computer or other programmable apparatus can provide a process for implementing the functions / operations specified in the boxes of a flowchart and / or block diagram.

[0298] Furthermore, although the operations of the methods of this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. Rather, the steps depicted in the flowcharts may be executed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0299] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0300] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0301] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this disclosure (including the claims) is limited to these examples; within the framework of this disclosure, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this disclosure as described above, which are not provided in detail for the sake of brevity.

[0302] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this disclosure, the provided drawings may or may not show well-known power / ground connections to integrated circuit (IC) chips and other components. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this disclosure, and this also takes into account the fact that the details of implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this disclosure will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuitry) have been set forth to describe exemplary embodiments of this disclosure, it will be apparent to those skilled in the art that the embodiments of this disclosure may be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0303] Although this disclosure has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0304] This disclosure is intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A unified patch management method compatible with multiple operating systems, comprising: Multiple first patches are obtained, and the multiple first patches are stored based on a preset unified data model to obtain multiple second patches; The multiple first patches are used to update multiple types of operating systems and / or applications that are compatible with the multiple types of said operating systems; Determine the deployment and update strategy for the plurality of second patches in the operating system that matches the plurality of second patches; Based on the deployment and update strategy, the multiple second patches are deployed and updated to the corresponding multiple device groups respectively.

2. The method according to claim 1, wherein, The unified data model includes basic attribute information, version information, security attribute information, deployment attribute information, and operating system characteristic information.

3. The method according to claim 2, wherein, The basic attribute information includes at least one of the following: patch identifier, patch name, release date, release vendor, and a first operating system that matches the second patch; the first operating system is any one of the various types of operating systems. The version information includes at least one of the following: version number, internal version number, and knowledge base number; The security attribute information includes at least one of the following: a list of patched vulnerabilities, general vulnerability and disclosure code information, risk level score, and whether there are vulnerabilities that have been actually exploited by attackers. The deployment attribute information includes at least one of the following: deployment status, number of installed devices, and installation success rate; The operating system characteristic information includes patch attribute information for various types of operating systems.

4. The method according to claim 1, further comprising: Obtain the security attribute information of the plurality of second patches, and determine the risk assessment results of the plurality of second patches based on the security attribute information; The step of determining the deployment update strategy for the plurality of second patches in the operating system that matches the plurality of second patches includes: Based on the risk assessment results, the deployment and update strategy is determined.

5. The method according to claim 4, wherein, The security attribute information includes a risk level score, and the risk assessment result includes a risk level; determining the risk assessment result of the plurality of second patches based on the security attribute information includes: The risk level of the plurality of second patches is determined based on the risk level score; In response to the existence of a vulnerability in the third patch among the plurality of second patches that can be actually exploited by attackers, the risk level of the third patch is increased.

6. The method according to claim 4, wherein, Based on the risk assessment results, the deployment update strategy further includes: Obtain the fourth patch from the plurality of second patches; A first device group corresponding to the fourth patch is determined, wherein the first device group is the device group among the plurality of device groups that matches the operating system of the fourth patch; The first equipment group is divided into multiple equipment subgroups; Based on different delay times, the fourth patch is deployed and updated to the multiple device groups in sequence.

7. The method according to claim 6, wherein, The division of the first device group into multiple device groups includes at least one of the following: According to the preset grouping ratio, devices are randomly selected from the first device group and assigned to the device group; Based on the grouping request, the specified device is assigned to the device group.

8. The method of claim 6, further comprising at least one of the following: Based on the risk assessment results of the fourth patch, the delay time between the device groups may be increased or decreased. In response to a change request for a first device in the first device group, the device group to which the first device belongs is re-determined based on the change request; Based on the deployment update status of the fourth patch in the preceding device group, the delay time of the fourth patch in the subsequent device group is modified.

9. The method according to claim 1, wherein, The deployment update strategy includes task deployment types; the method further includes: The task deployment type of the plurality of second patches is determined based on at least one of the following: device type, device attribute, and work area where the device is located. The task deployment types include automatic tasks and manual tasks; the automatic task is used to deploy and update the multiple second patches to the device group when the acquisition of the multiple second patches is detected, and the manual task is used to deploy and update the fifth patch among the multiple second patches to the device group based on a preset deployment time.

10. The method according to claim 1, wherein, The step of deploying and updating the multiple second patches to the corresponding multiple device groups based on the deployment update strategy also includes: Based on the interface matching the type of the operating system, the multiple second patches are deployed to the corresponding multiple device groups respectively; Based on preset device management policy parameters, the multiple second patches are updated to the multiple device groups; The device management strategy parameters include at least one of the following: quality update, function update, forced installation deadline, installation time, and version-oriented update.

11. The method according to claim 1, further comprising: Obtain the installation status of the plurality of second patches in the device group; The installation status of the multiple second patches in the device group is statistically analyzed and visualized.

12. The method according to claim 1, further comprising: For different types of operating systems, establish compliance standards for the deployment and update results of the multiple second patches; Based on the aforementioned compliance standards, the deployment and update results of the multiple second patches are subjected to compliance checks to obtain compliance check results.

13. The method according to claim 12, wherein, The compliance check is performed on the deployment and update results of the multiple second patches based on the compliance standards to obtain the compliance check results, including: The operating system version of the device group is compared with the operating system version in the compliance standard to determine the device compliance status; Obtain vulnerability information for devices in the device group whose compliance status is unqualified; Based on the device compliance status, determine the first compliance rate for devices with different types of operating systems; Based on the device compliance status, determine the second compliance rate for all devices operating systems; The compliance detection result is obtained based on at least one of the device compliance status, the device vulnerability information, the first compliance rate, and the second compliance rate.

14. A unified patch management device compatible with multiple operating systems, comprising: The acquisition module is configured to: acquire multiple first patches and store the multiple first patches based on a preset unified data model; The multiple first patches are used to update various types of operating systems and / or applications that match the type of the operating system; The strategy determination module is configured to: determine the deployment and update strategy of the multiple second patches in the operating system that matches the multiple second patches based on the patch information of the multiple second patches; The deployment update module is configured to deploy and update the multiple second patches to the corresponding multiple device groups based on the deployment update strategy.

15. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the unified patch management method compatible with multiple operating systems as described in any one of claims 1 to 13.

16. A non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the unified patch management method compatible with multiple operating systems as described in any one of claims 1 to 13.

17. A computer program product, characterized in that, It includes computer program instructions that, when executed on a computer, cause the computer to perform the unified patch management method compatible with multiple operating systems as described in any one of claims 1 to 13.

Images