A hybrid approach to system compliance based on hot and cold patches

Abstract

Compliance actions are developed using an assessment that considers both cold and hot patches, including identifying policies that define compliance conditions based on the patching status of software components. Determining the patching status of software components includes identifying evidence of cold patch binaries(s) and hot patch binaries(s) applicable to the software component, and using this evidence to determine whether the hot patch binaries(s) have been applied to the memory image in which instances of the software component are loaded. Compliance actions are then developed based on policies and the patching status of software components to address the compliance conditions. These actions include generating health reports or health certificates, initiating patching actions, initiating enforcement control actions, and so on.

Description

Background Technology

[0001] Computer software is complex and difficult to write. Therefore, discovering vulnerabilities (including security flaws, crashes, and other unintended behaviors) in delivered software applications is almost inevitable. When a bug is discovered, the developers promise to generate a fix or "patch" and provide these software patches to users. Furthermore, developers may occasionally introduce new features or other improvements through software patches. Therefore, developers, administrators, and security professionals frequently modify existing systems to implement new or improved operations by installing software patches.

[0002] Traditionally, software patching is done through "cold patching." In some instances of cold patching, the original binary image (e.g., version 1.0 binary) is modified on disk with new code / replacement code containing one or more software patches, resulting in a cold patch binary (e.g., version 1.1 binary). In other implementations, the original binary image is replaced on disk by the cold patch binary. Regardless of whether the original binary is modified or replaced, any software component operating from the original binary will be restarted using the new code / replacement code in the cold patch binary. If these software components include low-level operating system (OS) components, such as the OS kernel, restarting the software component typically requires a reboot of the OS. Regardless of whether an OS reboot is required, a software component reboot will result in system downtime and / or service interruption.

[0003] Recently, techniques for patching software using "hot patching" have been developed. Some hot patching instances directly modify the in-memory image of a software component by adding new / replacing code that includes one or more patches. In these instances, the code of the hot patch binary is applied in memory to the already loaded executable binary (e.g., one previously loaded from the original binary or a cold patch binary). Therefore, these implementations can apply patches to software components without requiring a reboot. Other hot patching instances patch the binary during the loader phase so that newly launched software components include one or more hot patches. In these implementations, when a software component is launched from the original binary or a cold patch binary, the OS loader uses the code from the hot patch binary to "fix" either the original or cold patch binary. Summary of the Invention

[0004] When systems support both cold and hot patching, they can exist in various patching states, including executing software components loaded from various combinations of cold and hot patch binaries. Therefore, these systems can be in different security, compliance, and operational states. At least some of the embodiments described herein relate to assessing and implementing system compliance based on a mixture of cold and hot patches available and / or active at the computer system. For example, embodiments may include determining compliance conditions for one or more software components based on one or more policies, determining the health status of these additional software components based at least on which cold and hot patches are applied to operational instances of these software components, and formulating one or more compliance actions for the compliance conditions, such as generating health reports and / or health certificates for these software components, initiating patching actions for these software components, initiating execution control actions for these components, etc.

[0005] The embodiments relate to methods, systems, and computer program products for developing compliance actions using assessments that consider a mix of cold and hot patches. These embodiments include identifying one or more system policies defining one or more compliance conditions based on the patching status of a software component, including identifying a specific system policy defining a specific compliance condition for a specific software component. These embodiments also include determining the patching status of a specific software component. Determining the patching status includes identifying multiple pieces of evidence, each corresponding to multiple binaries that have been applied to the specific software component, including (i) one or more cold patch binaries from which the specific software component can be loaded, and (ii) one or more hot patch binaries applicable to the specific software component. Determining the patching status also includes determining, based on the multiple pieces of evidence, whether at least a subset of the one or more hot patch binaries has been applied to a memory image in system memory at a computer system, into which an instance of the specific software component has been loaded. These embodiments also include developing compliance actions for a specific compliance condition based on a specific system policy and based on the determined patching status of the specific software component. Compliance actions include at least one of the following: generating at least one of a health report or health certificate based on the patching status of a specific software component; initiating a patching action on the specific software component; or initiating an execution control action on the specific software component.

[0006] This summary portion is provided to present selected concepts in a simplified form, which will be further described in the detailed description below. This summary portion is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope used to define the claimed subject matter. Attached Figure Description

[0007] To describe how the above and other advantages and features of the invention can be obtained, the invention, which has been briefly described above, will be described in more detail with reference to specific embodiments of the invention shown in the accompanying drawings. It is understood that these drawings depict only exemplary embodiments of the invention and are therefore not intended to limit its scope. The invention will be described and explained with additional specificity and detail using the drawings, wherein:

[0008] Figure 1A An example computer architecture is shown that facilitates the assessment and enforcement of system compliance based on a hybrid approach of hot and cold patches;

[0009] Figure 1B An example computer architecture is shown that facilitates the assessment and enforcement of system compliance based on a hybrid of hot and cold patching, where memory is divided into (multiple) OS memory regions and (multiple) protected memory regions.

[0010] Figure 1C It shows Figure 1A and Figure 1B Further details of the example audit service shown; and

[0011] Figure 2 A flowchart is shown as an example method for developing compliance actions using an assessment that takes into account a mix of cold and hot patches. Detailed Implementation

[0012] The embodiments described herein are designed to assess and enforce system compliance based on a mix of cold and hot patches available and / or active on a computer system. For example, embodiments may include using one or more strategies to determine compliance conditions for one or more software components, determining the health status of these additional software components based at least on which cold and hot patches are applied to operational instances of these software components, and formulating one or more compliance actions in response to the compliance conditions, such as generating health reports and / or health certificates for these software components, initiating patching actions for these software components, initiating enforcement control actions for these software components, etc.

[0013] Figure 1A and Figure 1BExample computer architectures 100a / 100b are illustrated, which facilitate the assessment and implementation of system compliance based on a hybrid approach of hot and cold patching. As shown, each computer architecture 100a / 100b includes a corresponding computer system 101a / 101b. Each computer system 101a / 101b further includes computer hardware, such as one or more processors (not shown), system memory 102, and storage 103 (e.g., persistent storage, such as magnetic drives, solid-state drives, etc.). System memory 102 stores runtime binary images of OS services 106 and OS kernel 112 of operating system (OS) 105, as well as binary images (or multiple binary images of multiple applications) of applications 104 executing in the context of OS 105.

