Patent Description:
As the value and use of information continue to increase, individuals and businesses seek additional ways to process and store it. One option is an Information Handling System (IHS). An IHS generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes. Because technology and information handling needs and components may vary between different applications, IHSs may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. Variations in IHSs allow for IHSs to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, global communications, etc. In addition, IHSs may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.

Computer security, also known as cybersecurity, refers to the protection of IHSs from theft or damage to hardware, software, and/or electronic data. In this context, a threat is a possible danger that may exploit an IHS's vulnerability to breach its security and therefore cause harm. Nowadays, many security threats to both consumer and commercial IHSs require the adversary to modify the configuration of the IHS at the Basic Input/Output System (BIOS) or Unified Extensible Firmware Interface (UEFI) level.

<CIT> discloses a monitoring method and electronic equipment, and the method comprises the steps: receiving a loading instruction for a to-be-loaded firmware interface driver; wherein the loading instruction is used for indicating to load the firmware interface driver; and if the firmware interface driver is an untrusted firmware interface driver, loading the firmware interface driver, and monitoring the firmware interface driver.

<CIT> discloses a firmware-based mechanism for protecting against physical attacks on ROM areas holding Authenticated Variables. A first hash of contents of at least one Authenticated Variable is created by a computing device's UEFI-compliant firmware and stored in a non-volatile storage location. Subsequently a second hash of contents of the at least one Authenticated Variable is created by the firmware and compared by the firmware to the stored hash to identify unauthorized modifications of the at least one Authenticated Variable occurring after the creation of the first hash.

Embodiments of systems and methods for detecting security threats by monitoring chains of configuration changes made to Basic Input/Output System (BIOS) or Unified Extensible Firmware Interface (UEFI) attributes are described. In an embodiment, an IHS may include a processor and a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution by the processor, cause the IHS to: monitor a chain of BIOS/UEFI configuration changes; compare the chain of BIOS/UEFI configuration changes against an Indication of Attack (IoA); and report an alert in response to the chain of BIOS/UEFI configuration changes matching the IoA.

To monitor the chain of BIOS/UEFI configuration changes, the program instruction, upon execution, may cause the IHS to access a non-volatile memory (NVM) where BIOS configuration attributes are stored. In the invention, the chain of BIOS/UEFI configuration changes includes at least a first configuration change having a first timestamp followed by a second configuration change having a second timestamp.

The IoA includes at least a third configuration change followed by a fourth configuration change, and the program instructions, upon execution, cause the IHS to compare: (i) the first configuration change against the third configuration change, and (ii) the second configuration change against the fourth configuration change, and where the chain of BIOS/UEFI configuration changes matches the IoA, in part, when: (i) the first configuration change is equal to the third configuration change, and (ii) the second configuration change is equal to the fourth configuration change.

Additionally, the IoA may include a time interval between the third and fourth configuration changes, and the program instructions, upon execution, may cause the IHS to: compare a time difference between the second timestamp and the first timestamp against the time interval, and where the chain of BIOS/UEFI configuration changes matches the IoA, in part, when the time difference is equal to or less than the time interval.

In some cases, a chain of BIOS/UEFI configuration changes may include: a disabling of BIOS signing, followed by an enabling of BIOS downgrade, followed by a disabling of BIOS auto-recovery, followed by an enabling of BIOS auto-recovery, followed by a disabling of BIOS downgrade, and followed by an enabling of BIOS signing. Additionally, or alternatively, the chain of BIOS/UEFI configuration changes may include: selecting a legacy boot option from a boot list, followed by a disabling of secure boot, followed by an attempt to perform a legacy boot. Additionally, or alternatively, the chain of BIOS/UEFI configuration changes may include: selecting a Secure Digital (SD) boot option, a Thunderbolt boot option, or a Universal Serial Bus (USB) boot option from a boot list, followed by the adding of a boot device to the boot list. Additionally, or alternatively, the chain of BIOS/UEFI configuration changes may include: disabling boot path security, followed by at least one of: disabling a secure boot, or attempting a legacy boot. Additionally, or alternatively, the chain of BIOS/UEFI configuration changes may include: disabling of a BIOS integrity check, followed by an enabling of BIOS downgrade, followed by a firmware update, followed by a disabling of BIOS auto-recovery.

