Master Key Types: Microsoft Azure offers 2048, 3072, and 4096 bit RSAasymmetric master keys, but it does not support any symmetric master keys.
Encryption Modes: Microsoft Azure does not offer symmetric encryption methods, but does offer two asymmetric encryption methods: RSA OAEP and RSA PKCS#1v1.5.
Plaintext Size Limits: Microsoft Azure offers a plaintext size limit of 0.25KB.
Bring Your Own Key (BYOK) Options: To utilize BYOK, the key being used on the cloud must first be imported the Cloud Service Provider, and to import the key, it must first be wrapped. Microsoft Azure takes an RSA key that is wrapped by AES and RSA-OAEP.
Signature Modes: To ensure the integrity of data-in-transit, signatures are used. Microsoft Azure offers RSA-PSS, RSA PKCS#1V1.5, ECDSA with P-256, ECDSA with P-512, ECDSA with SECP-256k1. and ECDSA with P-384 signature methods.
Cloud HSM Compliance: Each Cloud Service allows users to store keys in a cloud HSM, but the cloud HSM for each service has different compliancy certificates. Microsoft Azure’s regular Vault HSMis FIPS 140-2 level 2 compliant and its Managed HSM is FIPS140-2 level 3 compliant.
Azure Key Vault Features: Azure Key Vault protects keys and secrets with HSMs or software appliances. Both Azure Services and the customer can access the keys and secrets that are stored. Azure Key Vault is FIPS 140-2 Level 2 compliant and only supports asymmetric keys. It also supports RSA keys of sizes 2048, 3072 and 4096and Elliptic Curve key types P-256, P-384, P-521, and P-256K (SECP256K1). Azure Key Vault supports customer managed keys and manages tokens, passwords, certificates, APIkeys, and other secrets.
Azure Dedicated HSM Features: Azure Dedicated HSM stores keys on an on-premises Luna HSM. This key storage is only accessible by the customer, allowing users to manage keys and not have to worry about the CSP having access to the keys. Azure Dedicated HSM is FIPS 140-2 Level 3 compliant and supports symmetric and asymmetric keys. It also supports RSA, DSA, Diffie-Hellman, Elliptic Curve Cryptography (ECDSA, ECDH, Ed25519, ECIES) with named, user-defined, and Brainpool curves, and KCDSA for asymmetric keys. Symmetric keys created with AES-GCM, Triple DES, DES, ARIA, SEED, RC2, RC4, RC5, and CAST are accepted by Azure Dedicated HSM. For Hash/Message Digest/HMAC, SHA-1, SHA-2, and SM3 are accepted, for key derivation SP800-108 Counter Mode is accepted, and for key wrapping SP800-38F is accepted. Azure Dedicated HSM is capable of offline key backup, and single device provisioning, but customer managed keys are not supported.
Plaintext Size Limits: Amazon Web Services offers a plaintext size limit of 4KB.
Bring Your Own Key (BYOK) Options: To utilize BYOK, the key being used on the cloud must first be imported the Cloud Service Provider, and to import the key, it must first be wrapped. Amazon Web Services takes an AES-256 key that is wrapped by RSA 2048.
Signature Modes: To ensure the integrity of data-in-transit, signatures are used. AWS offers RSA-PSS, RSA PKCS#1V1.5, ECDSAwith P-256, ECDSA with P-512, ECDSA with SECP-256k1. and ECDSA with P-384 signature methods.
Cloud HSM Compliance: Each Cloud Service allows users to store keys in a cloud HSM, but the cloud HSM for each service has different compliancy certificates. Amazon Web Services regular KMS HSM is FIPS140-2 level 2 compliant and the AWS Custom Keystore CloudHSM is FIPS 140-2 level 3 compliant.
Amazon KMS Features: AWS KMS has a managed service in AWS cloud for key storage. Both customers and AWS services can access keys stored in this way. AWS KMS is FIPS 140-2 Level 2 compliant and supports symmetric and asymmetric keys. It also supports RSAES_OAEP_SHA_1 and RSAES_OAEP_SHA_256 encryption algorithms with RSA 2048, RSA 3072, and RSA 4096 key types. Encryption algorithms cannot be used with the elliptic curve key types (ECC NIST P-256, ECC NIST P-384, ECC NIST-521, and ECC SECG P-256k1). When using elliptic curve key types, AWS KMS supports the ECDSA_SHA_256, ECDSA_SHA_384, and ECDSA_SHA_512 signing algorithms. AWS KMS is capable of limited key management, storage and auditing, and encryption.
Amazon CloudHSM Features: AWS CloudHSM has a dedicated hardware appliance in AWS cloud for key storage. This key storage is only accessible by the customer, allowing users to manage keys and not have to worry about the CSP having access to the keys. AWS CloudHSM is FIPS 140-2 Level 3 compliant and supports symmetric and asymmetric keys. It also supports 2048-bit to 4096-bit RSA keys, in increments of 256 bits, 128, 192, and 256-bit AES keys, 3DES 192-bit keys, and keys with the P-224, P-256, P-384, P-521, and secp256k1 curves. Only the P-256, P-384, and secp256k1 curves are supported for sign and verify. AWS CloudHSM is capable of key management, key storage and auditing, and being provided as the root of trust for PKIs.
Master Key Types: Google Cloud Platform (GCP) offers 2048, 3072, and 4096 bit RSA asymmetric master keys. It is also one of the only Cloud Service Providers (CSPs) to offer 256 bit symmetric master keys.
Plaintext Size Limits: Google Cloud Platform offers a plaintext size limit of 64KB.
Bring Your Own Key (BYOK) Options: To utilize BYOK, the key being used on the cloud must first be imported the Cloud Service Provider, and to import the key, it must first be wrapped. Google Cloud Platform takes an AES-256 key that is wrapped by RSA3072.
Signature Modes: To ensure the integrity of data-in-transit, signatures are used. GCP offers RSA-PSS, RSA PKCS#1V1.5, ECDSA with P-256, and ECDSAwith P-384 signature methods.
Cloud HSM Compliance: Each Cloud Service allows users to store keys in a cloud HSM, but the cloud HSM for each service has different compliancy certificates. All HSM keys on Google Cloud Platform are FIPS 140-2 level 3 compliant.
Google Cloud KMS Features: Google Cloud KMS can store keys in either an HSM or a software application. This key storage can be accessed by both the customer and the CSP. Google Cloud KMS is FIPS 140-2 Level 3 compliant if an HSM is used, and FIPS 140-2 Level 1 compliant if software keys are used. Google Cloud KMS supports symmetric and asymmetric keys. It also supports 256-bit Advanced Encryption Standard (AES-256) keys in Galois Counter Mode (GCM), padded with Cloud KMS-internal metadata and RSA keys of sizes 2048, 3072 and 4096.Google Cloud KMS is capable of key management, storage, auditing, encryption, encryption for Kubernetes, and both HSM and software key management.
The National Institute of Standards and Technology, also known as the NIST, is a United States government laboratory that works to develop, test, and recommend best practices for federal agencies, and other organizations relating to things such as online security. Metrics, measurements, and regulations, like the Federal Information Protection Standard, are created by the NIST to help strengthen the reliability and security of technologies being developed. All federal organizations are required to follow standards outlined by the NIST in their specific field when they are dealing with confidential, federal data. The standards and regulations set out by the NIST are recognized internationally, meaning any organization that follows the NIST’s standards for their business sector is trusted to be using the correct practices in their technology. NIST standards and regulations have been created for many Science, Technology, Engineering, and Mathematics (STEM) fields, from astrophysics to cybersecurity.
Why should you try and be compliant?
One of the many questions asked by organizations is why should I comply with the NIST’s standards and regulations? The main reason is the amount of testing put into the publications they release. Weeks, months, and sometimes years of testing are implemented into the subject NIST publications are related to before they are released to the public. This ensures that methods and practices proposed in the standards are the most up-to-date and methods available at the time of writing. The research is done by a team of professionals in their field, so the publications released to the public are extremely accurate, both informationally and technically.
Another reason to comply with the NIST’s standards is the fact that it will make your organizations infrastructure and new technologies much more secure. The goal of releasing NIST publications is to provide a more secure environment for both the government and companies in general. The more organizations that follow these standards, the less security breaches and vulnerabilities are available for exploitation by threat actors. Some regulations, like the Federal Information Protection Standard (FIPS), are required for work with the federal government. This means, any company seeking federal work contracts, will need to be FIPS 140-2 compliant, along with potentially needing to comply with other regulations, depending on the organizations field.
Compliance can also provide your business with an edge over competitors. Those organizations that comply with federal security standards will appeal to customers over those businesses who don’t comply. Those same customers will trust your organization to produce an equally secure product or service in the future, winning your company future business with a recurring client. Some organizations will require compliance with specific regulations if a company wishes to be their vendor. One of these organizations is the United States federal government.
Who needs to be NIST compliant?
All contractors, vendors, subcontractors, and all federal agencies are required to be compliant with NIST standards and regulations if they wish to work with the United States federal government. This is due to the sensitive data that companies working with the government will be manipulating, storing, and processing. If the data is handled improperly, this could cause a security gap allowing threat actors access to information or services that are meant to be top secret. Certain organizations, as well as local governments, may require those companies wishing to work with them to comply with certain NIST standards and regulations as well.
How do you comply with regulations and standards?
One of the easiest ways to follow NIST regulations is to comply with the requirements set forth in the NIST publications. These requirements are specific to each publication, meaning following the requirements of one publication will not guarantee compliance with all NIST publications. To help your company with being compliant with current and future publications created by the National Institute of Science and Technology, you should utilize the Cybersecurity Framework, created by the NIST. The NIST Cybersecurity Framework does not guarantee compliance with all current publications, rather it is a set of uniform standards that can be applied to most companies.
The NIST Cybersecurity Framework was created to improve the cybersecurity of organizations to prevent data breaches and increase the strength of cybersecurity tactics used by organizations. By implementing a uniform set of standards, organizations following the Cybersecurity Framework will already understand the infrastructure and cybersecurity tactics used by other Cybersecurity Framework organizations. The Cybersecurity Framework is broken into 5 stages, called the Framework Core:
Identify – The Identify stage helps the rest of the Framework Core function properly. This stage provides transparency into the workings of the tools currently in use, while prioritizing actions for securing critical infrastructure. Companies implementing this stage will identify all of the software and systems that are critical to the organization’s infrastructure. This helps find unauthorized devices within the network, such as a worker’s phone that is accessing their email, which could be used as an attack vector for threat actors. Understanding the systems at play in your infrastructure helps identify where most of the secure data is kept, which can then be prioritized for protection. All data cannot be protected within an organization, thus secure data has a priority for protection. Asset management, risk assessment, and risk management strategy are all tasks that fall under the Identify stage.
Protect – The protect phase is focused on reducing the number of breaches and other cybersecurity events that occur in your infrastructure. It also handles mitigating the damage a breach will cause if it occurs. This could mean putting security systems in to prevent or detect data loss, such as intruder prevention systems, or other such cybersecurity tools. Identity access and management (IAM) control, training, and data security are just a few of the processes that fall under the protection umbrella.
Detect – This stage helps with the detection of an intruder once a breach occurs, as no security system is 100% secure. Once an attacker gets into your organization’s infrastructure, they must be detected and dealt with in a timely manner, so they do not have enough time to steal any data or compromise any client systems. The longer it takes to detect an intruder, the more data that could be compromised. Events, monitoring, and detection are all a part of the Detect stage.
Respond – The respond stage deals with the response an organization has to a breach. These guidelines help with developing and implementing a plan to respond to a security breach. If the breach is not secured and the attacker is given free reign of an organization, then the breach can become worse and worse. Response planning, communications, analysis, mitigation, and improvements are the steps implemented in the Respond phase.
Recover – The final stage, Recover, deals with the aftermath of a security breach. A plan for disaster recovery is created and implemented here. A back-up of all databases and infrastructure should be in place as part of the recovery plan. This stage includes recovery planning, communications, and improvements for the future.
The Health Insurance Portability and Accountability Act (HIPAA) provides a set of standards to protect the sensitive data of patients. Companies dealing with Protected Health Information (PHI) must have administrative, physical, and technical security measures to be HIPAA compliant.
HIPAA Privacy Rule provides federal protection for PHI held by covered entities. Privacy Rule also permits disclosure of PHI needed for patient care and other important purposes.
Covered entities are anyone providing treatment, accepting payments or operating in healthcare, or business associates. These include anyone who has patient information and provides support in treatment, payments, or operations. All covered entities must be HIPAA compliant. Subcontractors and other business associates must also be HIPAA compliant.
To determine if you are covered, follow this link.
General Security Rules require covered entities to maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting PHI.
Ensuring confidentiality, integrity, and availability of all PHI covered entities create, receive, maintain or transmit.
Identify and protect against reasonably anticipated threats to the security, or integrity of the information.
Protect against reasonably anticipated, impermissible uses, or disclosures.
Ensure compliance by covered entities’ workforce.
Facility Access and Control A covered entity must limit physical access to its facilities while ensuring that authorized access is allowed.
Workstation and Device Security A covered entity must implement policies and procedures to specify proper use of, and access to, workstations and electronic media. A covered entity must also have in place policies and procedures regarding the transfer, removal, disposal, and re-use of electronic media, to ensure appropriate protection of PHI.
Security Management Process A covered entity must identify and analyze potential risks to PHI, and it must implement security measures that reduce risks and vulnerabilities to a reasonable and appropriate level.
Security Personnel A covered entity must designate a security official who is responsible for developing and implementing its security policies and procedures.
Information Access Management A covered entity must implement policies and procedures for authorizing access to PHI only when such access is appropriate based on the user or recipient’s role.
Workforce training and Management A covered entity must provide for appropriate authorization and supervision of workforce members who work with PHI.
Evaluation A covered entity must perform a periodic assessment of how well its security policies and procedures meet the requirements of the Security Rule.
Access Control A covered entity must implement technical policies and procedures that allow only authorized persons to access electronic protected health information (e-PHI).
Audit Controls A covered entity must implement hardware, software, and/or procedural mechanisms to record and examine access and other activity in information systems that contain or use e-PHI.
Integrity Controls A covered entity must implement policies and procedures to ensure that e-PHI is not improperly altered or destroyed. Electronic measures must be put in place to confirm that e-PHI has not been improperly altered or destroyed.
Transmission Controls A covered entity must implement technical security measures that guard against unauthorized access to e-PHI that is being transmitted over an electronic network.
Payment Card Industry Data Security Standards (PCI DSS) are a set of security standards formed in 2004 to secure credit and debit card transactions against data theft and fraud. PCI DSS is a set of compliance methods, which are a requirement for any business.
Let’s suppose payment card data is stored, processed, or transmitted to a cloud environment. In that case, PCI DSS will apply to that environment and will involve validation of the CSP’s infrastructure, and the client’s usage of that environment.
PCI DSS Requirements:
Install and maintain a firewall configuration to protect cardholder data
Do not use vendor-supplied default for system passwords and other security parameters
Protect stored cardholder data
Encrypt transmission of cardholder data across an open, public network
Use and regularly update anti-virus software or programs
Develop and maintain secure systems and applications
Restrict access to cardholder data by business need to know
Assign a unique ID to each person with computer access
Restrict physical access to cardholder data
Track and monitor all access to network resources and cardholder data
Regularly test security systems and processes
Maintain a policy that addresses information security for all personnel