METHOD, STORAGE MEDIUM AND COMPUTER PLATFORM FOR PROCESS MONITORING USING MEMORY SEARCH AND HEARTBEAT MONITORING

Abstract

A method (1000) comprising: an operating system agent (106) of a computer system that monitors a process (108) to detect whether the integrity of the process (108) has been compromised, wherein the monitoring includes scanning a data structure (119) by the operating system agent (106), the process (108) is executed in a user space (115), the data structure (119) is part of an operating system kernel space (117), and wherein the operating system agent generates a heartbeat (230), and the heartbeat (230) comprises a sequence of clues that follow a schedule to indicate that the operating system agent is operating in an acceptable state; a hardware controller of the computer system that waits for the heartbeat (230), wherein the hardware controller is separate from the operating system agent (106);wherein the hardware controller takes a corrective action in response to at least one of the following: the hardware controller detects an interruption of the heartbeat (230), or the operating system agent sends a security alert for the process (108) to the hardware controller; and an application (111) that registers the process (108) with the operating system agent, the operating system agent beginning to monitor the process (108) in response to the registration.

Description

BACKGROUNDA computing platform (e.g., a server) may be subject to a security attack where an external device attempts to access information stored on the computing platform or damage components of the computing platform. To prevent or at least limit the extent of damage caused by security attacks, the computing platform may have various levels of protection. For example, the computing platform may have various access restriction mechanisms, such as firewalls, keywords, keys, etc. Another example is malware protection software that searches directories for malware agents. As further examples, the computing platform may periodically measure its software components so that the measurements may be analyzed (e.g., by analysis tools on a remote server) to determine whether tampering has occurred; events (login password errors, web site accesses, etc.) occurring on the computing platform may be monitored with a system information and event management system (SIEM), etc. US 2019 / 0 384 918 A1 describes a method for monitoring integrity of a computer system. EP 3 514 720 A1 describes a system comprising 1) an inner kernel of an operating system (OS), the inner kernel measuring a data structure in a memory, 2) a device to measure the data structure in the memory, the device operating independently of the OS, and 3) a trusted execution environment containing an application to compare measurements from the inner kernel and the device. It is an object of the invention to propose a method for process monitoring, a corresponding non-transitory storage medium and a corresponding computer platform. This object is achieved by a method according to the invention as claimed in claim 1, a non-transitory storage medium according to the invention as claimed in claim 8 and by a computer platform according to the invention as claimed in claim 14.BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 is a schematic diagram of a computing platform including an operating system kernel-based process monitor for monitoring the integrity of user space processes, according to an example implementation. FIG. 2 is an illustration of process monitoring by the process monitor of FIG. 1, including extension of process monitoring by a baseboard management controller of the computing platform, according to an example implementation. FIG. 3 is a flow diagram illustrating searching of a kernel space-based data structure of a user space process for suspect library common objects, according to an example implementation. FIG. 4 is a flow diagram illustrating scanning a kernel space-based data structure of a user space process to search for copy-on-write (COW) executable pages according to an example implementation.FIG. 5 is a flow diagram illustrating the passing of a heartbeat seed or key to an operating system of the computing platform, according to an example implementation. FIG. 6 is a flow diagram illustrating a technique used by the process monitor to generate and send a heartbeat message to the baseboard management controller, according to an example implementation.FIG. 7 is a flow diagram illustrating a method for monitoring the heart beat used by the process monitoring according to an example implementation. FIG. 8 is a flow diagram illustrating a technique used by the baseboard management controller to authenticate heartbeat messages, according to an example implementation. FIG. 9 is a flow diagram illustrating a technique used by the baseboard management controller to respond to a warning message from the process monitor and to respond to a heartbeat interrupt from the process monitor, according to an example implementation. FIG. 10 is a flow diagram illustrating a technique for monitoring a user space process using an operating system agent and a hardware controller, according to an example implementation. FIG. 11 is an illustration of a non-transitory storage medium storing machine readable instructions to cause a machine to monitor a process according to an example implementation. FIG. 12 is a schematic diagram illustrating a computing platform that uses an operating system kernel extension and a baseboard management controller to monitor a process, according to an example implementation.DETAILED DESCRIPTIONA computing platform (e.g., a server, a portable computer, a tablet computer, etc.) may have a variety of user space processes, such as user space processes, that provide security services to the computing platform. In this context, a "process" refers to an instance of an executed program, such as an instance of an application. A particular process may be single-threaded (i.e., a single thread) or multi-threaded (i.e., multiple threads), where a "thread" refers to a unit of executable program instructions. For example, multiple threads may be executed in parallel by multiple processor cores of the computing platform to perform a particular task or a series of tasks for the computing platform.The storage area of the computing platform may be divided into a kernel area and a user area. The "kernel space" refers to the storage area of the computing platform in which the kernel code of the operating system is stored and executed, and the "user space" refers to the storage area of the computing platform used by non-operating system kernel processes (or "user space processes") such as application processes. The kernel space has the highest privilege level and cannot be entered by user space processes. Kernel processes can access both kernel space and user space. An example of a user space process that provides security services to a computing platform is the instance of an executed malware protection application. A Linux kernel and a Windows NT kernel are examples of operating system kernels.Because processes that provide security services to the computer system may be located within the user area, these processes may be vulnerable to malware security attacks. In this context, malware generally refers to any software that has been developed with the aim of intentionally damaging a computer system (e.g., a single computer platform or network of computer platforms) and / or extracting information from the computer system. Malware exists in various forms, e.g. as viruses, ransomware, worms, Trojan horses, etc.Malware (e.g., robin food ransomware) may stop or shut down the processes associated with the security services in the user space to remain hidden and penetrate deeper into a enterprise's computer system. Terminating these security service-related user space processes may be combined with conventional malware-based attacks (e.g., injection attacks, process-cull attacks, etc.) to bypass defense actions and potentially increase malware agent permissions.According to the example implementations described herein, a computer system, e.g., a computer platform, includes an operating system kernel agent, referred to as a "process monitor," that monitors user space processes (e.g., processes that provide security services) to determine whether the integrity of these processes has been compromised. In accordance with example implementations, the process monitor scans data structures in kernel space (e.g., virtual memory areas (VMAs)) that contain information about corresponding portions of the address space of a monitored user process. By monitoring the kernel space data structures, the process monitor may identify a particular state of the storage state of the process that is consistent with the integrity of the compromised process. For example, the process monitor may identify a process storage state that indicates that the monitored process has been subject to a process cavity or that code has been injected into the process.Since the process monitor is part of the operating system kernel and the monitored data structures are located in the kernel domain, monitoring the processes in the user domain is very resistant to tampering. In accordance with example implementations, monitoring by the process monitor is enhanced by the computer platform hardware to further enhance monitoring by the process monitor against a potentially powerful attacker. More specifically, in accordance with some implementations, the process monitor generates a heartbeat; and a hardware controller (e.g., a baseboard management controller) of the computing platform listens to the heartbeat. If the hardware controller detects an interrupt to the heartbeat, the hardware controller may assume that the integrity of the operating system kernel (and process monitoring) has been compromised and take remedial or corrective action. As described further below, the remedial action may include shutting down the computing platform, restarting the computing platform, notifying a remote management server, etc. In this context, a "heartbeat" refers to a repeating sequence of signals, pings, or indicators, such as messages following a particular schedule (e.g., a periodic schedule), to represent that the unit sending or generating the heartbeat is operating in an acceptable state. Thus, the disruption of the heartbeat (e.g., a missing signal, ping, or a missing indication of the heartbeat) corresponds to the device not being in an acceptable state.According to example implementations, the hardware controller receives an alert from the process monitor when it detects a storage state of a monitored user space process that is consistent with a risk to the integrity of the process. The hardware controller may take corrective action in response to such a warning (e.g., shutting down the computing platform, restarting the computing platform, notifying a remote management server, etc.).As further described herein, in accordance with example implementations, the process monitor may listen to the heartbeat of a monitored user space process such that when the user space process ceases to operate (e.g., due to malware terminating the process), that event may be detected by the process monitor via the detected absence of the heartbeat. Thus, in some implementations, there may be a hierarchy of heartates for the monitored user space processes: a first hierarchical level of heartates sent from monitored processes that can be used to detect manipulations on the processes, and a second hierarchical level containing a heartate sent from the process monitor that can be used to detect manipulations on the process monitor (and thus on the kernel). As further described herein, sending a heartbeat (and monitoring the heartbeat accordingly) through a particular monitored user space process may be optional, whereby memory scan-based monitoring may also be used for a legacy user space process that does not support generation of a heartbeat.Referring to FIG. 1, as a more specific example, a computing platform 100, in accordance with some implementations, may include one or more processors 110 (e.g., one or more central processing units (CPUs), one or more CPU processing cores, and so forth), and a system memory 114. System memory 114 and other memory discussed herein are non-transitory storage media that may be formed from semiconductor memory devices, memristor-based memory devices, magnetic memory devices, phase-change memory devices, a combination of devices from one or more of these memory technologies, etc. System memory 114 may be a collection of memories from volatile and nonvolatile memory devices.In accordance with example implementations, the memory locations of system memory 114 include a user space 115 and a kernel space 117. Kernel space 117 represents memory locations of system memory 114 in which operating system kernel code corresponding to operating system kernel 104 is stored and executed; and user space 115 refers to the memory space of system memory 114 used by non-operating system kernel processes (or "user space processes"), such as processes corresponding to executing instances of applications 111. As further described herein, a particular user space process may be a monitored user space process 108 (also referred to herein as "monitored process 108" or "process 108").The computing platform 100 is only one example of a number of different potential architectures consistent with the many possible implementations. Generally, regardless of its particular architecture, the computing platform is a processor-based electronic device having an operating system with an associated kernel and user domain. The computing platform 100 may be, for example, a stand-alone server, a rack-mounted server module, a rack-mounted edge processing module, a server blade, a blade chassis having one or more server blades, a client, a thin client, a desktop computer, a portable computer, a laptop computer, a notebook, a tablet computer, a smartphone, a portable computer, etc.According to example implementations, the computing platform 100 includes a kernel-range operating system agent referred to as a "process monitor 106" (also referred to herein as an "operating system kernel-based process monitor 106") that can monitor one of a plurality of user-range processes 108 to detect or determine whether the integrity of the processes 108 has been compromised (i.e., to detect whether a tampering has occurred). In accordance with example implementations, the process monitor 106 may be an extension of the operating system kernel 104, such as a loadable kernel module (LKM) for a Linux operating system corresponding to code 135 loaded during installation of the operating system; and after installation of the operating system, the process monitor 106 becomes part of the operating system kernel 104.As further described herein, in accordance with example implementations, the process monitor 106 provides an application programming interface (API) 109 that enables an application 111 to register a user space process corresponding to an instance of the application 111 such that the process, when registered, becomes a registered user space process 108 monitored by the process monitor 106.In accordance with some implementations, the API 109 may provide a register() function that is invoked to register a process (to become a corresponding monitored process 108) and obtain a process identification (ID) for the process, among other parameters. The API 109 may also provide a ping() function that may be invoked to select optional monitoring of a heartbeat from the process 108. Among other parameters, the ping() function may obtain a parameter representing a timeout period for the heartbeat. The API 109 may also provide a function unregister( ) that cancels the registration of the process as the monitored process 108. It should be appreciated that monitoring a heartbeat of a monitored process 108 may be optional, in accordance with example implementations, to account for the inability of a legacy process to generate the heartbeat.FIG. 2 is an illustration 200 of monitoring processes 108 by the process monitor 106, in accordance with example implementations. Referring to FIG. 2 in conjunction with FIG. 1, in accordance with example implementations, the process monitor 106 scans a portion of the kernel space 117 associated with the monitored user space process 108 to acquire corresponding memory scan data 224. More specifically, in accordance with some implementations, the process monitor 106 may periodically query one or more operating system kernel space data structures 119 (also referred to herein as "kernel space data structures 119" and "data structures 119") that describe corresponding user space storage areas (e.g., virtual storage areas) of the monitored process 108. Kernel space data structures 119 are used by operating system kernel 104 to track and manage the user storage area of supervised process 108. For example, the kernel 104 may use the data structures 119 to manage page retrieval, copy-on-writes (COWs), file storage allocation, paging requests, etc. In accordance with example implementations, the monitored process 108 may have multiple kernel space data structures 119, each kernel space data structure 119 corresponding to a different contiguous virtual memory space of the process 108, and the contiguous virtual memory space having common characteristics.For example, in some implementations for a Linux operating system, the kernel data structure 119 may be a virtual storage area (VMA) that includes pointers to the virtual start and end addresses of a corresponding contiguous segment of the virtual storage; flags indicating whether the respective pages are readable only; flags indicating whether the respective pages are dirty; flags indicating whether the respective pages are executable; data representing a backup storage resource; data representing reverse mapping structures; and so forth. A given user space supervised process 108 may have multiple VMAs, e.g., one VMA for the corresponding program code, another VMA for each data type, one VMA for each different memory map, etc., according to example implementations.According to example implementations, the process monitor 106 may scan the kernel space data structure(s) 119 for a particular monitored user space process 108 from time to time (e.g., periodic interval scanning, continuous scanning and re-scanning, periodic scanning according to a predefined schedule, etc.) to determine whether the monitored user space process 108 has a particular storage state that indicates or represents that the integrity of the process 108 has been compromised based on the observed data stored in the data structure(s) 119. This determination may include determining (as described below in connection with FIG. 3 ) whether the monitored user space process 108 has any shared library objects (referred to herein as "suspect library objects") that indicate an attempt to load a malicious library in the context of a process; and / or the determination may include determining (as described below in connection with FIG. 4 ) whether the monitored user space process 108 has any copy-on-write (COW) execution pages that would be consistent with injection of malicious code.With continued reference to FIG. 2 in conjunction with FIG. 1, in the event that scanning the kernel space data structure(s) 119 of a process reveals a storage state indicative or representing an integrity compromise of the process 108, the process monitor 106 sends a warning 240 (e.g., a message) to a hardware controller of the computing platform, such as the baseboard management controller 170, in accordance with example implementations. Generally, the alert 240 identifies a particular monitored user space process 108 and presents a particular integrity compromise problem to the process 108 detected or determined by the process monitor 106.According to example implementations, process monitoring and reporting is further protected from compromise by a malware agent by sending alerts (240) to hardware such as baseboard management controller 170. As further described herein, in accordance with some implementations, the baseboard management controller 170 may include a silicon root of trust (SRoT) for the computing platform 100; and as such, the baseboard management controller 170 serves as a highly trusted entity to send a corresponding alert 250 (e.g., a message) to the remote management server 194 in response to an alert 240. In accordance with example implementations, similar to alert 240, alert 250 may include, for example, an identifier for the user space monitoring process 108 in question, along with other information representing details of the type of integrity breach detected by process monitor 106. As further described herein, a particular alert 520 may also be used to notify a remote management server 194 that the kernel 104 has been compromised.The baseboard management controller 170 may take additional and / or other corrective or remedial action (other than sending the alarm 250) in response to receiving an alarm 240 from the process monitor 106, depending on the particular implementation. For example, in accordance with some implementations, the baseboard management controller 170 may disable the computing platform 100 in response to receiving a warning 240 and request a password, key, or other credential (e.g., a credential provided via a remote management server 194) before allowing the computing platform 100 to restart. As another example, in accordance with some implementations, the baseboard management controller 170 may restart (i.e., perform a power-on reset) the computing platform 100 in response to receiving a warning 240. According to some implementations, the particular remedial action taken by the baseboard management controller 170 may be based on a predefined user policy.As also shown in FIG. 2, in accordance with some implementations, the process monitor 106 may send a heartbeat 230 to the baseboard management controller 170. For example, the heartbeat 230 may correspond to a sequence of messages (e.g., Peripheral Component Interconnect express (PCIe) messages), where each message corresponds to a particular heartbeat indication or ping of the heartbeat 230. The baseboard management controller 170 waits for the heartbeat 230 so that in the event of a heartbeat 230 being interrupted (e.g., when the baseboard management controller 170 does not receive a heartbeat indication or ping within a certain amount of time), the baseboard management controller 170 may send a corresponding warning 250 to the remote management server 194 and / or take additional or other remedial action according to a predefined user policy, in accordance with example implementations.By listening to the heartbeat 230, the baseboard management controller 170 may identify whether the integrity of the process monitor 106, and thus the integrity of the operating system kernel 104, has been compromised. This protects the process monitor from a relatively powerful opponent who may manipulate the kernel 104 and otherwise (without the heartbeat mechanism 230) may disable the monitoring by the process monitor 106 without this disable being detected by the baseboard management controller 170. It should be appreciated that, in accordance with example implementations, the computing platform 100 may apply one or more additional actions (i.e., actions in addition to monitoring the heartbeat 230) to determine or recognize whether the integrity of the operating system kernel 104 has been compromised. For example, in accordance with some implementations, the baseboard management controller 170 may include a scan engine (e.g., an engine comprised of hardware, machine-executable instructions, or a combination thereof), such as the scan engine described in U.S. Patent Application Publication No. 2019 / 0384918, which may scan kernel data structures, kernel code, and loadable kernel modules (such as the process monitor 106) to ensure that the operating system kernel 104 and its extensions have not been altered. The scan engine is an example because the computing platform 100, according to further implementations, may include one or more different and / or additional mechanisms for monitoring the integrity of the operating system kernel 104.The baseboard management controller 170 may transmit process monitoring information other than the alerts 250 to a remote management server 194. For example, as shown in FIG. 2, in accordance with some implementations, the process monitor 106 may send non-alerting report messages 244 to the baseboard management controller 170 that contain data about the results of the memory scan; and the baseboard management controller 170 may compile the data and send corresponding report messages 260 to the remote management server 194 to report the results.For example, in accordance with some implementations, the process monitor 106 may send a report message 244 to the baseboard management controller 170 that includes data representing the shared library objects for a particular monitored user space process 108 found as a result of checking the corresponding kernel space data structures 119. Report message 244 may also include the corresponding file paths of the shared library objects. For example, by reporting (via report messages 260) the shared library objects and file paths to remote management server 194, the security verification tools on server 194 (or other entity) may compare the file paths of the shared library objects to the file paths recorded in an Integrity Measurement Architecture (IMA) protocol for computing platform 100. The discrepancies between the file paths found in this comparison may indicate, for example, that the integrity of certain software components of the computing platform 100 has been compromised.As another example, in some implementations, the computing platform 100 may be one of a fleet of servers; the data from the storage scan reports provided by the fleet servers may be statistically analyzed (e.g., by tools on a remote management server 194 or other component); and a warning for a particular fleet server may be generated in response to a particular server statistics representing an outlier with respect to corresponding statistics from the remainder of the fleet.FIG. 2 also shows the process monitor 106 monitoring heart beds 210 generated by the respective monitored user space processes 108. In accordance with example implementations, an application 111 (FIG. 1 ) may select, via the API 109, the heartbeat monitor for a particular monitored user space process 108 along with a particular amount of time for the heartbeat 210. If the process monitor 106 detects an interruption of the heartbeat 210 (i.e., does not detect a heartbeat display or ping within the timeout period for the heartbeat 210), the process monitor 106 may send a corresponding warning 240 to the baseboard management controller 170 so that the controller 170 may then take the corresponding remedial or corrective actions (e.g., restart, transmit a warning 250 to a remote management server 194, etc.). It should be appreciated that, in accordance with example implementations, the heartbeat monitor for the monitored user space processes 108 is optional, for example, allowing a legacy user space process 108 to scan its memory through the process monitor 106, while omitting the heartbeat monitor for the process 108.In some implementations, the API 109 may be a socket-style API, such as a Netlink API for the Linux operating system. A socket-style API may generally be easier to use than, for example, an API implemented with non-standard system calls or mechanisms based on ioclt system calls for the Linux operating system. In accordance with example implementations, the user space process 108 may bind to a socket, whereby the process 108 may be verified by the process monitor 106. After the process passes verification, the process monitor 106 may perform scanning of the kernel space data structures 119 associated with the process 108 and monitor the process's heartbeat 210 (if this option is selected).In accordance with some implementations, computing platform 100 does not provide an additional mechanism to protect against snooping of heart beat 210 because a socket messaging system such as Netlink provides sufficient contextual information for authenticating heart beat 210. In this regard, the user space process 108 sends its respective process ID that the process monitor 106 can use to securely identify the source of the heartbeat 210. Moreover, according to example implementations, the socket messaging system supports duplex communication such that the process monitor 106 can send a message to a user space process 108 to request further information from the process 108 to verify the source of the heartbeat 210.In accordance with other implementations, the API 109 may not be a socket API and may be invoked via system calls.The functions of the process monitor 106 may be implemented using a work queue 228 (e.g., a Linux queue). In general, a scheduler of the process monitor 106 may provide units of work 229 for the work queue 228, where each unit of work 229 may represent a particular task or function to be performed by a corresponding kernel thread. In general, the use of the work queue 228 allows a multi-threading approach to perform the functions of the process monitor 106. As examples, these functions may include registering a user space process 108 for monitoring memory sensing, registering a user space process 108 for monitoring the heartbeat 210, performing a memory sensing of data structures 119 corresponding to a user space process 108, listening to a heartbeat 210 from a user space process 108, generating pings (e.g., messages) for the heartbeat 230, regulating sending alerts 240 to the baseboard management controller 170, sending report messages 244 to the baseboard management controller 170, de-registering a user space process 108 for monitoring, etc.Returning to FIG. 1, in accordance with example implementations, the computing platform 100 may include, in addition to the processor(s) 110, the system memory 114, and the baseboard management controller 170, various other hardware components, such as an input / output (I / O) bridge or platform controller hub (PCH) 118; one or more mass storage devices 130; a non-volatile memory 184 (e.g., flash memory) storing the firmware 176; one or more network interface cards (NICs) 113; a trusted platform module (TPM) 188; I / O devices (e.g., a keyboard, a mouse, a trackpad, a display, etc.); PCIe option cards and so on.The baseboard management controller 170, the NIC(s) 113, the TPM 188, and the processors 110 may communicate via the PCH 118, according to example implementations; and the storage device(s) 130 may / may be connected to the processors 110 via the PCH 118. As shown in FIG. 1, the storage device(s) 130 may store an operating system image 132 (corresponding to an operating system), an operating system boot loader code 134 (corresponding to an operating system boot loader), a process monitoring code 135 (corresponding to the process monitor 106), and an application code 136 (corresponding to the applications 111), in accordance with some implementations. In the example implementation of FIG. 1, a NIC 113 couples the PCH 118 to the network fabric 190 to enable the baseboard management controller 170 to communicate with a management network, including the remote management server 194 illustrated. In accordance with further example implementations, the baseboard management controller 170 may include a network interface controller that communicates with the network fabric 190.In general, network fabric 190 may be connected to one or more types of communication networks, such as (as examples) fibre channel networks, iSC networks, ATA over Ethernet (AoE) networks, HyperSC networks, Gen-Z fabrics, dedicated management networks, local area networks (LANs), wide area networks (WANs), global networks (e.g., the Internet), wireless networks, or any combination thereof.The TPM 188 is an example of a security component of the computing platform 100 that includes secure memory that can be used to store secure information (e.g., the secure boot variables, hashes to verify the integrity measurement, keys, etc.) for the computing platform 100. Examples of TPMs that may be used are commercially available from suppliers such as Infineon Technologies, Nuvoton, and STMicroelectronics. According to further embodiments, the computing platform 100 may also include a security component other than a TPM. Moreover, in further implementations, the TPM may be a virtual TPM (vTP). Depending on the particular implementation, the TPM may be implemented in firmware, software, or hardware. In accordance with other implementations, computing platform 100 may not include a TPM.According to example implementations, the baseboard management controller 170 may be an embedded system mounted on a motherboard of the platform 100. Depending on the particular implementation, the baseboard management controller 170 may include one or more semiconductor packages (or "chips") and one or more semiconductor chips. In accordance with further implementations, the baseboard management controller 170 may be an expansion card that is connected to a slot on the motherboard. In other embodiments, the baseboard management controller 170 may not contain any motherboard-mounted semiconductor packages or may be located on an expansion card. Regardless of its particular form or implementation, the baseboard management controller 170 may generally include one or more embedded general purpose processing cores 154 (e.g., CPU processing cores) that may execute machine-executable instructions to provide an alarm monitor 172 to the baseboard management controller 170. In general, as further described herein, the alarm monitor 172 may perform various functions associated with the process monitoring described herein, such as listening to the heartbeat 230 (FIG. 2 ); authenticating messages corresponding to heartbeat indicators or pings of the heartbeat 230; responsive to a detected disruption of the heartbeat 230; taking corrective or remedial action in response to the failure to detect the heartbeat 230; receiving warnings 240 from the process monitor 106; taking corrective or remedial action in response to the warnings 240; sending warnings 250 to a remote management server 194; receiving reporting messages 244 from the process monitor 106; sending reporting messages 260 to a remote management server 194; and so forth.A "baseboard management controller" is a specialized service processor that monitors the physical state of a server or other hardware using sensors and communicates with a management system via a management network. The baseboard management controller 170 may communicate with applications executing at the operating system level via an IOCTL interface driver, an REST application program interface (API), or other system software proxy that facilitates communication between the baseboard management controller 170 and applications. The baseboard management controller 170 may access hardware devices located in a server housing, including system memory, at the hardware level. The baseboard management controller 170 may be capable of directly modifying the hardware devices. The baseboard management controller 170 may operate independently of the operating system of the computing platform 100. The baseboard management controller 170 may be located on the server's motherboard or motherboard or other device to be monitored. The fact that a baseboard management controller is mounted on a motherboard of the managed server / hardware or otherwise connected or attached to the managed server / hardware does not prevent the baseboard management controller from being considered "separate" from the server / hardware. As used herein, a baseboard management controller has management functions for computer device subsystems and is separate from a processing resource executing a computer device operating system. Thus, the baseboard management controller 170 is separate from the processor(s) 110 executing the high-level operating system for the computing platform 100.In accordance with example implementations, the baseboard management controller 170 may have a management level and a separate security level. Via its management level, the baseboard management controller 170 may provide various management services to the computing platform 100. In addition to the actions described herein relating to monitoring the integrity of the processes 108 and the operating system kernel 104, the baseboard management controller 170 may provide various other management services, such as monitoring sensors (e.g., temperature sensors, fan speed sensors), monitoring operating system status, monitoring power status, logging events on the computing platform 100, providing remote management functions to the computing platform 100, and so forth. Via its security level, the baseboard management controller 170 provides security functions or services to the computing platform 100, e.g., key management (e.g., functions related to storing and loading cryptographic keys), firmware image validation, cryptographic identity retrieval of the platform, loading measurement hashes, retrieval of measurement hashes, and so forth, in accordance with example implementations.As described further below, in accordance with some implementations, the baseboard management controller 170 may store, as part of its security level, a seed or key that the baseboard management controller 170 may use to authenticate messages corresponding to the pings of the heartbeat 230 (FIG. 2 ). Authentication of the heartbeat messages is a security measure that prevents a powerful opponent from counterfeit the heartbeat messages. As described further below, the baseboard management controller 170 may transmit the seed or key to the process monitor 106 as part of powering up or powering up the computing platform 100; and the process monitor 106 may use the seed or key to generate messages corresponding to the pings of the heartbeat 230.The security level of the baseboard management controller 170 is formed by a secure enclave of the controller 170, which includes a security processor 173 (e.g., a CPU processing core), a non-volatile memory 156 (e.g., a memory for storing cryptographic keys, a cryptographic identity, seeds, etc.), a volatile memory 155 (e.g., a memory for storing firmware loaded into the volatile memory 155 and executed by the security processor 173); a secure bridge (not shown) to control access to the secure enclave and control outgoing communication from the secure enclave; cryptographic-related peripheral devices (not shown) such as cryptographic accelerators, a random number generator, tampering detection circuitry, etc.; and a hardware or "silicon" root-of-trust (RoT) engine, herein called "SRoT engine 174". In accordance with example implementations, the SRoT engine 174 validates the firmware to be executed by the security processor 173 before the SRoT engine 174 loads the firmware into the secure enclave volatile memory 155 and allows the security processor 173 to execute the firmware.As mentioned above, the baseboard management controller 170 includes general purpose processing cores 154. The processing core(s) 154 execute(s) firmware instructions from a non-volatile memory 164 to provide various management services to the controller 170 as part of the management level of the controller. As part of the management services 54, the general purpose processing core / s 1 may execute firmware instructions to provide the alarm monitor 172.In accordance with example implementations, the baseboard management controller 170 may validate firmware 176, which may correspond to machine-executable instructions and data, for example, executed by the computing platform 100 to provide a variety of different functions to the platform 100. For example, the firmware 176 may include a boot code image executed by a particular boot processor 110 to boot the computing platform 100; machine executable instructions corresponding to a management stack executed by the baseboard management controller 170 to provide a plurality of different management services to the computing platform 100; machine executable instructions executed by the security processor 173 to provide different security services to the computing platform 100; and so forth. According to example implementations, the firmware 176 may be stored in the non-volatile memory 184, and the baseboard management controller 170 may communicate with the non-volatile memory 184 via a bus 183 (e.g., a serial peripheral interface (SPI) bus). In accordance with further example implementations, the baseboard management controller 170 may not validate the firmware 176, and the validation may be by a separate security semiconductor package disposed between, for example, the baseboard management controller 170 and the non-volatile memory 184.In example implementations where the baseboard management controller 170 validates the firmware 176, the baseboard management controller 170 generally resets the general purpose processing core(s) 154 of the controller 170 in response to a power-on reset of the computing platform 100. After performing initial root-of-trust security checks, as well as other checks (e.g., hardware fault checks), the baseboard management controller 170 enables the general purpose processing core(s) 154 from reset.According to example implementations, the baseboard management controller 170 stores a fixed fingerprint that is used by the SRoT engine 174 to validate machine-executable instructions. More specifically, in accordance with example implementations, SRoT engine 174 validates an initial portion of the firmware (originally stored 176 in non-volatile memory 184) and then loads it into memory 155 in response to the power-on reset, so that this portion of firmware can now be trusted. The security processor 173 may boot and execute the loaded firmware instructions. By executing the firmware instructions, the security processor 173 may then validate another portion of the firmware176 corresponding to a portion of the baseboard management controller's management firmware stack; and after this validation, the security processor 173 may then load that portion of the firmware 176 into the memory 155 before the memory 155 is disabled to prevent further changes. The security processor 173 may also validate another portion of the firmware176 corresponding to the boot image, in accordance with example implementations; and after validation, the boot image may be loaded into the system memory 114 such that a boot processor 110 may execute instructions of the image to launch the computing platform 100. Booting the computing platform 100 may be secure booting (e.g., secure booting via the unified extensible firmware interface (UEFI)) or non-secure booting, depending on the implementation. The boot operation ends with the loading of the operating system boot loader code 134 and the transfer of control over the computing platform 100 to the operating system.Returning to FIG. 2, in accordance with example implementations, scanning kernel space data structures 119 by process monitor 106 detects injection of shared library object code at runtime. This shared library object code injection may be the result of using dynamically loaded functions to load malicious shared library objects, as well as injecting shared library code during the load time when an attacker uses environmental variables (e.g., an environmental variable LD_PRELOAD) and system files (e.g., " / etc / ld.so.preload") to load malicious shared objects. In general, memory sensing by the process monitor 106 may also identify a surgical process code injection in which an attacker injects code into the process 108 without disturbing the portion of the process memory that relates to sending the heart beat 210.In accordance with example implementations, the process monitor 106 passes through kernel space data structures 119 corresponding to the monitored process 108 to search for suspect shared library objects. A shared library object may be, for example, a memory-mapped shared library object, a deleted shared library object, a shared library object external to traditional operating system directories, a shared object with storage directories, and so forth. In this context, a "suspect" shared library object refers to a shared library object having an associated file path that, in combination with the type or category of the shared library object, indicates that the object is associated with malware.More specifically, referring to FIG. 3 in conjunction with FIG. 2, in accordance with example implementations, the process monitor 106 may perform a technique to scan300 the kernel space data structure(s) 119 for a particular monitored user space process 108 for suspect shared library objects. According to block 3 04, the process monitor 106 searches the data structure(s) 119 and identifies suspect shared library objects based on the file paths of the shared library objects. For example, the shared library objects may be located in a temporary directory, a user home directory, etc. The process monitor 106 may add the identified suspect shared library object candidates to a candidate list according to block 3 08.The process monitor 106 may then be configured as in blocks 312- 3 of 324FIG. As shown in FIG. 3, an iterative process may begin to evaluate each suspect library common object. As part of this iterative process, the process monitor 106 determines whether the suspect library common object is included in a reference list file, as per decision block3 12. In accordance with example implementations, the reference list file includes approved library common objects and their corresponding full file paths. Depending on the particular implementation, the reference list file may be populated with information provided by experts, references provided by information collected during process monitoring, and so forth. Furthermore, entries in the reference list file may be removed and added as appropriate if information about malware agents and their corresponding behavior becomes known over time. In accordance with some implementations, one or more applications 111 (FIG. 1 ) may execute on a separate security computer system; shared library objects and corresponding file paths may be observed on the separate security computer system; and a reference list file may then be filled with the observed shared library objects and corresponding file paths for use on another computer platform, such as computer platform 100. If, as indicated in decision block 3, 16, the process monitor 106 determines that the corresponding shared library object in the reference list file has the same full file path as the suspect shared library object, then as indicated in block 320, the process monitor 106 removes the suspect shared library object from the candidate list. If there are more suspect library common objects in the candidate list to be evaluated, control returns to decision block 3 12 to perform another iteration according to decision block 3 24.After the suspect shared library objects have been evaluated, the process monitor 106 determines whether suspect shared library objects remain in the candidate list according to decision block 3. If so, the process monitor sends a warning message (i.e., warning 240) to the baseboard management controller 170 according to block 332. For example, in accordance with example implementations, the alert message may identify the corresponding monitored user space process 108, the shared library objects in question, the file paths of those shared library objects, time stamps corresponding to the times at which the discoveries were made, and so forth.In accordance with example implementations, the process monitor 106 may scan the kernel space data structures 119 to identify all executable COW pages. In general, executable pages of shared library objects are invariable, i.e., they have a read-only state and are shared by the kernel 104 for all processes. Thus, according to the example implementations, COW execution pages are used to identify a behavior that matches malware because an unmanaged process should not have a shared library object with a COW execution page, i.e., a page with private changes. Injection of code with ptrace and other tools triggers COW because the kernel of operating system 104 ensures that changes for other processes mapping the same shared library object file are not visible and are not written back to the underlying file. The approach used by the process monitor 106 detects the code injection without measurements and does not rely on the actual content of user memory pages, which may be encrypted, for example.To prevent malware from becoming persistent, the operating system may mark all executable pages of a native binary file supported by a file as "private" and read-only. In this case, "private" means that updates for other processes mapping the same file are not visible and are not written back to the underlying file. This means that inserting code into the executable pages of a file-based binary effectively triggers a COW. Thus, in accordance with example implementations, memory sensing by process monitor 106 detects code injected other than via shared library objects.Referring to FIG. 4 in conjunction with FIG. 2, in accordance with example implementations, the process monitor 106 may perform a technique 400 to scan the kernel data structure(s) 119 for an associated user space monitored process 108 to identify executable COW pages and generate an alarm in response thereto. More specifically, process monitor 106 may traverse data structures 119 (block 4 04) according to Technique 4 00 and search for COW execution pages. For example, for a Linux operating system in which data structures 119 are VMAs, process monitor 106 may identify a COW executable page if a VMA for monitored user space process 108 has the following flags for the page: an R flag set to "1" indicating that the page can only be read; a D flag set to "1" indicating that the page is dirty; and an E flag set to "1" indicating that the page is executable. If any COWausführbar pages are found according to decision block 4 08, the process monitor 106 sends a warning message (i.e., warning message 240) to the baseboard management controllers 170 according to block In 412. Consistent with example implementations, this message may include an identifier for the process 108, information for the identified COW executable(s) page(s) found(s), time stamps corresponding to times of discoveries, etc.FIG. 7 shows an example method 700 that may be triggered, e.g., periodically, to cause the process monitor 106 to check whether a timeout of the heartbeat 210 has occurred for a particular monitored user process 108. Thus, the process monitor 106 determines whether a heartbeat timeout has occurred, according to decision block 704; and if so, the process monitor 106 sends a warning message to the baseboard management controller 170, according to block 708. For example, the alert 240 may correspond to a message including information identifying the particular monitored user space process 108 for which the heartbeat timeout occurred, a timestamp indicating the time the timeout was detected, etc. It should be appreciated that, as described herein, the technique 700 may be optional for a particular process 108.As already mentioned, it is possible for a powerful attacker to falsify or mimic the heartbeat messages 230 supplied by the process monitoring 106. Thus, in accordance with example implementations, actions are taken that allow the baseboard management controller 170 to authenticate messages that appear as "heartbeat messages", i.e., messages corresponding to heartbeat indications or pings of the heartbeat 230. Depending on the implementation, one of many types of authentication methods may be used.For example, in some implementations, the process monitor 106 may generate a heartbeat 230 by generating a message that includes a header indicating that the message is a "heartbeat message" and also includes a count that may be used to authenticate the messages as actually a heartbeat message. The count value may be generated, for example, by a monotonically increasing counter that increases by a predetermined increment value. The baseboard management controller 170 may also include a monotonically increasing counter that increases by the same predetermined increment value. The process monitor 106 and the baseboard management controller 170 may synchronize the initial counts stored by their counters so that the two counters operate in lockstep. In this manner, to send a particular heartbeat message to the base board management controller 170, the process monitor 106 may, for example, increase its counter by the predetermined increment value to derive a count value, and then include the count value in the heartbeat message. The heartbeat message may also include, for example, header information indicating that the message is a heartbeat message. The baseboard management controller 170 may then receive (via the alarm monitor 172 of FIG. 1 ) the heartbeat message and increment the counter of the baseboard management controller 170 by the predefined increment value to derive a count value. The base board management controller 170 may then authenticate the message by comparing this count to the count of the received message.To achieve a higher level of security, the process monitor 106 and the baseboard management controller 170 may include pseudo random generators, each of which generates an output based on the same polynomial function, in accordance with other implementations. As further described herein, an initial seed for the pseudo random generator may be provided as input to both pseudo random generators upon booting of the computing platform 100. With the seed, for the first heartbeat message, the corresponding outputs of both polynomial generators are equal. Therefore, the baseboard management controller 170 may then receive (via the alert monitor 172 of FIG. 1 ) the first heartbeat message and compare a number embedded in the message to the output of its pseudo random generator to authenticate the message. The next output of the pseudo random generator may be generated, for example, by using the current output as an input. Regardless of how the inputs to the pseudo random generators are generated, both pseudo random generators generally operate in the same step, so that the outputs of the pseudo random generators can be used to send and authenticate heartbeat messages.In accordance with further implementations, an even higher level of security for the heartbeat messages may include the use of a message authentication code (MAC). Generally, the MAC is a tag that can be inserted into a message and is generated based on a content of the message and a key. As described further below, the key may be provided to both the process monitor 106 and the baseboard management controller 170 at start-up of the computing platform 100, such that the MAC of an accepted heartbeat message may be used by the baseboard management controller 170 to authenticate the message.FIG. 5 shows an example of a boot technique 500 illustrating how a seed or key for the heartbeat message may be distributed to the process monitor 106 as part of the boot of the computing platform 100. In this example, the baseboard management controller 170 already has the heartbeat seed or key, as the baseboard management controller 170 stores the heartbeat seed or key in its memory (e.g., stores data representing the seed or key in the non-volatile memory 156 of the baseboard management controller 170).As can be seen from FIG. 5 in conjunction with FIG. 1, as part of this boot technique 500, the baseboard management controller 170 may store the heartbeat key or heartbeat seed in a system management basic input / output operating system (SMBIOS) table (block 508). In general, the SM BIOS table may be read by the operating system kernel 104 after the kernel 104 is loaded and initialized. The method 500 includes loading (block 512) the operating system boot loader code 134; and thus, the operating system boot loader loads the operating system according to block 516. As shown in block 520, as part of operating system initialization, the process monitor 106 reads the heartbeat key or heart beat seed from the SMBIOS table (block 520) and deletes the key / seed. The operating system then has control over the computing platform 100 as illustrated in block 524.When the heartbeat key is used to authenticate the heartbeat message, the operating system kernel 104 may read the heartbeat key into the kernel key ring as part of operating system initialization. Moreover, according to further implementations, the operating system boot loader may load the heartbeat key indirectly into the kernel key ring.In accordance with further implementations, the heartbeat seed or heartbeat key may be injected into the process monitor 106 as a kernel parameter at boot time. Moreover, in these implementations, the heartbeat seed or heartbeat key may be provided to the baseboard management controller 170 via an API of the baseboard management controller 170 to add the seed / key.Referring to FIG. 6 in conjunction with FIG. 1 1, in accordance with some implementations, the process monitor 106 may use a technique 600 for sending a message corresponding to the heartbeat 230 (i.e., for sending a ping of the heartbeat 230). According to block 604, the process monitor 106 constructs a message corresponding to the heartbeat 230, including generating a MAC for the message based on a heartbeat key. Then, in accordance with block 608 the process monitor 106 sends the message via the baseboard management controller 170. It should be appreciated that method 600 may be triggered by an interrupt according to a periodic schedule, in accordance with example implementations. In accordance with some implementations, the process monitor 106 may communicate the message to the baseboard management controller 170 over a PCIe link.Generally illustrated in FIG. 8 is a technique 800 that can be used by the alarm monitor 172 (FIG. 1 ) of the motherboard management controller 170 to process a message whose header indicates that the message is a heartbeat message. Referring to FIG. 8 in conjunction with FIG. 1 1, in accordance with the technique 800, after the decision block 804, the baseboard management controller 170 determines whether the header indicates that the potential heartbeat message originated from the process monitor 106, and if not, the baseboard management controller 170 processes the non-heartbeat message according to block 810. Otherwise, if the header indicates that the message is a heartbeat message, the baseboard management controller 170 determines whether the message has been authenticated, as indicated at decision block 814, and if not, reports the message as indicated at block 818. For example, the baseboard management controller 170 may determine whether the candidate heartbeat message is authenticated based on a MAC included in the message and a cryptographic key. If the message is authenticated, the baseboard management controller 170 logs (block 822) the heartbeat 230, i.e., the baseboard management controller 170 logs the heartbeat ping corresponding to the authenticated heartbeat message.FIG. 9 illustrates a technique 900 that may be used by the alarm monitor 172 (FIG. 1 ) of the motherboard management controller 170 to periodically (or according to another schedule) check whether the heartbeat 230 is time out. Referring to FIG. in 9 in conjunction with FIG. 1, the motherboard management controller 170 determines (decision block 910) whether there is a heartbeat 230 timeout or a warning message from the process monitor 106. If so, the baseboard management controller 170 sends a warning message to the remote management server 194, as per block 914, and may perform one or more additional remedial actions, such as initiating (block 918) a power-on reset of the computing platform 100. In accordance with further example implementations, the baseboard management controller 170 may take other and / or other remedial action, such as disabling a subsequent boot of the computing platform 100 until authorized by corresponding credentials, etc.Other variants are also conceivable, which fall within the scope of the appended claims. For example, in accordance with other implementations, the process monitor 106 may send the heartbeat 230 (FIG. 2 ) and all alerts 240 to a hardware controller other than a baseboard management controller, e.g., a graphics processing unit (GPU), a network processor, or a microcontroller that does not provide management services to the computing platform 100. In accordance with further implementations, the key or seed for the heart beat 230 may be stored in a secure memory other than the memory of the baseboard management controller 170. For example, the key or seed may be stored in a memory of the TPM 188 (FIG. 1 ). In accordance with further implementations, the baseboard management controller 170 may not include a hardware trust base and may not validate the firmware 176. In accordance with other implementations, scanning kernel space memory by process monitor 106 may also search for information other than that about shared library objects and executable COW pages.Moreover, in accordance with other implementations, scanning kernel memory by process monitor 106 may not include scanning for suspect shared library objects and scanning for executable COW pages; and aspects of the scanning may be selected as part of registering a process for the scanning in accordance with example implementations.Although reference is made to the Linux operating system by way of example herein, in accordance with other implementations, the computing platform 100 may have a different operating system (e.g., a Windows NT operating system) than a Linux operating system, and for these implementations, the computing platform 100 may have a suitable operating system extension corresponding to the process monitor 106.User space processes that are not related to safety related processes may be monitored and may therefore be monitored user space processes 108 monitored by the process monitor 106, according to example implementations. The monitored user space processes 108 may include, for example, processes related to container instantiation, container provisioning, etc. In accordance with some implementations, the baseboard management controller 170 may obtain a policy for the computing platform 100; and a monitoring interface for the baseboard management controller 170 may allow the identities of the monitored user space processes 108 to be remotely observed, whereby the list of the monitored user space processes 108 may be updated over time and allows a customer to verify whether a particular process is being monitored. Moreover, in accordance with some implementations, the baseboard management controller 170 may provide an interface for monitoring messages and reports that may be checked via, for example, a Web Graphical User Interface (GUI), a Redfish API, a Simple Network Management Protocol (SNMP), etc.As shown in FIG. 10, a method 100 according to example implementations includes an operating system agent of a computer system monitoring a process (block 1004) to determine whether the integrity of the process has been compromised. Monitoring includes scanning a data structure by the operating system agent. The process is performed in a user space and the data structure is part of the kernel space of the operating system. The method 1000 includes a hardware controller of the computer system waiting for a heartbeat (block 1008) generated by the operating system agent. In addition, the method 1000 includes the hardware controller taking a corrective action (block 1012) when the hardware controller detects an interrupt to the heartbeat or when the operating system agent provides a safety alert to the hardware controller for the process.Referring to FIG. 11, a non-transitory storage medium 1100 stores machine readable instructions 1104 that, when executed by a machine, cause the machine to scan kernel storage space associated with a process to detect a storage state corresponding to the process compromised by a security attack. The instructions 1104, when executed by the machine, further cause the machine to send a first heartbeat to a hardware controller; and in response to detecting the memory state, transmit a warning to the hardware controller to cause the hardware controller to take corrective actions.As shown in FIG. 12, a computing platform 1200 includes a base board management controller 1204, a hardware processor 1208, and a memory 1212 storing instructions 1216. The baseboard management controller 1204 is to monitor a first heartbeat provided by a loadable operating system kernel extension and, in response to a detected interruption of the first heartbeat or a transmission of a security message from the operating system kernel module, take an action to remedy the security message. The instructions 1216, when executed by the hardware processor 1208, cause the hardware processor 1208 to wait for a second heartbeat generated by the process; scan a kernel memory space associated with the process to detect a memory state corresponding to a compromised integrity of the process; and send the first heartbeat to the baseboard management controller 1204. The instructions 1216 cause the hardware processor 1208, when executed by the hardware processor 1208, to transmit the security message to the baseboard management controller 1204 in response to at least one of the second heartbeat detection error or memory state detection.According to example implementations, an application registers the process with the operating system agent, and the operating system agent begins monitoring the process in response to the registration. A particular advantage is that applications can select the processes to be monitored.In accordance with example implementations, the registration includes the application that enables the operating system agent to heartbeat monitor the process. A particular advantage is that scanning the memory without heartbeat monitoring can be used for legacy applications that do not support the provision of a heartbeat.According to example implementations, taking remedial action by the hardware controller includes at least one of: the hardware controller initiates a restart to the computer system, or the hardware controller transmits a safety alert to a management server. A particular advantage is that remedial action can be taken in real-time or near real-time in response to detected malware activities.In accordance with example implementations, the hardware controller listens to the heartbeat by receiving a message from the operating system agent and determining whether the message represents the heartbeat based on a predetermined seed or key associated with the heartbeat. A particular advantage is that attackers can be prevented from counterfeit the heart beat.According to embodiments, in a pre-operating system environment of the computer system, the hardware controller stores the predetermined seed or key in a system management basic input output system (SMBIOS) table; the operating system agent reads the predetermined seed or key from the SMBIOS table; and the predetermined seed or key is deleted from the SMBIOS table. A particular advantage is that there is some degree of security for communicating the predetermined key or seed to the operating system agent.In accordance with example implementations, in response to an initialization of an operating system of the computer system, the retrieved seed or key is injected into a key ring of the operating system. A particular advantage is that a higher level of security is used to protect the seed or key from access by an attacker.According to example implementations, an application may communicate the predetermined key or seed to the operating system agent as kernel parameters; and the predetermined seed or key may be communicated to the hardware controller via an application programming interface (API). A particular advantage is that boot firmware does not need to be changed to provide the seed or key.In accordance with example implementations, in response to registering the process with a heartbeat monitoring option, a heartbeat generated by the process is monitored. Upon detection of this heartbeat, a warning is transmitted to the hardware controller to cause it to take corrective action. A particular advantage is that the heart beat offers a further possibility of monitoring whether the integrity of a process has been compromised.Although the present disclosure has been described with respect to a limited number of implementations, those skilled in the art having the advantages of this disclosure will recognize numerous modifications and variations thereof. It is intended that the appended claims cover all such modifications and variations.