[0014] exist Figure 1A In computer system 100a, system memory 102 is shown as comprising a single memory partition, while Figure 1B In computer system 101b, system memory 102 is shown divided into at least one OS memory region and at least one protected memory region. In an embodiment, computer system 101b implements virtualization technology, such as a hypervisor, which enforces these memory partitions within computer system 101a. In computer system 101b, the protected memory region is managed by a security kernel 119 and includes services such as the depicted audit service 108 and hot patching engine 110 (which are part of OS service 106 in computer system 101a). Those skilled in the art will understand that placing audit service 108 and hot patching engine 110 within the protected memory region isolates these services from application 104 and OS 105, helping to protect them from tampering by application 104 or OS 105. Audit service 108 and / or hot patching engine 110 include sub-components within each of the OS memory region and the protected memory region.

[0015] Regardless of whether system memory 102 is partitioned, the various software components shown within system memory 102 execute based on one or more cold-patched binaries 114 stored in storage 103 (in this example, these may include the original unpatched binaries). In an embodiment, one or more of these software components also execute based on one or more hot-patched binaries 115, which are applied in memory to a memory image loaded from the cold-patched binaries 114. In one example, during the initialization of a software component, the hot-patching engine 110 instructs the loader 113 to "fix" one or more cold-patched binaries 114 with the code from one or more hot-patched binaries 115, thereby generating a memory binary image of the software component including one or more hot patches. In another example, after the software component initialization, the hot-patching engine 110 modifies an existing memory binary image using the code from one or more hot-patched binaries 115, thereby generating a memory binary image of the software component including one or more hot patches.

[0016] In an embodiment, computer systems 101a / 101b include a local update service 107 and communicate with a remote update service 116 (or multiple remote update services). In an embodiment, the local update service 107 communicates with the remote update service 116 (e.g., via one or more networks) to receive a cold patch binary 114 and / or a hot patch binary 115 and initiate the application of the hot patch binary 115 (e.g., via a hot patch engine 110).

[0017] As shown in the figure, the hot patching engine 110 (and potentially the loader 113) maintains a patch log 111, which is shown as patch log 111a in system memory 102 and / or patch log 111b in storage 103. Although in various embodiments, patch log 111 may store a large amount of information, in some embodiments, for one or more executing software components (e.g., application 104, OS service 106, OS kernel 112, etc.), patch log 111 records at least each time a hot patch is applied to a cold patch and / or each time a hot patch is applied to another hot patch. Therefore, patch log 111 can be used to verify the cold patches and / or hot patch chains executed from each of the one or more executing software components. In embodiments, one or more of the cold patch binary 114 and / or hot patch binary 115 are associated with corresponding digital signatures. In these embodiments, these digital signatures are checked by the local update service 107 and / or the hot patching engine 110, and these checks are recorded in patch log 111. In embodiments, patch log 111 is protected by one or more tamper-proof techniques (e.g., encryption, memory partitioning, digital signatures, keys or hashes stored in a secure cryptographic processor, etc.). In some embodiments, patch log 111 is stored at a remote location, such as a file share; alternatively or additionally, patch log 111 may be implemented as part of a distributed patch log database capable of tracking multiple computer systems. Those skilled in the art will understand that the information stored in patch log 111 forms an “audit trail” of installed patches.

[0018] In some embodiments, loader 113 loads a hot patch from hot patch binary 115, and hot patch engine 110 applies the hot patch to one or more memory images in system memory 102. Hot patch engine 110 records the hot patch application in patch log 111.

[0019] In some embodiments, loader 113 loads a hot patch from hot patch binary 115, and hot patch engine 110 verifies the digital signature of the hot patch. If the signature is valid, hot patch engine 110 applies the hot patch to one or more memory images within system memory 102. Hot patch engine 110 records the hot patch application and signature in patch log 111. In some cases, new hot patch binary 115s will become available, and these new hot patch binary 115s will overlap or replace existing hot patch binary 115s. In some embodiments, assuming the new hot patch binary 115 is verified, loader 113 and hot patch engine 110 will unload the existing hot patch binary and load the new hot patch binary 115. In some embodiments, loader 113 and hot patch engine 110 will load the new hot patch binary 115 after the existing hot patch binary 115. In some cases, computer system 101a / 101b restarts, and multiple hot patch binary 115s are available for the same component. In some embodiments, loader 113 and hot patching engine 110 ensure that the loading of cold patch binary 114 and hot patch binary 115 is itself tamper-proof. In some embodiments, loader 113 and hot patching engine 110 ensure that the loading of cold patch binary 114 and hot patch binary 115 includes logging non-optional patch logs to patch log 111. In some embodiments, loader 113 and hot patching engine 110 ensure that hot patches are loaded sequentially (e.g., build date, receive time, signing date, etc.) and that the order in which hot patches are applied is recorded in patch log 11. In some embodiments, loader 113 and / or hot patching engine 110 will check policy 109 and load instances of hot patch binary 115 according to the policy. In some embodiments, computer systems 101a / 101b may not have cold patches, or cold patches may not be allowed for certain time windows or environmental factors based on policies. This may be a result of availability requirements, bandwidth constraints (hot patch binary files are much smaller than cold patch binary files), or other factors.

[0020] Audit service 108 analyzes computer systems 101a / 101b to determine whether computer systems 101a / 101b meet one or more compliance conditions within policy 109, which is shown to exist in system memory 102 as policy 109a and / or in storage 103 as policy 109b, and potentially enforces one or more unmet compliance conditions. In embodiments, compliance means that computer systems 101a / 101b operate on a given set of software patches according to the conditions defined in policy 109. In some embodiments, compliance also means that application 104 and / or OS 105 are in a given configuration according to the conditions defined in policy 109. In some embodiments, policies 109 are received from remote update service 116, although they may be obtained from one or more other sources, they may also be user-defined, etc. In some embodiments, policies 109 are implicitly received or encoded in patches. This can be implemented as metadata associated with a single patch, metadata associated with a set of patches, encoded data within a patch, encoded data distributed across a set of patches, etc. In some embodiments, policies 109 and patch logs 111 are implemented as the same component.

[0021] In some embodiments, audit service 108 examines cold patch binary file 114 and / or hot patch binary file 115 in conjunction with patch log 111 to determine at least one compliance status of computer system 101b / 101b. In some embodiments, audit service 108 further analyzes system memory 102 to consider whether one or more hot patch binary files 115 are actually loaded into system memory 102. Examples of analysis of system memory 102 include calling certain application programming interfaces (APIs) or providing appropriate input to components of various possible patches to distinguish between compliance and non-compliance and / or identify whether a hot patch has been applied. In some embodiments, audit service 108 also considers other system configuration information, such as file systems, the registry, and other storage artifacts. In some embodiments, audit service 108 also considers additional information, such as local security settings, firewall settings, and other risk factors (e.g., user profiles, location, application reputation, etc.). Using this information, audit service 108 determines the health status of one or more components of computer system 101b / 101b. Then, the audit service 108 performs one or more compliance actions, such as generating health reports and / or health certificates, initiating patching actions (e.g., applying cold patches and / or cold patches, downloading and queuing available updates, etc.), or initiating enforcement control actions (e.g., terminating an instance of a software component, allowing the startup of a new instance of a software component and / or dependent components, sandboxing a software component, etc.).