Additionally, or alternatively, the chain of BIOS/UEFI configuration changes may include: bypassing physical presence requirement for a Trusted Platform Module (TPM) clearing operation, followed by an a TPM clearing operation. Additionally, or alternatively, the chain of BIOS/UEFI configuration changes may include: allowing a TPM clearing operation, followed by at least one of: allowing a local TPM activation, or allowing a remote TPM activation operation. Additionally, or alternatively, the chain of BIOS/UEFI configuration changes may include: enabling an auto-on feature, an auto-on wake-on-LAN feature, an USB-wake feature, or a wake-on-Dock feature, followed by at least one of: (i) allowing a BIOS downgrade followed by a firmware update operation, (ii) allowing a remote TPM activation operation, or (iii) allowing a remote wipe of an internal drive.

Additionally, or alternatively, the chain of BIOS/UEFI configuration changes may include: enabling an auto-on feature, an auto-on wake-on-LAN feature, an USB-wake feature, or a wake-on-Dock feature, followed by at least one of: (i) allowing a BIOS downgrade followed by a firmware update operation, or (ii) allowing a remote TPM activation operation. Additionally, or alternatively, the chain of BIOS/UEFI configuration changes may include: enabling a microphone or camera, followed by an auto-on microphone or camera setting. Additionally, or alternatively, the chain of BIOS/UEFI configuration changes may include: changing a minimum length of an admin password, followed by a disabling of a strong password feature, followed by an admin password change.

Additionally, or alternatively, the chain of BIOS/UEFI configuration changes may include: an admin password change, followed by an enabling of an admin setup lockout feature. Additionally, or alternatively, the chain of BIOS/UEFI configuration changes may include: clearing an intrusion warning, followed by a chassis intrusion reset.

The present invention(s) is/are illustrated by way of example and is/are not limited by the accompanying figures. Elements in the figures are illustrated for simplicity and clarity, and have not necessarily been drawn to scale.

Certain types of security attacks require an adversary to modify the configuration of an Information Handling System (IHS) at the Basic Input/Output System (BIOS) or Unified Extensible Firmware Interface (UEFI) level. In fact, sophisticated attacks may require configuration changes to two or more BIOS/UEFI attributes in a specific order, such that detecting any given BIOS/UEFI attribute change in isolation would not protect the IHS. To address these, and other problems, systems and method described herein provide a threat modeling perspective and platform-level security to define strings or chains of BIOS/UEFI configuration changes that can be used by security software as Indicators of Attack (IoAs).

In some embodiments, a system agent on the IHS may be configured to monitor all changes to BIOS/UEFI configuration attributes, and to compare current and historical configuration changes to pre-defined IoAs to find a match. IoAs may be generated beforehand, for example, by understanding advanced adversaries, platform threat models, and customer security. In some cases, IoAs may be used by third-party security software vendors for inclusion in their own IoA filters.

A reporting module may be configured to alert an administrator, a security operations center, or the IHS's user in situations where a detected chain of BIOS/UEFI configuration changes matches a pre-defined IoA. Detection confidence may be measured and monitored, for example, based upon number of configuration changes that match corresponding changes prescribed by a given IoA. In some implementations, a machine learning module may be employed for creating new IoAs and maintaining existing IoAs.

Accordingly, systems and methods described herein may provide an adversarial and threat-based approach to defining and describing dangerous combinations of BIOS/UEFI configuration changes. These techniques also provide a description and delivery of specific combinations of configuration changes as IoAs, as well as risk and confidence rating of partial or full chains of BIOS/UEFI configurations for IoA detection, reporting, and/or alerting.

