fakecineaste

Cloud compliance engine

Dome9

The Dome9 Arc agentless SaaS platform delivers full visibility and control of security and compliance in AWS, Azure and Google Cloud environments.

https://dome9.com/

Evident.io

Public cloud threat protection, governance & compliance

https://www.paloaltonetworks.com/cloud-security/prisma-public-cloud

Custodian

Cloud Custodian is a rules engine for managing public cloud accounts and resources

It allows users to define policies to enable a well managed cloud infrastructure, that's both secure and cost optimized.

https://github.com/cloud-custodian/cloud-custodian

AWS cloud security

IAM

AWS Identity and Access Management (IAM) - Securely manage access to AWS services and resources

https://aws.amazon.com/iam/

KMS

AWS Key Management Service (KMS)- Easily create and control the keys used to encrypt your data

https://aws.amazon.com/kms

GuardDuty

Protect your AWS accounts and workloads with intelligent threat detection and continuous monitoring

https://aws.amazon.com/guardduty/

GuardRails

A guardrail is a high-level rule that provides ongoing governance for your overall AWS environment.

https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html

Amazon Route 53 is a highly available and scalable cloud Domain Name System (DNS) web service. It is designed to give developers and businesses an extremely reliable and cost effective way to route end users to Internet applications by translating names like www.example.com into the numeric IP addresses like 192.0.2.1 that computers use to connect to each other. Amazon Route 53 is fully compliant with IPv6 as well.

https://aws.amazon.com/route53/

About SAML 2.0-based Federation

Using SAML-Based Federation for API Access to AWS

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html

Enabling SAML 2.0 Federated Users to Access the AWS Management Console

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html

How to automate SAML federation to multiple AWS accounts from Microsoft Azure Active Directory

https://aws.amazon.com/blogs/security/how-to-automate-saml-federation-to-multiple-aws-accounts-from-microsoft-azure-active-directory/

Option 2: SAML-Based Authentication

You can set up the management portal to authenticate users using your identity provider (IdP).

Your users don't have direct access to AWS resources. Instead, the vSphere client gets the user's information from your identity store and uses a SAML assertion to grant the user access to AWS Management Portal for vCenter.

https://docs.aws.amazon.com/amp/latest/userguide/install-option-saml.html

Option 1: Federation Authentication Proxy

You can set up the management portal to authenticate users using the AWS Connector for vCenter.

Your users don't have direct access to AWS resources. Instead, the vSphere client gets the user's information from your vCenter server and assumes an AWS Identity and Access Management (IAM) role to get temporary AWS security credentials for the user.

https://docs.aws.amazon.com/amp/latest/userguide/install-option-connector.html

Configure SAML for Identity Management in Amazon Connect

https://docs.aws.amazon.com/connect/latest/adminguide/configure-saml.html

Gemalto's SafeNet Luna Hardware Security Module (HSM) and SafeNet KeySecure now both fully support Google Cloud's Customer-Supplied Encryption Key (CSEK) feature, meaning customers can generate, manage and bring their own encryption keys to protect data and workloads in Google Cloud Storage and Compute Engine.

Many cloud service providers are offering variations of flexible key management such as bring-your-own-key (BYOK) and hold-your-own-key (HYOK).

https://www.globenewswire.com/news-release/2017/12/04/1219683/0/en/Gemalto-Gives-Google-Cloud-Platform-Customers-Flexible-Encryption-and-Key-Management-Capabilities.html

Customer-Supplied Encryption Key partners

Customer-Supplied Encryption Keys (or CSEK, available for Google Cloud Storage and Compute Engine) allow you to provide a 256-bit string, such as an AES encryption key, to protect your data at rest.

To simplify the use of this unique functionality, our partners Gemalto, Ionic, KeyNexus, Thales and Virtru, can generate CSEK keys in the appropriate format. These partners make it easier to generate an encryption key for use with CSEK, and to associate that key to an object in Cloud Storage or a persistent disk, image or instance in Compute Engine.

https://cloud.google.com/blog/products/gcp/cloud-kms-ga-new-partners-expand-encryption-options

Customer-Supplied Encryption Keys
https://cloud.google.com/security/encryption-at-rest/customer-supplied-encryption-keys/

Host Your Own Keys and Keep Control of Your Data
https://www.virtru.com/encryption-key-management

Use Your own Encryption Keys with S3’s Server-Side Encryption
https://aws.amazon.com/blogs/aws/s3-encryption-with-your-keys