[0022] For example, in one embodiment, a software patch addressing a given vulnerability (e.g., identified in a remote vulnerability database 118) may be available as one or both a cold patch and a hot patch. In some embodiments, if both a cold patch and a hot patch resolve the vulnerability, and each of the cold patch and hot patch resolves the vulnerability in the same way, the audit service 108 may determine whether one of the cold patch or hot patch is applied to a running software component and formulate one or more compliance actions based on that determination. In other embodiments, where a vulnerability is resolved by both cold and hot patches, the cold patch and hot patch resolve the vulnerability in different ways. For example, it may be impractical for hot and cold patches to achieve the same level of security due to technical limitations. Therefore, for example, a hot patch may provide mitigation, while a cold patch provides a fix. For example, if a network packet type can be used to attack the system, a hot patch may resolve the vulnerability by dropping packets of that type, while a cold patch may resolve the vulnerability by additional packet processing to ensure that packets of that type are not allowed to carry out attacks. In these embodiments, the audit service 108 may determine different compliance statuses based on whether a mitigating hot patch or cold patch with a fix has been applied. Audit service 108 can determine which of the mitigation hot patches or cold patches with fixes is applied to a running software component, and formulate one or more compliance actions based on these determinations.

[0023] Therefore, in this embodiment, audit service 108 ensures that an appropriate combination of cold patch binary 114 and hot patch binary 115 is installed and applied to running software components to provide runtime security compliance guarantees, and if runtime security compliance guarantees cannot be met, audit service 108 may impose restrictions on the software components. In some embodiments, audit service 108 requires that some hot patches be applied before other software components are loaded at computer system 100a / 100b. In some embodiments, using analysis of cold patch binary 114, audit service 108 also requires that these hot patches remain applied throughout the lifecycle of the software components, even during system restarts or service interruptions, thereby providing "reset / reboot" security compliance guarantees.

[0024] To illustrate how audit service 108 accomplishes the above tasks Figure 1C It shows Figure 1A and Figure 1B Other details regarding China Audit Services 108. Figure 1CThe audit service 108 described herein includes various components (i.e., policy identification component 120, patch status determination component 121, and compliance enforcement component 122), which represent various functionalities that the audit service 108 may implement according to the various embodiments described herein. It is understood that the described components, including their identities, subcomponents, and arrangements, are presented merely to aid in describing the various embodiments of the audit service 108 described herein, and these components do not limit how software and / or hardware implement the audit service 108 described herein, or any specific functionality thereof.

[0025] Typically, policy identification component 120 accesses policies 109 from storage 103 and / or from external sources (e.g., remote update service 116). From these policies 109, policy identification component 120 identifies one or more compliance conditions based on the patching status of one or more software components executed at computer systems 101a / 101b. In some embodiments, policy identification component 120 also identifies one or more vulnerabilities from a remote vulnerability database 118. In these embodiments, the identified vulnerabilities are used as further input to the conditions within policy 109.

[0026] Generally, the patch status determination component 121 considers cold patch status and hot patch status to determine the patching status of at least one software component. In an embodiment, the patch status determination component 121 determines cold patch binaries 114 and hot patch binaries 115 existing in storage 103, and which of these hot patch binaries 115 have been applied to one or more running instances of the software component. In an embodiment, the patch status determination component 121 analyzes which hot patch binaries 115 have been applied to one or more running instances of the software component based on querying the patch log 111 and / or by directly analyzing those instances in system memory 102.

[0027] Generally, based on the analysis of the patch status determination component 121, the compliance enforcement component 122 formulates one or more compliance actions for the compliance conditions identified by the policy identification component 120. In an embodiment, compliance actions may include: generating a health report and / or health certificate, initiating a patching action, initiating an execution control action, etc.

[0028] Now combine Figure 2 Further description of these components that provide audit services 108 Figure 2 A flowchart is shown for an example method 200 for developing compliance actions using an assessment that considers both cold and hot patches. Method 200 will be described with reference to other components and data from computer architectures 100a / 100b.

[0029] Method 200 includes action 201 of identifying compliance conditions from policies. In embodiments, action 201 includes identifying one or more system policies that define one or more compliance conditions based on the patch status of software components, including identifying specific system policies that define specific compliance conditions for specific software components. In a presenting example, policy identification component 120 loads one or more policies from policy 109. These policies 109 provide compliance conditions for software components (e.g., application 104, OS service 106, OS kernel 112, etc.) executing at computer systems 101a / 101b. For the purposes of this presenting example, it is assumed that policy 109 determines at least one compliance condition for application 104.

[0030] In one policy example, policy 109 defines a set of conditions such that if a given set of hot patches is available (either within hot patch binaries 115 or from a remote update service 116) to address a vulnerability (e.g., identified in a remote vulnerability database 118), these hot patches must be applied to computer systems 101a / 101b to maintain compliance (if non-compliance occurs, the software component can be terminated). In some embodiments, policy 109 also defines a condition that cold patch binaries 114 are updated (e.g., via a local update service 107) to address the vulnerability (at which point the hot patches will no longer be applicable to those cold patch binaries). In embodiments, hot patches are not applicable to cold patch binaries because the cold patch binaries already include patches provided by the hot patches, or the cold patch binaries include conflicting patches (e.g., patches in the cold patch binaries conflict with mitigation patches in the hot patches). In some embodiments, policy 109 defines conditions based on reliability. In one example reliability policy, if both hot and cold patch updates are available, and if applying a hot patch update fails, the policy applies the cold patch (and vice versa).

[0031] In another policy example, policy 109 defines a set of conditions such that a software component operating in an operating environment is considered compliant only if the operating environment is in a known compliant state. In an embodiment, the operating environment is considered to be in a known compliant state if it meets certain security boot requirements and / or if an appropriate digitally signed audit trail exists in patch log 111. In some embodiments, policy 109 requires “rebaseline” the operating environment before the software component is considered compliant if a time threshold has passed and / or if a threshold number of hot patches have been applied to the operating environment. In an embodiment, the operating environment is rebaselined by installing cold patches, analyzing audit trails, etc.

[0032] In another policy example, policy 109 defines a set of conditions that guide whether the system can maintain compliance based on whether a security goal or an availability goal exists. In one embodiment, for security purposes, policy 109 instructs that if a cold patch is more secure than a hot patch, the cold patch must be installed to maintain compliance (even if this means service interruption or even a system restart). In another embodiment, for availability purposes, policy 109 instructs that if a hot patch is available, it should be prioritized over a cold patch (applied only during a later baseline re-establishment / reboot). In yet another embodiment, to balance security and availability, policy 109 instructs that hot patches that implement mitigation should be prioritized over cold patches that implement fixes.