Claims

A method (1000) comprising: an operating system agent (106) of a computer system monitoring a process (108) to detect whether an integrity of the process (108) has been compromised, wherein the monitoring comprises scanning a data structure (119) by the operating system agent (106), the process (108) is executed in a user space (115), the data structure (119) is part of an operating system kernel space (117), and wherein the operating system agent generates a heartbeat (230), and the heartbeat (230) comprises a sequence of indications following a schedule to represent that the operating system agent is operating in an acceptable state; a hardware controller of the computer system waiting for the heartbeat (230), the hardware controller being separate from the operating system agent (106); the hardware controller taking corrective action in response to at least one of the following: the hardware controller detecting an interruption of the heartbeat (230), or the operating system agent providing a safety warning to the process (108) to the hardware controller; and an application (111) registering the process (108) with the operating system agent, the operating system agent beginning to monitor the process (108) in response to the registration.The method (1000) of claim 1, wherein the registering comprises the application (111) enabling heartbeat monitoring of the process (108) by the operating system agent (106).The method (1000) of claim 1, wherein the hardware controller that takes the corrective action comprises at least one of the following steps: the hardware controller causes the computer system to restart, or the hardware controller transmits a security alert to a management server (194).The method (1000) of claim 1, wherein the hardware controller listening to the heartbeat (230) comprises the hardware controller: receiving a message from the operating system agent (106); and determining whether the message represents the heartbeat (230) based on a predetermined seed or key associated with the heartbeat (230).The method (1000) of claim 4, further comprising: in a pre-operating system environment) of the computer system, storing the predetermined seed or key in a system management basic input output system (SMBIOS) table, by the hardware controller; reading the predetermined seed or key from the SMBIOS table by the operating system agent (106); and deleting the predetermined seed or key from the SMBIOS table.The method (1000) of claim 4, further comprising: responsive to initialization of an operating system of the computer system, injecting the retrieved seed or key into a key ring of the operating system.The method (1000) of claim 4, further comprising: an application (111) that transmits the predetermined key or seed as a kernel parameter to the operating system agent (106); and transmitting the predetermined seed or key to the hardware controller using an application programming interface, API (109).A non-transitory storage medium (1100) storing machine readable instructions that, when executed by a machine, cause the machine to: cause, responsive to an application (111) registering a process with an operating system agent (106), the operating system agent (106) to begin monitoring the process (108) responsive to the registration to detect whether an integrity of the process (108) has been compromised, the monitoring comprising scanning a kernel storage space associated with the process to detect a storage state corresponding to the process compromised by a security attack; causing the operating system agent to send a first heartbeat (230) to a hardware controller, the hardware controller being separate from the operating system agent (106), and wherein the heartbeat (230) comprises a sequence of indications following a schedule to represent the operating system agent operating in an acceptable state in response to detecting the memory state, causing a warning to be sent to the hardware controller to cause the hardware controller to take corrective action.The storage medium (1100) of claim 8, wherein the instructions, when executed by the machine, further cause the machine to: responsive to a registration of the process (108) with a heartbeat monitoring option, wait for a second heartbeat (210) generated by the process; and responsive to an error in the detection of the second heartbeat (210), transmit a warning to the hardware controller to cause the hardware controller to take corrective actions.The storage medium (1100) of claim 8, wherein the instructions, when executed by the machine, further cause the machine to: identify the storage state based on the identification of a shared library object and a location of the shared library object.The storage medium (1100) of claim 8, wherein the instructions, when executed by the machine, further cause the machine to identify the storage state based on the identification of an executable memory page associated with the process (108) being a copy-on-write page.The storage medium (1100) of claim 11, wherein the instructions, when executed by the machine, further cause the machine to identify the storage state based on at least one status flag associated with the storage page.The storage medium (1100) of claim 8, wherein the instructions, when executed by the machine, further cause the machine to: identify a particular shared library object associated with the process (108) and a path associated with the particular shared library object; compare the given shared library object to a reference list of a plurality of authorized shared library objects and file paths associated with the plurality of authorized shared library objects; and determine whether the storage state corresponding to the process compromised by a security attack has been detected based on the comparison.A computer platform (100) comprising: a baseboard management controller (170) to: monitor a first heartbeat (230) provided by a loadable operating system kernel extension, the first heartbeat (230) comprising a first sequence of alerts following a first schedule to represent that the kernel extension is operating in an acceptable state; and in response to a detected interrupt of the first sequence of alerts or a transmission of a security alert from the operating system kernel extension, initiate an action to remedy the security alert; a hardware processor other than the baseboard management controller (170); and a memory for storing instructions corresponding to the operating system kernel extension, the instructions, when executed by the hardware processor, cause the hardware processor to: wait for a second heartbeat (210) of the process (108), the second heartbeat (210) comprising a second sequence of indications following a second schedule to represent that the process is operating in an acceptable state; causing, in response to an application (111) registering the process (108) with an operating system agent (106), the operating system agent to begin monitoring the process (108) in response to the registration to detect whether an integrity of the process has been compromised, wherein the monitoring comprises scanning kernel memory space associated with the process to detect a memory state corresponding to a compromised integrity of the process; sending the first heartbeat (230) to the baseboard management controller (170); and in response to at least one of a detected failure of the second sequence of indications or the detection of the memory state, sending the safety warning to the baseboard management controller (170).The computing platform (100) of claim 14, wherein the instructions, when executed by the hardware processor, further cause the hardware processor to use the memory scan to determine whether the process has undergone at least one of process fetch or code injection.The computing platform (100) of claim 14, wherein the process (108) comprises one of a plurality of processes, and the instructions, when executed by the hardware processor, further cause the hardware processor to: listen to a plurality of heartbeats (210) generated by the plurality of processes (108); and in response to a detected interruption of a particular heartbeat (210) of the plurality of heartbeats (210), transmit a safety alert to the baseboard management controller (170).The computing platform (100) of claim 14, wherein: the instructions, when executed by the hardware processor, further cause the hardware processor to: determine a plurality of shared library objects associated with the process (108), and determine, for each shared library object of the plurality of shared library objects, a file path of the shared library object; transmit the plurality of shared library objects and the file paths to the baseboard management controller (170); and wherein the baseboard management controller (170) is configured to transmit the plurality of shared library objects and the file paths to the baseboard management controller (170) to a remote management server.The computing platform (100) of claim 14, wherein the instructions, when executed by the hardware processor, further cause the hardware processor to generate messages corresponding to the first heartbeat (230) based on a predetermined seed or key shared with the baseboard management controller (170).The computing platform (100) of claim 14, wherein the instructions, when executed by the hardware processor, further cause the hardware processor to identify the storage state based on at least one of: a determination of an executable memory page associated with the process (108) as a copy-on-write page; or an identification of a shared library object associated with the process and a file path for the shared library object.The method (1000) of claim 1, wherein a failure of the sequence of indications corresponds to the situation that the operating system agent (106) is not operating in an acceptable state.

Images