Data Encryption in the Cloud, Part 4: AWS, Azure and Google Cloud
https://cloudarchitectmusings.com/2018/03/09/data-encryption-in-the-cloud-part-4-aws-azure-and-google-cloud/

What is Amazon S3?

Amazon S3 stores data as objects in a flat environment (without a hierarchy). Each object (file) in the storage contains a header with an associated sequence of bytes from 0 bytes to 5 TB. Objects in Amazon S3 are associated with a unique identifier (key), so access to them can be obtained through web requests from anywhere. For example, any allowed node in your own datacenter or external user can get access to any object in your Amazon S3 bucket.

What is Amazon EBS?

Every computer needs a drive and virtual machine is not an exception. Amazon EBS is a storage for the drives of your virtual machines. It stores data as blocks of the same size and organizes them through the hierarchy similar to a traditional file system. EBS is not a standalone storage service like Amazon S3 so you can use it only in combination with Amazon EC2, a cloud computing service by AWS.

There are three types of volumes in Amazon EBS.

General Purpose (SSD) Volumes

Provisioned IOPS (SSD) Volumes

Magnetic Volumes

What is Amazon EFS?

At some point, it became clear that EBS may be good for setting up a drive for virtual machines, and S3 is good for storage, but what if you want to run an application with high workloads that need scalable storage and relatively fast output? Amazon Elastic File System was created to fulfill those needs

You can mount EFS to various AWS services and access it from various virtual machines. Amazon EFS is especially helpful for running servers, shared volumes (like NAS devices), big data analysis, and any scalable workload you can think of.

Amazon S3 vs EFS vs EBS Comparison

https://www.cloudberrylab.com/resources/blog/amazon-s3-vs-ebs-vs-efs/

a diagram of how Amazon Web Services leverages envelope encryption

Given its capability to make data unreadable to those who do not have the key to unlock it, encryption can actually be a powerful tool for protecting data confidentiality.

We are now moving to a world where every piece of data will be encrypted, whether in transit between devices or stored at rest in your servers

Note that while the series is focused on encryption of data at rest, the principles discussed will broadly cover encrypting data in transit.

Encryption can be defined as the use of mathematical functions/algorithms to make data unreadable in order to disguise it from unauthorized actors.

Decryption transforms the disguised data back into readable data.

Plaintext is the unencrypted data or message. It can refer to the data prior to encryption or after it has been decrypted.

Ciphertext is the is the encrypted data or message.

A Cipher Is the mathematical function/algorithm that does the actual encryption and decryption.

A Key is a value that serves as input to the cipher and must used to decrypt ciphertext

In short, the encryption process takes a key (K) and inputs it into the cipher (CI) along with the plaintext (P) to create the ciphertext (C).

The decryption process is essentially the inverse with the key (K) being used as an input into the cipher (CI) to transform ciphertext (C) back to plaintext (P).

While early data encryption relied on the secrecy of the cipher to maintain the security of the system, that has changed over time as it has been shown that any cryptosystem, relying on the secrecy of its algorithm, can be cracked.

“A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.”

Today, cipher algorithms are largely open standard and it is generally acknowledged that the security of any cryptosystem relies on the strength of the cipher and of the encryption key.

Ciphers such as AEs-256 and RSA-2048 can potentially generate ciphertext that takes more time to break than the current age of the universe.

Symmetric or Secret Key Encryption

The same key is used for both encrypting and decrypting data

Here’s an example of how to create a plaintext file and then encrypt it with a 128-bit symmetric key; the openssl command should be fairly easy to understand. You may notice that the encryption command includes an -iv switch followed by a random string of characters.

To decrypt the ciphertext, you just use the decrypt -d option and supply the same symmetric key used to encrypt the original plaintext file.

The challenge with the symmetric key encryption approach is around key storage and management. The secret key has to be carefully protected and distributed securely to all parties that need to encrypt or decrypt data. If the key is lost, then the data is unreadable and if a malicious actor gains access to the key, they will have full access to the data.

The most widely used symmetric key encryption standard today is Advanced Encryption Standard (AES). AES can use keys of different sizes including 128-bit, 192-bit and 256 bit with AES-256 being the most commonly used key size for data encryption at rest

It would require a supercomputer >1 quadrillion years to brute-force decrypt the resulting ciphertext, without the key.

Asymmetric or Public Key Encryption

A different key is used for encryption than for decryption. The encryption key is known as the public key and as the name implies, is typically made publicly available to anyone who wants to send an encrypted message to the owner of the public key. The public key is paired with a private key which only the owner should have access to and is used to decrypt any message that was encrypted with the associated public key.