[0033] In another policy example, policy 109 defines a set of conditions based on attributes of computer systems 101a / 101b that guide whether the system can maintain compliance. In embodiments, this includes one or more of location, user information, the presence of peripheral devices, application information, or other attributes. For example, some locations may have limited bandwidth and / or other environmental factors that restrict the download and application of one or more cold patches. In another example, for a given component, multiple hot patch binaries 115 may exist. Based on policy 109 and the attributes of computer systems 101a / 101b, loader 113 and hot patch engine 110 will load one (or a set of) hot patch binaries 115, while other hot patch binaries 115 may be loaded before (e.g., in a specific order) or not. In embodiments, policy 109 defines a set of conditions based on one or more of health attributes or functionality attributes. For example, one or more policies 109 may define a set of hot patches required for the system to be certified as healthy, while one or more policies 109 may define the hot patches required for the system to be verified as having the desired functionality. In some embodiments, one or more of policies 109 may even define a set of hot patches for removing functionality. For example, if there is a software component that provides functionality with a vulnerability that is unpatched or unpatched, policy 109 may require the application to remove a hot patch for that functionality from the software component (thereby removing the vulnerability).

[0034] In another policy example, policy 109 defines a set of conditions that take into account workloads with various software components and / or dependencies. For example, due to their different workloads, policy 109 may allow virtual machines with uptime priorities (e.g., running client services) to remain compliant with hot patches while virtual machines with security priorities (e.g., running server workloads) would require cold patches to maintain compliance. In another example, policy 109 may allow software components with a threshold number of dependencies to remain compliant with hot patches while software components with a smaller number of dependencies would require cold patches to maintain compliance. In yet another example, policy 109 may allow software components without redundancy to remain compliant with hot patches while software components with redundancy (e.g., through a cluster) would require cold patches to maintain compliance.

[0035] In another policy example, policy 109 defines a set of conditions that indicate that a set of hot patches for implementing mitigation is sufficient to maintain compliance, but cold patches for implementing fixes should be downloaded in a timely manner and queued for the next opportunity to install (e.g., during scheduled maintenance).

[0036] In another policy example, policy 109 defines a set of conditions that consider the Service Level Agreement (SLA) associated with a software component. For example, policy 109 could allow hot patching for software components associated with a more stringent SLA, but require cold patching for software components associated with a less stringent SLA. For instance, the condition could specify that a set of hot patches is sufficient to meet a given compliance state if and only if the SLA exceeds “three nines” (99.9% availability), or it could specify that a set of cold patches is required to meet a given compliance state if the SLA is below 95%. Note that in some embodiments, if it is determined that a hot patch or cold patch exceeds the SLA, new hot patch binaries and cold patch binaries may not be installed until a user or administrator takes action. In some embodiments, if a hot patch exceeds the SLA, the hot patch is uninstalled to improve reliability. In some embodiments, if a cold patch exceeds the SLA, a rollback process can be initiated, where the appropriate cold patch binary 114 is uninstalled, after which the processes(s) running the cold patch can be restarted.

[0037] In another policy example, policy 109 defines a set of conditions that define when mitigating hot patches is no longer sufficient. This set of conditions could indicate that cold patches need to be fixed to maintain compliance, or it could indicate that an updated policy must be downloaded (e.g., extending the set of conditions to a later date) to determine the compliance status based on hot patches. For example, the conditions could specify that a set of hot patches is sufficient for a minimum number of hours before a predetermined date or time, or, if applicable, that the compliance status must have a shorter validity period.

[0038] In another policy example, policy 109 defines a set of one or more conditions that define the order in which two or more hot patches must be applied. As an example, if patch log 111 indicates that two or more hot patches must be applied in a specific order, the conditions may specify that computer system 101a / 101b or the software components executing therein can satisfy health conditions that are provable.

[0039] As described above, in this embodiment, policy 109 is implicitly received or encoded in the patch. Therefore, in this embodiment, at least one of one or more system policies is received or encoded within the patch file.

[0040] Method 200 further includes action 202 of determining the software patching status from cold patches and hot patches. In an embodiment, action 201 includes determining the patching status of a particular software component. In an embodiment, determining the patching status includes identifying multiple pieces of evidence, each corresponding to a binary file among multiple binary files that has been applied to the particular software component, the multiple binary files including (i) one or more cold patch binary files from which the particular software component can be loaded, and (ii) one or more hot patch binary files applicable to the particular software component. In an embodiment, each of the multiple pieces of evidence can be used to determine whether the multiple binary files have been applied to the particular software component. For example, the evidence may include a storage or disk copy of the patch file, a cryptographic hash of patch log 111, etc. Continuing with the foregoing example, in one scenario, patch status determining component 121 determines one or more cold patches in cold patch binary file 114 that can be applied to application 104, and one or more hot patches in hot patch binary file 115 that can be applied to application 104.

[0041] In some embodiments, one or more of the cold patch binary 114 and / or hot patch binary 115 are associated with a digital signature. Therefore, in some embodiments of action 202, each of the one or more cold patch binary files and the one or more hot patch binary files is associated with a corresponding digital signature. In these embodiments, the patch status determination component 121 can determine the validity of these signatures, for example, by checking these signatures against a digital certificate.

[0042] In some embodiments, the determination of the patching status is measured on a per-process basis. In one case, computer systems 101a / 101b start up without applying a new cold patch binary 114, but the new cold patch binary 114 is available, including application 104. A first instance of application 104 is loaded and running, and the loader 113 and the hot patch engine 110 have applied a hot patch binary 115 to it. The local update service 107 has determined that it is safe to apply the cold patch binary 114 to application 104 on disk. After applying the cold patch binary 114, a second instance of application 104 is loaded and run. In this case, the first instance of application 104 runs using the hot patch binary 115, while the second instance of application 104 runs using the cold patch binary 114. In these embodiments, audit service 108 analyzes computer systems 101a / 101b on a per-process basis to determine whether computer systems 101a / 101b meet one or more compliance conditions within policy 109. Strategy 109 can use additional attributes to determine the risk of two or more instances of application 104, and that its use by an administrator may pose a greater risk to computer system 101. However, if a hot-patched instance of application 104 may be more risky, but is used by a guest user (with fewer privileges), its risk can be determined to be lower. Many factors can determine risk, including which attacks the patch mitigates, user privileges, software dependencies, etc. In some embodiments, audit service 108 will determine that the hot-patched instance of application 104 is too risky to continue running. Audit service 108 will terminate the process or signal the OS kernel 112 to terminate the process. In some embodiments, local update service 107 maintains different versions (e.g., using different file paths) of software components within cold patch processing binary 114, each version supporting running instances / processes of that software component at computer systems 101a / 101b. In these embodiments, local update service 107 may also maintain various hot patches applicable to these different cold patch binaries within hot-patched binary 115.

