UEFI Variables For Amazon EC2 Instances

By Ashwin Venugopal -

 






Introduction

When you start an instance with the boot mode configured as UEFI, a key-value storage for variables is initialized. This storage can be utilized by both UEFI and the operating system of the instance to keep UEFI variables.

UEFI variables are utilized by the boot loader and the operating system to set up the initial system startup. They enable the operating system to control specific aspects of the boot process, such as the order in which devices boot or handling the keys for UEFI Secure Boot.

UEFI Secure Boot for Amazon EC2 Instances

UEFI Secure Boot enhances the traditional secure boot mechanism of Amazon EC2 and provides extra layers of defense to help customers protect their software from threats that survive reboots. It guarantees that the instance boots only software that is verified with cryptographic keys. These keys are maintained within the key database of the UEFI non-volatile variable store. UEFI Secure Boot inhibits any unauthorized alterations to the instance's boot process.

How UEFI Secure Boot Works With Amazon EC2 Instances?

UEFI Secure Boot is a feature defined within UEFI that provides assurance regarding the condition of the boot sequence. Its purpose is to guarantee that only UEFI binaries that have been cryptographically verified are executed following the initial setup of the firmware. These binaries encompass UEFI drivers, the primary bootloader, and any components loaded in a chain. UEFI Secure Boot outlines four essential databases that are utilized in maintaining a chain of trust. These databases are kept in the UEFI variable store.

The chain of trust is as follows:

  • Platform Key (PK) database- The PK database serves as the foundation of trust. It holds one public PK key that is utilized within the trust chain for refreshing the key exchange key (KEK) database. To modify the PK database, possession of the private PK key is required to authorize an update request. This process also encompasses the option of eliminating the PK database by assigning an empty PK key.

  • Key Exchange Key (KEK) database- The KEK database consists of a collection of public KEK keys that play a role in establishing the chain of trust for updating the signature (db) and denylist (dbx) databases. To modify the public KEK database, it is necessary to possess the private PK key to authorize a request for an update.

  • Signature (db) database- The db database consists of a collection of public keys and hashes utilized in the chain of trust for verifying all UEFI boot binaries. To modify the db database, possession of the private PK key or any of the private KEK keys is required to sign a request for an update.

  • Signature denylist (dbx) database- The dbx database contains a collection of public keys and binary hashes that are considered untrusted and serve as a revocation file within the chain of trust. This dbx database holds priority over all other key databases. To modify the dbx database, possession of the private PK key or one of the private KEK keys is required to sign a request for an update. By default, UEFI Secure Boot is turned off and the system operates in Setup Mode. In Setup Mode, all key variables can be modified without requiring a cryptographic signature. Once the PK is configured, UEFI Secure Boot becomes active and the system leaves Setup Mode.

Requirements For UEFI Secure Boot on Amazon EC2

When you start an Amazon EC2 instance using a compatible AMI and an approved instance type, the instance will automatically check UEFI boot binaries against its UEFI Secure Boot database. There is no further setup needed. Additionally, you have the option to set up UEFI Secure Boot on an instance after it has been launched.

Conclusion

Some UEFI variables for Amazon EC2 instances are discussed above.






























Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Deployment (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 3, please click  here Microsoft Sentinel Content Hub Content in Microsoft Sentinel includes any of the following types: Data connectors offer log ingestion from different sources into Microsoft Sentinel. Parsers give log formatting/transformation into ASIM formats, supporting usage across various Microsoft Sentinel content types and scenarios. Workbooks provide monitoring, visualization, and interactively with data in Microsoft Sentinel, highlighting meaningful insights for users.  Analytics rules give alerts that point to relevant SOC actions via incidents.  Hunting Queries are used by SOC teams to proactively hunt for threats in Microsoft Sentinel. Notebooks help SOC teams in using advanced hunting features in Jupyter and Azure Notebooks. Watchlists support the ingestion of specific data for enhanced threat detection and reduced alert fatigue.  Playbooks and Azure Logic Apps Custom Connectors provide featu...
Read more