For purposes of this disclosure, an IHS may include any instrumentality or aggregate of instrumentalities operable to compute, calculate, determine, classify, process, transmit, receive, retrieve, originate, switch, store, display, communicate, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an IHS may be a personal computer (e.g., desktop or laptop), tablet computer, mobile device (e.g., Personal Digital Assistant (PDA) or smart phone), server (e.g., blade server or rack server), a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price.

An IHS may include Random Access Memory (RAM), one or more processing resources such as a Central Processing Unit (CPU) or hardware or software control logic, Read-Only Memory (ROM), and/or other types of nonvolatile memory. Additional components of an IHS may include one or more disk drives, one or more network ports for communicating with external devices as well as various I/O devices, such as a keyboard, a mouse, touchscreen, and/or a video display. An IHS may also include one or more buses operable to transmit communications between the various hardware components.

<FIG> illustrates an example of components of IHS <NUM> configured to detect security threat by monitoring chains of configuration changes made to BIOS/UEFI attributes, according to some embodiments. As illustrated, IHS <NUM> includes processor <NUM>. In various embodiments, IHS <NUM> may be a single-processor system, or a multi-processor system including two or more processors. Processor <NUM> may include any processor capable of executing program instructions, such as a PENTIUM series processor, or any general-purpose or embedded processors implementing any of a variety of Instruction Set Architectures (ISAs), such as an x86 ISA or a Reduced Instruction Set Computer (RISC) ISA (e.g., POWERPC, ARM, SPARC, MIPS, etc.).

Processor <NUM> may be accessed via northbridge <NUM> chip or integrated circuit (IC) that provides an interface via a QuickPath Interconnect (QPI) or front side bus. Northbridge <NUM> also provides access to system memory <NUM> that may be configured to store program instructions and/or data accessible by processor <NUM>. In various embodiments, system memory <NUM> may be implemented using any suitable memory technology, such as static RAM (SRAM), dynamic RAM (DRAM) or magnetic disks, or any nonvolatile/Flash-type memory, such as a solid-state drive (SSD).

Northbridge <NUM> may also provide access to graphics processor <NUM>. In certain embodiments, graphics processor <NUM> may be part of one or more video or graphics cards installed as components of IHS <NUM>. Graphics processor <NUM> may be coupled to northbridge <NUM> via a graphics bus such as provided by an AGP (Accelerated Graphics Port) bus or a PCIe (Peripheral Component Interconnect Express) bus. In certain embodiments, a graphics processor <NUM> generates display signals and provides them to a monitor or other display device.

IHS <NUM> includes Platform Controller Hub (PCH) or southbridge chipset <NUM>, which may comprise one or more ICs coupled to northbridge <NUM>. In certain embodiments, PCH <NUM> provides processor <NUM> with access to a variety of resources. For instance, PCH <NUM> may be coupled to network interface <NUM>, such as a Network Interface Controller (NIC). In certain embodiments, network interface <NUM> may be coupled to PCH <NUM> via a PCIe bus or the like, and it may support communication via various wired and/or wireless networks. User interface device(s) <NUM> may include a keyboard, trackpad, camera, remote control, or any other device configured to enable a human user to interact with IHS <NUM>.

In various embodiments, SPI Flash <NUM> may be coupled to PCH <NUM> over an SPI bus. SPI Flash <NUM> may be a non-volatile memory (NVM) device capable of being electrically erased and reprogrammed. SPI Flash <NUM> may be divided into various partitions with each partition storing instructions and/or data for a different component of IHS <NUM>.

As shown, a partition of SPI Flash <NUM> may store BIOS/UEFI firmware instructions <NUM>. Upon execution by processor <NUM>, BIOS/UEFI instructions 110provide an abstraction layer that allows the IHS's OS to interface with certain hardware components that are utilized by IHS <NUM>. The Unified Extensible Firmware Interface (UEFI) was designed as a successor to BIOS; many modern IHSs utilize UEFI in addition to or instead of a BIOS. As used herein, BIOS is also intended to encompass UEFI.