[0043] In some embodiments, determining the patching status further includes, based on multiple pieces of evidence, determining whether at least a subset of one or more hot patch binaries has been applied to a memory image in system memory at the computer system, into which an instance of a particular software component has been loaded. Continuing with the foregoing example, in one scenario, the patch status determining component 121 consults the patch log 111 to determine whether, for at least one running instance of application 104, one or more hot patch binaries 115 have been applied to one of the cold patch binaries 114 (if applicable).

[0044] In some embodiments, determining the patch status also includes verifying whether a hot patch has indeed been applied to an instance of a particular software component. Therefore, some embodiments of action 202 include analyzing the memory image loaded therein to an instance of the particular software component to verify the application of a subset of one or more hot patch binaries. Access to memory may include taking a memory snapshot, collecting real-time memory dump data, executing a kernel driver that reads the appropriate memory region, etc. Continuing with the foregoing example, the patch status determination component 121 passively monitors the behavior of application 104 and / or OS 105 to ensure that appropriate hot patches are applied. In some embodiments, the patch status determination component 121 invokes an API or provides appropriate input to various patching components to determine whether they have been properly patched.

[0045] As described above, in some embodiments, one or more of the cold patch binary 114 and / or hot patch binary 115 are associated with digital signatures. In these embodiments, the patch status determination component 121 can verify from the patch log 111 that the appropriate sequence of cold and hot patches has been applied based on these signatures (e.g., audit trails). Therefore, in some embodiments of action 202, determining the patching status of a particular software component also includes verifying the validity of a chain of two or more digital signatures in the corresponding digital signatures from the patch log.

[0046] Method 200 further includes action 203 of formulating compliance conditions based on patch status. In an embodiment, action 201 includes formulating compliance actions for specific compliance conditions based on specific system policies and the determined patch status of specific software components. The compliance actions include at least one of the following: (i) generating at least one of a health report or health certificate, based at least on the patch status of the specific software component; (ii) initiating a patching action on the specific software component; or (iii) initiating an enforcement control action on the specific software component. Continuing the foregoing example, based on the compliance conditions determined by the policy identification component 120 in action 201 and based on the patch status of the instance of application 104 determined in action 202, compliance enforcement component 122 formulates compliance actions for application 104.

[0047] In some embodiments, compliance implementation component 122 generates a health report based at least on the patching status of a specific software component. In embodiments, the health report includes or is based on various factors within computer system 101a / 101b, such as the security status of the underlying operating environment in which the specific software component operates (e.g., based on secure boot technology, such as using a Trusted Platform Module), which cold and / or hot patches have been or have not been applied to the specific software component, the configuration status of the specific software component, etc. With particular reference to patching status, in some embodiments, generating a health report in action 203 includes generating a health score based at least on whether a subset of one or more hot patch binaries has been applied to a memory image in system memory to which an instance of the specific software component is loaded.

[0048] In embodiments, the health report also includes or is based on information external to computer systems 101a / 101b, such as information contained in a remote vulnerability database 118. For example, whether the application set of cold and hot patches resolves vulnerabilities identified in the remote vulnerability database 118 can affect the health score. Therefore, in some embodiments, generating a health report in action 203 includes generating a health score based at least on whether a subset of one or more hot patch binaries resolves vulnerabilities identified in an external vulnerability database. In some embodiments, audit service 108 transmits the generated health report to an external entity, such as remote authentication service 117.

[0049] In some embodiments, the compliance enforcement component 122 generates a health certificate based at least on the patching status of a specific software component. Similar to a health report, in embodiments, the generation of the health certificate is based on various factors internal and / or external to the computer system 101a / 101b. These factors may include the security status of the underlying operating environment in which the specific software component executes, which cold and / or hot patches have been or have not been applied to the specific software component, the configuration status of the specific software component, the configuration status and / or the state of the specific software component, whether the set of applied cold and hot patches resolves vulnerabilities identified by the remote vulnerability database 118, etc. In embodiments, the compliance enforcement component 122 generates a health certificate only when the generated health score / report is sufficiently high (e.g., based on identified compliance conditions). For example, in some embodiments, generating a health certificate in action 203 includes generating a health certificate only when a subset of one or more hot patch binaries has been applied to a memory image in system memory, into which an instance of the specific software component has been loaded. In other embodiments, generating a health certificate in action 203 further includes generating a health certificate only if the operating system is determined to have the identified trust level.

[0050] In some embodiments, the compliance enforcement component 122 “reduces” the health score over time, even without external input (e.g., new policy 109 from remote update service 116, new vulnerability information from remote vulnerability database 118, etc.). Therefore, for example, even when a software component has received a score sufficient for the compliance enforcement component 122 to issue a health certificate, the software component may subsequently receive a score insufficient to issue a continuing health certificate simply due to the passage of time (e.g., based on policy 109). As those skilled in the art will understand, reducing the health score over time can be useful for ensuring security in the event of a disconnect or partial connection, where computer systems 101a / 101b operate only with intermittent or limited access to remote update service 116. In particular, reducing the health score over time ensures that the computer system remains compliant only if it receives patches from remote update service 116 at least occasionally.

[0051] In some embodiments, the compliance enforcement component 122 sends a generated health report and / or certificate to a compliance service. For example, in one embodiment, computer systems 101a / 101b communicate with a first or third-party vulnerability assessment and / or compliance service, such as providing a compliance service (“CaaS”). In these embodiments, the compliance service authenticates whether computer systems 101a / 101b can continue to operate, at least in part, based on the patching status of computer systems 101a / 101b (including which hot patches have been applied). In another embodiment, the compliance service determines whether computer systems 101a / 101b can be authenticated operationally, at least based on whether a combination of cold and hot patches applied to computer systems 101a / 101b resolves a specific vulnerability identified in a remote vulnerability database 118. Therefore, by sending the generated health report and / or certificate to the compliance service, the compliance service is able to authenticate computer systems 101a / 101b for continued operation, at least in part, based on the hot patches applied to computer systems 101a / 101b. Referring to method 200, in some embodiments, generating a health report and / or health certificate in action 203 therefore includes sending the generated report or health certificate to a compliance service.

[0052] In some embodiments, compliance enforcement component 122 initiates a patching action on a specific software component. For example, if an instance of a specific software component has not yet been patched with one or more hot patch binaries 115 as required by a specific compliance condition, but these hot patches are available, compliance enforcement component 122 instructs hot patching engine 110 to apply these hot patches to the instance of the specific software component. Therefore, in some embodiments, initiating a patching action on a specific software component includes initiating the application of a subset of one or more hot patch binaries to a memory image loaded with an instance of the specific software component.