A common analogy for asymmetric key encryption is the use of mailboxes for postal mail. The secret message can dropped into a publicly located mailbox through the freely accessible mail slot. However, only the postman who has the key can open the mailbox and access the message.

This solves the issue of how to distribute the encryption key securely since it can be made publicly available without fear that data can then be compromised or that the private key may be cracked using the public key.

In fact, symmetric encryption is ~1000x faster and requires 1/10th the key size of asymmetric encryption to encrypt the same data with the same level of security.

The most widely used asymmetric key encryption standard today is Rivest-Shamir-Adleman (RSA)

RSA can use keys of different sizes with RSA-1024 and RSA-2048 being the most commonly used key size for data encryption at rest.

However due to the different algorithms that are used for their respective ciphers, the security of each standard is relatively equivalent.

Envelope Encryption

A hybrid approach is used that can leverage both Symmetric and Asymmetric Key Encryption

A one-time symmetric key, called a Date Encryption Key (DEK) is generated and used to encrypt a piece of data.

A separate symmetric key or public key, called a Key Encryption Key (KEK), is generated and used to encrypt the DEK. The KEK can leverage either Symmetric or Asymmetric encryption.

The encrypted DEK is appended to or placed alongside the ciphertext and stored together.

For the decryption process, the reverse is done:

An application retrieves the ciphertext and associated DEK

The application retrieves the KEK if it is a symmetric key or the associated private key if the KEK is an asymmetric public key

The encrypted DEK is decrypted using the KEK if it is a symmetric key or using the associated private key if the KEK is an asymmetric public key

The ciphertext is then decrypted using the DEK

Envelope encryption has a number of advantages:

Easier data key protection – You don’t have to worry about where to securely store every data key since the keys are encrypted. They can be stored along with their encrypted data. You just have to focus on securing a smaller set of key encryption keys.

Easier key management – With a smaller set of key encryption keys to manage, you can choose to rotate/change just the KEKs and not have to rotate the DEKs and to re-encrypt your data.

Combines the strengths of both symmetric and asymmetric key encryption methods – I mentioned earlier that while asymmetric key encryption makes for easier key management, it is not as efficient as symmetric key encryption. In this case, you can use a symmetric key to encrypt the data and use a public key to encrypt the data encryption key

https://cloudarchitectmusings.com/2018/02/08/encrypting-your-data-in-the-cloud-part-2-encryption-101/

Envelope Encryption

Typically there are many long term keys or master keys that is held in a key management system (KMS).

Typically there are many long term keys or master keys that is held in a key management system (KMS).
When you need to encrypt some message :
A request is sent to the KMS to generate a data key based on one of the master keys.
KMS returns a data key, which usually contains both the plain text version and the encrypted version of the data key.
The message is encrypted using the plain text key.
Then both the encrypted message and the encrypted data key are packaged into a structure (sometimes called envelope) and written.
The plain text key is immediately removed from memory.
When it comes time to decrypt the message:
The encrypted data key is extracted from the envelope.
KMS is requested to decrypt the data key using the same master key as that was used to generate it.
Once the plain text version of the data key is obtained then the encrypted message itself is decrypted.

https://devender.me/2016/07/13/envelope-encryption/

The best security posture takes a multi-layer approach where data is secured end to end.

Encryption can and should be leveraged for a number of use cases including user authentication, data integrity checks, digital signatures and non-repudiation. This series, however, will focus specifically on data encryption.

It is important that data be encrypted both in transit and at rest. The former focuses on encrypting the communication channel between two entities while the latter focuses on encrypting stored data.

https://cloudarchitectmusings.com/2018/01/25/data-encryption-in-the-cloud-part-1-why-you-should-care/

How each provider implements their cryptographic system, including encryption methods, ciphers and key management.

There are a number of activities related to key management including:

Key Generation – This is the creation of encryption keys using a pseudo random number generator

Key Storage – Once the keys are generated, they need to be securely stored and backed up so that they cannot be lost, tampered with or accessed without proper authorization. For password/passphrase based encryption, the passwords and passphrases must be securely stored as well.

Key Activation – A key can be activated at creation time or at a later time manually or automatically. If multiple copies of the key are created and activated, they needs to be stored and tracked

Key Distribution – Once activated, there needs to be a way for authorized applications, systems and users to request and to retrieve keys for encryption and decryption.

Key Rotation – It is recommended that keys be rotated on a periodic basis. Key rotations should be able to occur on an established schedule or manually by an administrator. When a new key is created and distributed to replace an old key, the old key must be deactivated and retained so it can used for decryption purposes.