Particularly, upon the booting of IHS <NUM>, processor <NUM> may utilize BIOS/UEFI instructions 110to initialize and test hardware components coupled to IHS <NUM> and to load an OS for use by IHS <NUM>. As part of the boot process, BIOS/UEFI instructions 110enable a local or remote user to make configuration changes to a number of IHS components and processes by modifying the values of one or more BIOS/UEFI configuration attributes. These BIOS/UEFI configuration attributes are stored in an NVM and made accessible to the IHS's OS via a suitable configuration interface.

In various embodiments, IHS <NUM> may not include each of the components shown. Additionally, or alternatively, IHS <NUM> may include components other than those that are shown (e.g., additional storage and user interface devices, Super I/O controllers, USB ports, etc.). For example, in some cases, a cryptographic module may be implemented as an FPGA, or as other hardware logic coupled to PCH <NUM>. An example of cryptographic hardware module is the Trusted Platform Module, or TPM. Furthermore, some of the components that are represented as separate components may, in some implementations, be integrated with other components. In various embodiments, all or a portion of the operations performed by the illustrated components may instead be performed by components integrated into processor <NUM> as a system-on-a-chip (SOC) or the like.

<FIG> is a block diagram depicting components of BIOS/UEFI security agent <NUM> configured to detect security threats by monitoring chains of configuration changes made to BIOS/UEFI attributes, according to some embodiments. In this implementation, stack <NUM> includes OS <NUM>, a system software that manages IHS hardware and software resources and provides common services for applications, such as BIOS/UEFI security agent <NUM>.

Particularly, OS <NUM> may schedule tasks for efficient use of IHS <NUM>, and it may also perform cost allocation of processor time, mass storage, printing, and other resources. For hardware operations such as input and output and memory allocation, OS <NUM> behaves as an intermediary between programs and hardware components. Examples of suitable types of OS <NUM> include WINDOWS, MACOS, LINUX, and others.

BIOS/UEFI security agent <NUM> includes program instructions that, upon execution, performs methods for detecting security threats by monitoring chains of configuration changes made to BIOS/UEFI attributes stored in NVM <NUM> (e.g., a partition of SPI Flash <NUM>). In some implementations, BIOS/UEFI security agent <NUM> may further include reporting module <NUM> and machine learning module <NUM>. Reporting module <NUM> includes program instructions that, upon execution, issues alerts, reports, and/or notifications to an administrator or the user about a detected BIOS/UEFI attack. Meanwhile, machine learning module <NUM> includes program instructions that, upon execution, creates, modifies, and maintains IoAs in database <NUM> (e.g., on a Hard Drive).

Each IoA in database <NUM> may include a sequence of two or more BIOS/UEFI configuration changes that, if detected in that particular order, may be indicative of a threat or attack. Each BIOS/UEFI configuration change may be represented by a modification to an attribute (e.g., a binary flag, a selection from a list, etc.) associated with the BIOS/UEFI configuration and stored in NVM <NUM>.

In some cases, NVM <NUM> may store historical values for BIOS/UEFI configuration attributes as they change over time. In other cases, NVM may retain only the currently set value for each BIOS/UEFI configuration attribute, and BIOS/UEFI security agent <NUM> may keep a log of those historical changes upon accessing NVM <NUM> (e.g., through OS <NUM> upon completion of a boot process) in a look-up table (LUT), database, or the like. As BIOS/UEFI security agent <NUM> collects historical configuration changes and other parameters (e.g., same boot, timestamp, etc.) associated with those changes, BIOS/UEFI security agent <NUM> monitors chains of BIOS/UEFI configuration changes being made by a local or remote user, for example.

With respect to parameters collected concurrently with attribute changes, in some cases, a given BIOS/UEFI configuration change may be associated with a "boot number" value that indicates, with respect to a preceding BIOS/UEFI configuration change, whether the given change must be made in the same boot cycle, in a subsequent boot cycle, within a number of boot cycles, or after a number of boot cycles of IHS <NUM>, in order for an attack to match a particular IoA. Additionally, or alternatively, an IoA may include a time interval between a first BIOS/UEFI configuration change and a second BIOS/UEFI configuration change, such that, in order to an attack to match that IoA, the second change must be made within the time interval or after the time interval. Concurrently with the detection of BIOS/UEFI attribute value changes, a timestamp associated with each such change may also be stored and evaluated.