[0053] In another example, if an instance of a particular software component does not start with one of the cold patch binaries 114 as required by a particular compliance condition, but a cold patch is available, the compliance enforcement component 122 instructs the hot patch engine 110 to restart the software component from the appropriate cold patch. Therefore, in some embodiments, initiating a patching action on a particular software component includes initiating a reload of an instance of the particular software component from one or more cold patch binaries.

[0054] In another example, the cold and / or hot patches required for specific compliance conditions of a particular software component may not yet exist in cold patch binary 114 and / or hot patch binary 115. As a result, compliance enforcement component 122 instructs local update service 107 to download these patches from remote update service 116. Therefore, in some embodiments, initiating a patching action on a particular software component includes scheduling the download of one or more additional patch files for that particular software component.

[0055] In this embodiment, the patching action to be performed is selected based on policy 109. Therefore, in this embodiment, a specific patching action is selected at least in part based on one or more system policies.

[0056] In some embodiments, compliance enforcement component 122 initiates an execution control action on a specific software component. For example, if all cold patches and / or hot patches required for a specific compliance condition of a specific software component are present in cold patch binary 114 and / or hot patch binary 115, compliance enforcement component 122 allows the loader to initiate a new instance of the specific software component. Therefore, in some embodiments, initiating an execution control action on a specific software component includes allowing the loading of an additional instance of the specific software component. In these embodiments, compliance enforcement component 122 further ensures that all required hot patches are applied by the loader 113 during startup. Therefore, in embodiments, allowing the loading of an additional instance of the specific software component includes applying a subset of one or more hot patch binaries to an additional memory image of the additional instance of the specific software component.

[0057] In another example, if cold patch binary 114 and / or hot patch binary 115 lack all the cold patches and / or hot patches required for a specific compliance condition of a particular software component, the compliance enforcement component 122 refuses to allow the loader 113 to initiate an instance of the particular software component. Therefore, in some embodiments, initiating an enforcement control action on a particular software component includes refusing to load additional instances of the particular software component. Similarly, if cold patch binary 114 and / or hot patch binary 115 lack all the cold patches and / or hot patches required for a specific compliance condition of a particular software component, the compliance enforcement component 122 may terminate an instance of the particular software component that is already running. Therefore, in some embodiments, initiating an enforcement control action on a particular software component includes terminating an instance of the particular software component. This may occur if a new vulnerability is discovered and patches are still available, as will be understood by those skilled in the art.

[0058] In another example, there may be one or more other software components that depend on a particular software component for operation (e.g., when the particular software component is a library), and if all cold and hot patches required by a particular compliance condition of the particular software component are present and / or applied, the compliance enforcement component 122 may only allow those other software components to start. Therefore, in some embodiments, initiating an execution control action on a particular software component includes allowing the loading of other software components that depend on instances of the particular software component. Similarly, if cold and hot patches required by a particular compliance condition of the particular software component are absent and / or not applied, the compliance enforcement component 122 may refuse to start those other software components. Therefore, in some embodiments, initiating an execution control action on a particular software component includes refusing to load other software components that depend on instances of the particular software component.

[0059] In yet another example, if cold patch binary 114 and / or hot patch binary 115 lack all the cold and / or hot patches required for a specific compliance condition of a particular software component, compliance enforcement component 122 allows loader 113 to initiate a new instance of the particular software component, enabling that new instance to run in a sandboxed environment (e.g., container, virtual machine, jail, etc.). Therefore, in some embodiments, initiating enforcement control actions on a particular software component includes sandboxing an additional instance of the particular software component.

[0060] In some embodiments, method 200 is performed by an audit service residing in the same storage space as the operating system it runs on. For example, see reference... Figure 1A The audit service 108 resides in the same memory region as OS 105. In other embodiments, method 200 is performed by an audit service residing in a protected storage space unaffected by the operating system running there. For example, refer to... Figure 1B Audit service 108 resides in a protected memory region, while OS 105 resides in a separate OS memory region. Therefore, in the latter embodiment, method 200 is performed at least in part by a component residing in the protected memory region. In some embodiments, the protected memory region is isolated from hardware such as Intel Software Protection Extensions (SGX), ARM TrustZone, etc. In some embodiments, the protected memory region is isolated by a hypervisor from another memory region where a specific software component resides.

[0061] While this disclosure focuses on software patches, it should be understood that the principles discussed herein also apply to hardware updates / upgrades. For example, in an embodiment, audit service 108 considers the hardware configuration information of computer systems 101a / 101b when performing a health report / certification, including hardware added to computer systems 101a / 101b since startup, hardware removed from computer systems 101a / 101b since startup, hardware hot-swapped to computer systems 101a / 101b since startup, hardware firmware updates, etc. Therefore, for example, if firmware is outdated or becomes vulnerable, if hardware is outdated or deemed vulnerable or unstable, if unknown hardware has been added, if required hardware has been removed, etc., audit service 108 can refuse compliance certification.

[0062] Therefore, the embodiments described herein assess and enforce system compliance based on a mix of cold and hot patches available and / or active on the computer system. These embodiments utilize one or more strategies to determine the compliance conditions of one or more software components, at least based on which cold and hot patches are applied to operational instances of these software components to determine the health status of these additional software components, and to formulate one or more compliance actions for the compliance conditions, such as generating health reports and / or health certificates for these software components, initiating patching actions for these software components, initiating execution control actions for these components, and so on.

[0063] Although the subject matter has been described in language specific to structural features and / or methodological behavior, it should be understood that the subject matter defined in the appended claims is not limited to the features or behaviors described above, or the order of such behaviors. Rather, the described features and actions are disclosed only as examples of implementing the claims.

[0064] Embodiments of the present invention may include or utilize dedicated or general-purpose computer systems comprising computer hardware, such as one or more processors and system memory, as discussed in more detail below. Embodiments within the scope of the present invention also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media may be any available medium accessible by a general-purpose or dedicated computer system. A computer-readable medium storing computer-executable instructions and / or data structures is a computer storage medium. A computer-readable medium carrying computer-executable instructions and / or data structures is a transmission medium. Thus, by way of example and not limitation, embodiments of the present invention may include at least two distinctly different computer-readable media: computer storage media and transmission media.

[0065] Computer storage media are physical storage media that store computer-executable instructions and / or data structures. Physical storage media include computer hardware such as RAM, ROM, EEPROM, solid-state drives (“SSDs”), flash memory, resistive RAM, phase-change memory (“PCM”), optical disc storage, magnetic disk storage, or other magnetic storage devices, or any other hardware storage device that can be used to store program code in the form of computer-executable instructions or data structures, which can be accessed and executed by general-purpose or special-purpose computer systems to achieve the functions disclosed in this invention.

