Mismanaged encryption keys are the cause of various security breaches. Organizations should not rely on platform-managed keys for critical data resources.

Physical media theft is a common means for attackers to gain access to confidential information.

By default, Azure SQL Databases use Transparent Data Encryption (TDE) to encrypt and protect data at rest.

Disabling TDE for an Azure SQL Database exposes the data to potential theft.

Example 1: The following example shows a Terraform configuration that defines an Azure SQL Database that does not encrypt its data.

resource "azurerm_mssql_database" "aztf008-tp-01" {
  name           = "aztf008-db-d"
  ... 
  sku_name       = "DW100c"
  ...
  transparent_data_encryption_enabled = false
}

Implementation flaws, misconfigurations, and compromised keys are some of the problems that prevent single-layer encryption from fully protecting highly-sensitive data. Organizations should adopt a defense-in-depth approach to protect highly-sensitive data and avoid having a single-point-of-failure in their security design.

Implementation flaws, misconfigurations, and compromised keys are some of the problems that prevent single-layer encryption from fully protecting highly-sensitive data. Organizations should adopt a defense-in-depth approach to protect highly-sensitive data and avoid having a single-point-of-failure in their security design.

Automatic software upgrades, which ensure timely patching of known software vulnerabilities, are disabled.

Cloud services typically use techniques like caching, replication, and load balancing to facilitate service scalability, deliver content faster, and mitigate the impacts of volumetric attacks. Disabled or misconfigured availability features degrade service performance, but immediate effects are often not apparent until extreme events such as traffic spikes and hardware failures occur.

Azure offers several encryption options, each with specific benefits and limitations. For example, Azure storage server-side encryption (SSE) performs encryption by default without using compute resources, however, it does not encrypt the temporary disk or caches. It also does not protect data flowing from a compute instance to storage. Azure Disk Encryption (ADE), encrypts both temporary disks and caches, as well as data flowing to storage, but at the expense of compute resources.

Mismanaged encryption keys are the cause of various security breaches. Organizations should not rely on platform-managed keys for critical data resources.

Mismanaged encryption keys are the cause of various security breaches. Organizations should not rely on platform-managed keys for critical data resources.

Data backups are often over-looked as assets that require just as much protection as the original data.

Unencrypted backups leave the backup data accessible to potential attackers.

By default, Azure SQL Virtual Machines Automated Backup settings do not enforce encryption of data backups.

Example 1: The following example shows a Terraform configuration that defines Azure SQL Virtual Machine Automated Backup settings that do not enforce encryption of backup data.

resource "azurerm_mssql_virtual_machine" "aztf009-tn-03" {
  virtual_machine_id               = data.azurerm_virtual_machine.example.id
  ...
  auto_backup {
    retention_period_in_days = 1
    storage_blob_endpoint = ""
    storage_account_access_key = azurerm_storage_account.example.primary_access_key
  }
}

Mismanaged encryption keys are the cause of various security breaches. Organizations should not rely on platform-managed keys for critical data resources.

Implementation flaws, misconfigurations, and compromised keys are some of the problems that prevent single-layer encryption from fully protecting highly-sensitive data. Organizations should adopt a defense-in-depth approach to protect highly-sensitive data and avoid having a single-point-of-failure in their security design.

Mismanaged encryption keys are the cause of various security breaches. Organizations should not rely on platform-managed keys for critical data resources.

Azure offers several encryption options, each with specific benefits and limitations. For example, Azure storage server-side encryption (SSE) performs encryption by default without using compute resources, however, it does not encrypt the temporary disk or caches. It also does not protect data flowing from a compute instance to storage. Azure Disk Encryption (ADE), encrypts both temporary disks and caches, as well as data flowing to storage, but at the expense of compute resources.

Mismanaged encryption keys are the cause of various security breaches. Organizations should not rely on platform-managed keys for critical data resources.

Weak authentication mechanisms expose organizations to unauthorized access.

Authentication mechanisms can fail for various reasons, such as:
- Weak passwords
- Improper validation
- Weak credential management

Weak authentication mechanisms expose organizations to unauthorized access.

Authentication mechanisms can fail for various reasons, such as:
- Weak passwords
- Improper validation
- Weak credential management

Weak authentication mechanisms expose organizations to unauthorized access.

Authentication mechanisms can fail for various reasons, such as:
- Weak passwords
- Improper validation
- Weak credential management

Weak authentication mechanisms expose organizations to unauthorized access.

Authentication mechanisms can fail for various reasons, such as:
- Weak passwords
- Improper validation
- Weak credential management

The Apache Ivy automated dependency management system allows users to specify a version status, known as a dynamic revision, for a dependency instead of listing the specific. If an attacker is able to compromise the dependency repository or trick the build system into downloading dependencies from a repository under the attacker's control, then a dynamic revision specifier may be all that's needed for the build system to silently download and run the compromised dependency. Beyond the security risks, dynamic revisions also introduce an element of risk on the code quality front: Dynamic revisions place the security and stability of your software under the control of the third-parties who develop and release the dependencies your software uses.

At build time, Ivy connects to the repository and attempts to retrieve a dependency that matches the status listed.

Ivy accepts the following dynamic revision specifiers:

- latest.integration: Selects the latest revision of the dependency module.
- latest.[any status]: Selects the latest revision of the dependency module with at minimum the specified status. For example, latest.milestone will select the latest version that is either a milestone or a release, and latest.release will only select the latest release.
- Any revision that ends in +: Selects the latest sub-revision of the dependency module. For example, if the dependency exists in revisions 1.0.3, 1.0.7 and 1.1.2, a revision specified as 1.0.+ will select revision 1.0.7.
- Version ranges: Mathematical notation for ranges, such as < and >, can be used to match a range of versions.

Example 1: The following configuration entry instructs Ivy to retrieve the latest release version of the clover component:

<dependencies>
        <dependency org="clover" name="clover"
                    rev="latest.release" conf="build->*"/>
	...

If the repository is compromised, an attacker could simply upload a version that meets the dynamic criteria to cause Ivy to download a malicious version of the dependency.