<FIG> is a block diagram of method <NUM> for detecting security threats by monitoring chains of configuration changes made to BIOS/UEFI attributes. In some embodiments, method <NUM> may be performed by BIOS/UEFI security agent <NUM> upon execution by processor <NUM>. Particularly, method <NUM> begins at block <NUM>. At block <NUM>, method <NUM> monitors chains of BIOS/UEFI configuration changes made to IHS <NUM>.

For example, as noted above, BIOS/UEFI security agent <NUM> may retrieve current BIOS/UEFI configuration attribute values from NVM <NUM> through OS <NUM>. Then, BIOS/UEFI security agent <NUM> may store the current values in an LUT of historical attribute values. Each entry in the LUT or database may represent a change to BIOS/UEFI configuration attributes being performed over time. In addition to an indication of the attribute identification and/or the attribute value itself, each node or link in a chain of BIOS/UEFI configuration changes may also include a timestamp and/or a boot number value of when the change was made.

Block <NUM> compares IoAs stored in database <NUM> against historical BIOS/UEFI configuration changes, and block <NUM> determines whether a particular IoA has a match. In some cases, if a chain of BIOS/UEFI configuration changes exactly matches a sequence of configuration changes of a particular IoA, a threat may be detected. In other cases, the match may be identified only if the time intervals and/or number of boots between BIOS/UEFI configuration changes in the chain also match time intervals and/or number of boots between corresponding configuration changes in that particular IoA.

In other cases, rather of relying on exact matches, block <NUM> may detect a threat in response to a chain of configuration changes matching a smaller portion of an entire IoA. For example, if a chain of BIOS/UEFI configuration attribute value changes matches an IoA, but the timestamps associated with those changes are outside the range of the time intervals specified in the IoA, block <NUM> may calculate a detection confidence score (e.g., a %) based upon how many IoA parameters are matched by the chain of BIOS/UEFI configuration changes, with selectable weights for different types of parameters (e.g., attribute changes, time intervals, and/or boot numbers).

Still referring to block <NUM>, assume that a chain of BIOS/UEFI configuration changes includes a first configuration change having a first timestamp followed by a second configuration change having a second timestamp. Meanwhile, an IoA includes a third configuration change followed by a fourth configuration change. As such, block <NUM> may compare: (i) the first configuration change against the third configuration change, and (ii) the second configuration change against the fourth configuration change. In this case, chain of BIOS/UEFI configuration changes matches the IoA when: (i) the first configuration change is equal to the third configuration change, and (ii) the second configuration change is equal to the fourth configuration change.

If the IoA also defines a time interval between the third and fourth configuration changes, block <NUM> may compare a time difference between the second timestamp and the first timestamp against the time interval, and it may determine that the chain of BIOS/UEFI configuration changes matches the IoA when the time difference is equal to or less than the time interval. Alternatively, block <NUM> may determine that the chain of BIOS/UEFI configuration changes matches the IoA when the time difference is equal to or greater than the time interval.

Moreover, if the IoA further define a number of boots between the third and fourth configuration changes, block <NUM> may compare that values against number of boots between the first and second configuration changes, and it may determine that the chain of BIOS/UEFI configuration changes matches the IoA when the number of boots is met (e.g., equal to, smaller than, or greater than).

At block <NUM>, if an IoA has been exactly (or approximately) matched to a chain of BIOS/UEFI configuration changes, method <NUM> may cause reporting module <NUM> to issue an alert or report (e.g., an email, a text message, etc.) with details about the potential threat to a systems administrator or the like. For example, block <NUM> may report the name of the matched IoA or threat and/or a confidence store associate with an approximate match. In some cases, reporting module <NUM> may provide a visual comparison between the detected chain of BIOS/UEFI configuration changes and the matched IoA via a Graphical User Interface (GUI). For threats that originate remotely, the IHS user may also be notified. Moreover, in addition to reporting the detected threat or IoA match, reporting module <NUM> may be configured to issue a command to OS <NUM> to take a selected corrective action, such as logging a local or remote user out of IHS <NUM>, shutting down the IHS, applying stricter security or data protection protocols to an ongoing user session, etc. Method <NUM> ends at block <NUM>; but otherwise it may be repeated continuously or periodically (e.g., upon completion of each boot process).