[0066] Transmission media may include networks and / or data links, which may be used to carry program code in the form of computer-executable instructions or data structures and may be accessed by general-purpose or special-purpose computer systems. A “network” is defined as one or more data links used to transmit electronic data between computer systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computer system via a network or another communication connection (hardwired, wireless, or a combination of hardwired and wireless), the computer system may consider that connection as a transmission medium. Combinations of the foregoing should also be included within the scope of computer-readable media.

[0067] Furthermore, upon arrival at various computer system components, program code in the form of computer-executable instructions or data structures can be automatically transferred from the transmission medium to the computer storage medium (and vice versa). For example, computer-executable instructions or data structures received via a network or data link can be buffered in RAM within a network interface module (e.g., a "NIC") and then ultimately transferred to the computer system RAM and / or the non-volatile computer storage medium at the computer system. Therefore, it should be understood that computer storage media can be included in computer system components that also (or even primarily) utilize the transmission medium.

[0068] Computer-executable instructions include, for example, instructions and data that, when executed at one or more processors, cause a general-purpose computer system, a special-purpose computer system, or a special-purpose processing device to perform a specific function or set of functions. Computer-executable instructions can be, for example, binary files, intermediate format instructions such as assembly language, or even source code.

[0069] Those skilled in the art will understand that this invention can be practiced in network computing environments with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, mainframe computers, mobile phones, PDAs, tablets, pagers, routers, switches, etc. This invention can also be practiced in distributed system environments, where both local and remote computer systems perform tasks, and the local and remote systems are linked via a network (via a hardwired data link, a wireless data link, or a combination of hardwired and wireless data links). Thus, in a distributed system environment, the computer system can include multiple component computer systems. In a distributed system environment, program modules can reside in local and remote memory storage devices.

[0070] Those skilled in the art will also understand that the present invention can be practiced in a cloud computing environment. A cloud computing environment can be distributed, although this is not required. When distributed, a cloud computing environment can be internationally distributed within an organization and / or have components owned across multiple organizations. In this specification and claims, “cloud computing” is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources, such as networks, servers, storage, applications, and services. The definition of “cloud computing” is not limited to any other numerous advantages that can be obtained from such a model when properly deployed.

[0071] Cloud computing models can be composed of various features, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, and measurable services. Cloud computing models can also take the form of various service models, such as Software as a Service (“SaaS”), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), and CaaS. Furthermore, different deployment models can be used to deploy cloud computing models, such as private clouds, community clouds, public clouds, and hybrid clouds.

[0072] Some embodiments, such as cloud computing environments, may include a system comprising one or more hosts, each capable of running one or more virtual machines. During operation, the virtual machines emulate the running of a computing system, while supporting an operating system and possibly one or more other applications. In some embodiments, each host includes a hypervisor that emulates the virtual resources of the virtual machines using physical resources abstracted from a view of the virtual machines. The hypervisor also provides appropriate isolation between the virtual machines. Thus, from the perspective of any given virtual machine, the hypervisor provides the illusion that the virtual machine interacts with physical resources, even if the virtual machine only interacts with the appearance of the physical resources (e.g., virtual resources). Examples of physical resources include processing capacity, memory, disk space, network bandwidth, media drives, etc.

[0073] The invention may be practiced in other specific forms without departing from the spirit or essential characteristics thereof. The described embodiments are to be considered illustrative rather than restrictive in all respects. Therefore, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All modifications within the meaning and equivalence of the claims should be included within their scope. When elements are introduced in the appended claims, the terms “a,” “an,” “the,” and “said” are intended to indicate the presence of one or more elements. The terms “comprising,” “including,” and “having” are intended to be inclusive, meaning that other elements besides those listed may exist. The terms “set” and “subset” are indented to exclude an empty set; therefore, “set” is defined as a non-empty set, and “subset” is defined as a non-empty subset.

Claims

1. A method implemented at a computer system including a processor for developing compliance actions using an assessment that takes into account a mixture of cold and hot patches, the method comprising: Based on the patching status of software components, identify one or more system policies that define one or more compliance conditions, including identifying specific system policies that define a set of compliance conditions for a specific software component, the set of compliance conditions including: The first compliance requirement, as defined, is that when the objective of the computer system is a security objective, specific cold patch binaries for the particular software component must be installed to maintain compliance. The second compliance condition is defined as follows: when the objective for the computer system is an availability objective, installing a specific hot patch binary for the specific software component is sufficient to maintain compliance, and the specific hot patch binary lacks the fixes present in the specific cold patch binary; Determining the patching status of the specific software component includes: Identify multiple pieces of evidence, each corresponding to a binary file among multiple binary files that has been applied to the specific software component, the multiple binary files including (i) one or more cold patch binary files from which the specific software component can be loaded, and (ii) one or more hot patch binary files applicable to the specific software component; and Based on the aforementioned evidence, at least one of the following is determined: The objective against the computer system is the security objective, and the instance of the specific software component was not loaded from the specific cold patch binary; or The objective for the computer system is the availability objective, and the specific hot-patch binary has not yet been applied to the memory image in which the instance of the specific software component is loaded. Based on the specific system policy and the determined patching status of the specific software component, formulate a compliance action for one of the first or second compliance conditions, the compliance action including at least one of the following: At least one of a health report or a health certificate shall be generated based on the patching status of the specific software component. Initiate a patching action on the specific software component; or Initiate and execute control actions on the specific software component.

2. The method of claim 1, wherein the method generates the health report based at least on the patching status of the specific software component, and wherein generating the health report includes at least one of the following: A health score is generated at least based on the premise that the target for the computer system has been identified as the security target and that an instance of the specific software component is loaded from the specific cold patch binary; or The health score is generated based on the availability target already determined for the computer system, and the memory image in which the specific hot-patch binary has been applied to the instance of the specific software component being loaded.

3. The method of claim 1, wherein the method generates the health certificate based at least on the patching status of the specific software component, and wherein generating the health certificate comprises: The health certificate is generated only if the operating system is determined to have the identified trust level.

4. The method of claim 1, wherein the method generates at least one of the health report or the health certificate, and wherein the method further comprises: Send the generated report or health certificate to the compliance service.

5. The method of claim 1, wherein the method initiates the patching action on the specific software component, and wherein initiating the patching action on the specific software component comprises at least one of the following: The application of the specific hot-patched binary to the memory image is initiated, and the instance of the specific software component is loaded into the memory image; Initiate a reload of the instance of the specific software component from the specific cold patch binary; or Schedule the download of one or more additional patch files for the specific software component.