Key Expiration – An encryption key can be created that will only be used for a specified period. An example of this are one-time encryption keys that are generated for envelope encryption. When a key expires, it must be retained for decryption purposes.

Key Revocation – A key may need to be revoked, if it has been compromised, so it can no longer be used for encryption or decryption. But the key may need to be retained if it has already been used for encryption. In some cases, a revoked key may need to be reactivated for a short period of time to decrypt data.

Key Destruction – In some cases, a key may actually need to be completely removed. In that case, every instance of that key, must be deleted.

there are three type of Key Management Systems (KMS):

Software-based KMS – This can be software downloaded and installed on a set of physical or virtual machines.A popular standalone KMS is Hashicorp Vault.

Hardware-Based KMS - A HSM is specialized hardware designed specifically for cryptography and key management. They are tamper proof and hardened to ensure that keys are properly secured. An HSM could be used in conjunction with KMS software or the KMS software could be embedded into the HSM.

Cloud-Based KMS –The big three public cloud providers – Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), all offer encryption and key management as a managed service.The advantage of these services are that they operate on a pay-as-you-go model, you don’t have to managed the underlying hardware or software

Key Generation

Entropy

In Cryptography, entropy is the measure of uncertainty or randomness in a system.

Entropy refers to the randomness of the cipher and of the encryption key.

The higher the entropy, the more random the results and the more secure the ciphertext.

Since encryption depends so heavily on entropy, you need a component that can reliably generate random bits which can then be used to generate keys and to create ciphertext. This requires an entropy source provided by a Random Number Generator (RNG) and/or a Pseudo Random Number Generator (PRNG), also known as a Deterministic Random Number Generator (DRNG).

The RNG samples data from the analog world, such as temperature measurements, hard drive activity and mouse clicks, as its source of entropy for generating random bits

The PRNG/DRNG takes these random bits from the RNG and stores them in a memory buffer called the entropy pool

The PRNG/DRNG applies a mathematical algorithm to the content of the entropy pool to generate pseudo random bits that can be used for key generation and data encryption.

The reason that an RNG needs to sample analog data is that computers aren’t capable of generating truly random numbers on their own. They need a truly random source of bit to use from the “real world.” The downside of a RNG is that they need a continual entropy source such as keyboard and hard drive activity.

When an RNG runs out of entropy, it will no longer be able to generate random numbers for creating keys and encrypting data.Two scenarios where this may occur, for example, is a virtual machine that is abstracted from the underlying hardware and when an a machine is first booted up and do not have enough random data collected to feed a RNG.

Symmetric Key Generation

two methods:

Direct Key Generation – A key generation algorithm is invoked that uses random bits coming from a PRNG as input

Password/Passphrase Based Encryption – a user supplies a password or passphrase which serves as input to a Key Derivative Function that will generate a symmetric key.

There are a number of hardware and software RNG and PRNG based tools that can generate random passwords/passphrases.

Asymmetric Key Generation

Unlike symmetric keys which are derived directly from random bits provided by a PRNG/DRNG, an asymmetric key pair is created by taking the random bits provided by the PRNG and using them as seed values for a key generation algorithm based on the factoring and multiplication of very large prime numbers.This algorithm generates both the private key and the public key.

The public key can be made available to anyone or any application to use for encrypting data that can only be seen by the owner of the private key.

The private key needs to be stored and protected, preferably in a sound key management system

https://cloudarchitectmusings.com/2018/02/21/data-encryption-in-the-cloud-part-3-key-management-and-key-generation/

Securing the Cloud

When it comes to securing the data stored within AWS or Azure, a critical decision will be about data security and how you plan to manage your encryption keys. You will need to choose where you store your keys, who has access to them, and who controls the lifecycle of the keys
Bring-Your-Own Key (BYOK) and Bring-Your-Own-Encryption (BYOE)
https://www.fornetix.com/encryption-solutions-for-bring-your-own-key-encryption-byok-byoe/

BYOK with SafeNet KeySecure and ProtectApp

https://safenet.gemalto.com/data-encryption/enterprise-key-management/bring-your-own-key-byok/

Azure SQL Transparent Data Encryption with customer-managed keys in Azure Key Vault: Bring Your Own Key support

https://docs.microsoft.com/en-us/azure/sql-database/transparent-data-encryption-byok-azure-sql

UpCRM is pleased to announce : Bring Your Own Key Encryption for Salesforce

https://up-crm.com/upcrm-is-pleased-to-announce-bring-your-own-key-encryption-for-the-salesforce/

Use case – using customer supplied encryption keys