<FIG> is an example of a chain of configuration changes made to BIOS/UEFI attributes as part of attack scenario <NUM>, according to some embodiments. In attack scenario <NUM>, an attacker performs a downgrade attack on the BIOS, potentially taking advantage of a vulnerability patched in the latest BIOS. Once the attack has been performed and customer damage done, the attacker reverts all changes to attempt to avoid detection.

Particularly, at block <NUM>, a user disables BIOS signing by changing the value of that attribute from enabled to disabled. At block <NUM>, the user enables BIOS downgrade by changing the value of that attribute from disabled to enabled. At block <NUM>, the user disables BIOS AutoRecovery by changing the value of that attribute from enabled to disabled. Then, at block <NUM>, the user launches a BIOS downgrade attack.

At block <NUM>, after the attack is completed, the user enables BIOS AutoRecovery by changing the value of that attribute from disabled to enabled. At block <NUM>, the user disables BIOS downgrade by changing the value of that attribute from enabled to disabled. Finally, at block <NUM>, the user enables BIOS singing by changing the value of that attribute from disabled to enabled.

In various embodiments, BIOS/UEFI security agent <NUM> may capture the events of attack scenario <NUM> as a chain of BIOS/UEFI configuration changes and various associated parameters (e.g., timestamps, number of boots between events, etc.). Then, BIOS/UEFI security agent <NUM> may compare the chain of BIOS/UEFI configuration changes against corresponding changes outlined in one or more IoAs.

In the implementations depicted in <FIG>, various example IoAs have been grouped into the following categories of security threats: boot threats, BIOS update threats, TPM threats, remote threats, authentication threats, and log tampering threats. It should be understood, however, that other categories may be used, and that certain IoAs may outline BIOS/UEFI configuration changes across different categories of security threats. Moreover, longer IoAs may be created (manually or by operation of machine learning module <NUM>) by tying two or more IoAs in any suitable way to match new or developing security threats.

<FIG> are examples of Indicators of Attack (IoAs) representative of boot threats, according to some embodiments. At block <NUM> of IoA <NUM>, a user selects a legacy boot option from a boot list. At block <NUM>, the user disables SecureBoot by changing the value of that attribute from enabled to disabled. Then, at block <NUM>, the user attempts to perform a legacy boot. With respect to IoA <NUM>, at block <NUM> a user selects a Secure Digital (SD) boot option, a Thunderbolt boot option, or a Universal Serial Bus (USB) boot option from a boot list. Then, at block <NUM>, the user adds a boot device to the boot list. As to IoA <NUM>, at block <NUM> a user first disables boot path security by changing the value of that attribute from always to never, or from enabled to disabled. Then, at block <NUM>, the user disables UEFI Secure Boot by changing the value of that attribute from enabled to disabled. Otherwise, at block <NUM>, the user attempts a legacy boot.

<FIG> is an example of an IoA representative of a BIOS update threat, according to some embodiments. At block <NUM> of IoA <NUM>, a user disables a BIOS integrity check feature by changing the value of that attribute from enabled to disabled. At block <NUM>, the user allows BIOS downgrade by changing the value of that attribute from disabled to enabled. At block <NUM>, the user performs a BIOS/UEFI firmware update or recovery operation. Then, at block <NUM>, the user disables BIOS AutoRecovery by changing the value of that attribute from enabled to disabled.

<FIG> are examples of IoAs representative of TPM threats, according to some embodiments. At block <NUM> of IoA <NUM>, a user bypasses a physical present required for manipulating TPM or cryptographic module <NUM> by changing the value of that attribute. Then, a block <NUM>, the user performs a TPM clearing operation. At block <NUM> of IoA <NUM>, a user performs a TPM clearing operation. Then, at block <NUM>, the user performs a local TPM activation. Alternatively, at block <NUM>, a remote TPM activation operation is performed by a remote user (with respect to IHS <NUM>).