6. The method of claim 5, wherein a particular patching action is selected at least in part based on the one or more system policies.

7. The method of claim 1, wherein the method initiates the execution control action on the specific software component, wherein initiating the execution control action on the specific software component includes at least one of the following: Allows the loading of additional instances of the specific software component; Reject the loading of the additional instance of the specific software component; Allows the loading of other software components that depend on the instance of the specific software component; Reject the loading of other software components that depend on the instance of the specific software component; Terminate the instance of the specific software component; or The additional instance of the specific software component is sandboxed.

8. The method of claim 7, wherein allowing the loading of the additional instance of the particular software component comprises: The application of the specific hot-patched binary to the additional storage image is performed, and the additional instance of the specific software component is loaded into the additional storage image.

9. The method of claim 1, wherein determining the patching status of the specific software component further comprises: The memory image is analyzed to verify the application of the specific hot-patch binary, and the instance of the specific software component is loaded into the memory image.

10. The method of claim 1, wherein each of the one or more cold patch binaries and the one or more hot patch binaries is associated with a corresponding digital signature, and wherein determining the patching status of the particular software component further comprises: Verify the validity of the chain of two or more digital signatures in the corresponding digital signature from the patch log.

11. The method of claim 1, wherein the method is performed at least in part by a component residing in a protected memory region, the protected memory region being isolated from another memory region in which the particular software component resides.

12. The method of claim 1, wherein at least one of the one or more system policies is received or encoded in a patch file.

13. The method of claim 1, wherein the specific system strategy includes at least one of a health strategy or a functional strategy.

14. A computer system for developing compliance actions using an assessment that considers both cold and hot patches, comprising: processor; as well as Hardware storage device storing computer-executable instructions that can be executed by the processor to at least: Based on the patching status of software components, identify one or more system policies that define one or more compliance conditions, including identifying specific system policies that define a set of compliance conditions for a specific software component, the set of compliance conditions including: The first compliance requirement, as defined, is that when the objective of the computer system is a security objective, specific cold patch binaries for the particular software component must be installed to maintain compliance. The second compliance condition is defined as follows: when the objective for the computer system is an availability objective, installing a specific hot patch binary for the specific software component is sufficient to maintain compliance, and the specific hot patch binary lacks the fixes present in the specific cold patch binary; Determining the patching status of the specific software component includes: Identify multiple pieces of evidence, each corresponding to a binary file among multiple binary files that has been applied to the specific software component, the multiple binary files including (i) one or more cold patch binary files from which the specific software component can be loaded, and (ii) one or more hot patch binary files applicable to the specific software component; and Based on the aforementioned evidence, at least one of the following is determined: The objective against the computer system is the security objective, and the instance of the specific software component was not loaded from the specific cold patch binary; or The objective for the computer system is the availability objective, and the specific hot-patch binary has not yet been applied to the memory image in which the instance of the specific software component is loaded. Based on the specific system policy and the determined patching status of the specific software component, formulate a compliance action for one of the first or second compliance conditions, the compliance action including at least one of the following: At least one of a health report or a health certificate shall be generated based on the patching status of the specific software component. Initiate a patching action on the specific software component; or Initiate and execute control actions on the specific software component.

15. The computer system of claim 14, wherein the computer system generates the health report based at least on the patching status of the particular software component, and wherein generating the health report includes at least one of the following: A health score is generated at least based on the premise that the target for the computer system has been identified as the security target and that an instance of the specific software component is loaded from the specific cold patch binary; or The health score is generated based on the availability target already determined for the computer system, and the memory image in which the specific hot-patch binary has been applied to the instance of the specific software component being loaded.

16. The computer system of claim 14, wherein the computer system generates the health certificate based at least on the patching status of the particular software component, and wherein generating the health certificate comprises: The health certificate is generated only if the operating system is determined to have the identified trust level.

17. The computer system of claim 14, wherein the computer system initiates the patching action on the specific software component, and wherein initiating the patching action on the specific software component includes at least one of the following: The application of the specific hot-patched binary to the memory image is initiated, and the instance of the specific software component is loaded into the memory image; Initiate a reload of the instance of the specific software component from the specific cold patch binary; or Schedule the download of one or more additional patch files for the specific software component.

18. The computer system of claim 14, wherein the computer system initiates the execution control action on the specific software component, and wherein initiating the execution control action on the instance of the specific software component includes at least one of the following: Allows the loading of additional instances of the specific software component; Reject the loading of the additional instance of the specific software component; Allows the loading of other software components that depend on the instance of the specific software component; Reject the loading of other software components that depend on the instance of the specific software component; Terminate the instance of the specific software component; or The additional instance of the specific software component is sandboxed.

19. The computer system of claim 14, wherein each of the one or more cold patch binaries and the one or more hot patch binaries is associated with a corresponding digital signature, and wherein determining the patching status of the particular software component further comprises: Verify the validity of the chain of two or more digital signatures in the corresponding digital signature from the patch log.

20. A computer program product comprising a hardware storage device storing computer-executable instructions, the computer-executable instructions being executable by a processor to enable a computer system to formulate compliance actions using an assessment that takes into account a mixture of cold and hot patches, the computer-executable instructions including instructions executable by the processor to enable the computer system to at least: Based on the patching status of software components, identify one or more system policies that define one or more compliance conditions, including identifying specific system policies that define a set of compliance conditions for a specific software component, the set of compliance conditions including: The first compliance requirement, as defined, is that when the objective of the computer system is a security objective, specific cold patch binaries for the particular software component must be installed to maintain compliance. The second compliance condition is defined as follows: when the objective for the computer system is an availability objective, installing a specific hot patch binary for the specific software component is sufficient to maintain compliance, and the specific hot patch binary lacks the fixes present in the specific cold patch binary; Determining the patching status of the specific software component includes: Identify multiple pieces of evidence, each corresponding to a binary file among multiple binary files that has been applied to the specific software component, the multiple binary files including (i) one or more cold patch binary files from which the specific software component can be loaded, and (ii) one or more hot patch binary files applicable to the specific software component; and Based on the aforementioned evidence, at least one of the following is determined: The objective against the computer system is the security objective, and the instance of the specific software component was not loaded from the specific cold patch binary; or The objective for the computer system is the availability objective, and the specific hot-patch binary has not yet been applied to the memory image in which the instance of the specific software component is loaded. Based on the specific system policy and the determined patching status of the specific software component, formulate a compliance action for one of the first or second compliance conditions, the compliance action including at least one of the following: At least one of a health report or a health certificate shall be generated based on the patching status of the specific software component. Initiate a patching action on the specific software component; or Initiate and execute control actions on the specific software component.

Images