https://subscription.packtpub.com/book/virtualization_and_cloud/9781788834308/5/ch05lvl1sec44/use-case-using-customer-supplied-encryption-keys

Use Your own Encryption Keys with S3’s Server-Side Encryption

https://aws.amazon.com/blogs/aws/s3-encryption-with-your-keys/

the role of data encryption as a critical component of any company’s security posture and the potential pitfalls of not using encryption properly. This is magnified when you are talking about storing data outside of customer data centers such as is the case when archiving data to public cloud storage repositories such as Amazon S3, Azure Blob Storage and Google Cloud Storage

It is important to understand that while public cloud providers are responsible for securing the infrastructure and provide tools for protecting the data stored in their infrastructures, the user is ultimately responsible for using those tools to secure their data.

I want to continue this blog series by giving an overview of how encryption at rest is implemented among the big three public clouds – Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP).

Data-at-rest encryption only since all three providers’ implementation of TLS for encrypting data-in-transit do not differ greatly

Encryption of object storage data since that is where the largest amount of data is stored in the cloud. I will probably be covering services such as block storage, file storage and databases in the future.

How each provider implements their cryptographic system, including encryption methods, ciphers and key management.

Server-Side vs. Client-Side Encryption

With server-side encryption, data is not encrypted until it is transferred to the target, in this case the object storage service. All three providers offer server-side encryption with some differences in implementation details, particularly in regards to key management

With client-side encryption, data is encrypted at the source and prior to it being transferred to the target, in this case the object storage service. All three public cloud providers allow for client-side encryption with some offering varying levels of integration.

Encryption Methods

Amazon S3 supports both server-side and client-side encryption with a number of options for each. Customers have the option of enabling server-side encryption by default for all uploaded objects to S3

For both server-side and client-side encryption, AWS utilizes AES-256 with Galois Counter Mode (GCM) for any symmetric key encryption operations

GCM provides authenticated encryption by adding a unique tag to the ciphertext which verifies that the encrypted data has not been tampered with in any way.

Envelope encryption is used for all client-side options and for all server-side options except when the customer provides the encryption key.

For server-side encryption, Amazon S3 supports three options:

Amazon S3-managed keys (SSE-S3)

AWS Key Management Service (KMS) managed keys (SSE-KMS)

Customer-provided keys (SSE-C)

https://cloudarchitectmusings.com/2018/03/09/data-encryption-in-the-cloud-part-4-aws-azure-and-google-cloud/

How to Protect Data at Rest with Amazon EC2 Instance Store Encryption

Encrypting data at rest is vital for regulatory compliance to ensure that sensitive data saved on disks is not readable by any user or application without a valid key. Some compliance regulations such as PCI DSS and HIPAA require that data at rest be encrypted throughout the data lifecycle. To this end, AWS provides data-at-rest options and key management to support the encryption process.

For example, you can encrypt Amazon EBS volumes and configure Amazon S3 buckets for server-side encryption (SSE) using AES-256 encryption. Additionally, Amazon RDS supports Transparent Data Encryption (TDE).

Disk and file system encryption

You can use two methods to encrypt files on instance stores.

The first method is disk encryption, in which the entire disk or block within the disk is encrypted by using one or more encryption keys. Disk encryption operates below the file-system level, is operating-system agnostic, and hides directory and file information such as name and size.

Encrypting File System, for example, is a Microsoft extension to the Windows NT operating system’s New Technology File System (NTFS) that provides disk encryption.

The second method is file-system-level encryption. Files and directories are encrypted, but not the entire disk or partition. File-system-level encryption operates on top of the file system and is portable across operating systems.

The Linux dm-crypt Infrastructure

Dm-crypt is a Linux kernel-level encryption mechanism that allows users to mount an encrypted file system.

The solution in this post uses dm-crypt in conjunction with a disk-backed file system mapped to a logical volume by the Logical Volume Manager (LVM)

the relationship between an application, file system, and dm-crypt. Dm-crypt sits between the physical disk and the file system, and data written from the operating system to the disk is encrypted. The application is unaware of such disk-level encryption. Applications use a specific mount point in order to store and retrieve files, and these files are encrypted when stored to disk. If the disk is lost or stolen, the data on the disk is useless.

https://aws.amazon.com/blogs/security/how-to-protect-data-at-rest-with-amazon-ec2-instance-store-encryption/

fakecineaste

Tuesday, September 24, 2019

Cloud Development Life Cycle

Monday, September 23, 2019

AWS security

Labels

Blog Archive

Followers

Search This Blog