<FIG> are examples of IoAs representative of remote threats, according to some embodiments. At block <NUM> of IoA <NUM>, a user enables an auto-on feature, an auto-on wake-on-LAN feature, an USB-wake feature, or a wake-on-Dock feature. At block <NUM>, the user enables BIOS downgrade by changing the value of that attribute from disabled to enabled, and at block <NUM>, the user performs a BIOS/UEFI firmware update or recovery operation. Alternatively, at block <NUM>, a remote user performs a TPM remote activation operation. At block <NUM> of IoA <NUM>, a user enables an auto-on feature, an auto-on wake-on-LAN feature, an USB-wake feature, or a wake-on-Dock feature. Then, at block <NUM>, the user enables remote wiping of the IHSs internal drives. At block <NUM> of IoA <NUM>, a user enables a microphone or camera. Then at <NUM>, the user enables an auto-on microphone or camera setting.

<FIG> are examples of IoAs representative of authentication threats, according to some embodiments. At block <NUM> of IoA <NUM>, a user changes a minimum length of an administrator's password. At block <NUM>, the user disables a strong password feature. Then, at block <NUM>, the user changes the administrator's password. At block <NUM> of IoA <NUM>, a user changes the administrator's password. Then, at block <NUM>, the user enables of an admin setup lockout feature.

<FIG> is an example of an IoA representative of a log tampering threat, according to some embodiments. At block <NUM> of IoA <NUM>, a user clears an intrusion warning or flag (e.g., BIOS log, power log, thermal log, or RAM error log). Then, at block <NUM>, the user resets a chassis intrusion flag.

It should be emphasized that IoAs <NUM>-<NUM> are non-limiting examples, and that many other IoAs may employed. In some cases, machine learning module <NUM> of BIOS/UEFI security module <NUM> apply a suitable machine learning algorithm upon IoA data to determine how configuration changes are actually happening in the field (e.g., to discover relevant time intervals or boot numbers between changes). Additionally, or alternatively, machine learning module <NUM> may be apply a suitable machine learning algorithm upon threat data to automatically discover and curate new IoAs based upon collections of observed threats and attacks. Additionally, or alternatively, machine learning module <NUM> may be apply a suitable machine learning algorithm upon IoA or threat data related to clusters of multiple IHSs to devise IoAs that are relevant to an entire enterprise, or collections of enterprises.

It should be understood that various operations described herein may be implemented in software executed by logic or processing circuitry, hardware, or a combination thereof. The order in which each operation of a given method is performed may be changed, and various operations may be added, reordered, combined, omitted, modified, etc. It is intended that the invention(s) described herein embrace all such modifications and changes and, accordingly, the above description should be regarded in an illustrative rather than a restrictive sense.

Although the invention(s) is/are described herein with reference to specific embodiments, various modifications and changes can be made without departing from the scope of the present invention(s), as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention(s) as defined by the appended claims.

Claim 1:
An Information Handling System, IHS (<NUM>), comprising:
a processor (<NUM>); and
a memory (<NUM>) coupled to the processor (<NUM>), the memory (<NUM>) having program instructions stored thereon that, upon execution by the processor (<NUM>), cause the IHS (<NUM>) to:
monitor a chain of Basic Input/Output System, BIOS, or Unified Extensible Firmware Interface, UEFI, configuration changes comprising at least a first configuration change having a first timestamp followed by a second configuration change having a second timestamp;
compare the chain of BIOS/UEFI configuration changes against an Indication of Attack, IoA, comprising at least a third configuration change followed by a fourth configuration change, by comparing: the first configuration change against the third configuration change, and the second configuration change against the fourth configuration change; and
report an alert in response to the chain of BIOS/UEFI configuration changes matching the IoA when: the first configuration change is equal to the third configuration change, and the second configuration change is equal to the fourth configuration change.