Setting up Audit is one of the key aspects of any security architecture. For ADCS, logging is important as well. You may enable and set up Active Directory Certificate Services auditing using the instructions given in this article.
First thing First!
The first step is to ensure that auditing is enabled on your ADCS servers.
For this, Run the auditpol command and make sure “Registry” and “Certificate Services” advanced auditing are turned on.
Wait, but what is auditpol?
Windows captures logs of all kinds which may not be useful to us and cause a lot of confusion and loss of focus. To address this, Microsoft has introduced auditpol. Auditpol is used to categorize granually these logs at user level.
Remember to refresh the group policy after you have enabled it!
Some more examples to use auditpol are shown below :
Example 1:
Example 2 :
In our ADCS use case we will use:
auditpol /get /category:*
The next step is to enable monitoringusing the ADCS snap-in.
To do this, performthefollowing steps on the ADCS server.
Open Server Manager
Select Tools -> Certificate Authority
Right-click the CA name and selectProperties.
Select monitor
Enable requiredmonitoring settings
Backing up and restoring the CA database
Change CA configuration
Change CA security settings
Issuing and managing certificate requests
Revoke certificates and publish CRLs
Storing and retrieving archived keys
Starting and stoppingthe ADCS
The next step is to enable the certificate template changes using the certutil command.
Crypto-shredding is the technique to discard the encryption keys for the encrypted data without zeroizing/deleting the encrypted data, hence making the data undecipherable.
Over the past many years, the topic of data protection has been hitting the headlines. The unstoppable movement of data from various sources is susceptible to various risks and threats that had impacted millions of users in a short time. In the present technological era, data encryption has become the de-facto standard within the various industries; however, the management of encrypted data has become an uphill task for the stakeholders.
While discussing the management of encrypted data, there are two types of encrypted data to be looked into: Active encrypted data & Passive encrypted data.
With the active encrypted data, the data is used by various crypto-systems and being handled appropriately within the security ecosystem, whereas, with the passive encrypted data, the data is not used actively and is ready to be destructed.
Challenges in data destruction
Data destruction is a challenging task while exercising it as an individual’s right for erasure, specifically in reference to data protection regulations such as GDPR. While exercising the right to erasure, the organization has to look up all the references of concerned data within their databases, logs, backups, etc., find the relevant data and delete it from their systems; however, this is not a straightforward task and contains pros & cons of its own.
Next comes the solution to this problem, i.e., crypto-shredding.
Crypto-shredding: Solution to data destruction
As we know, in the crypto-shredding, the encryption is key is discarded/destroyed, and since the key is destroyed, the data that is encrypted by the key automatically becomes unusable as it can’t decrypt it without the key; however, we need to make sure there are no other copies of the key which could be used by bad actors to decrypt the data as the data is still available and lies in an encrypted fashion.
Also, there could be another possibility of breaking the encryption algorithm that can be safely discarded as if the algorithm would have been breakable. It would be considered and marked as vulnerable by the relevant authorities, and any organization would not be using it in the first place itself to encrypt the data.
Considering the above pointers, we can safely assume that the crypto-shredding is equivalent to deleting/zeroizing the data itself.
Crypto-shredding tackles the problem of searching/indexing the specific data reference across the entire infrastructure in a different way by focusing only on one crucial aspect, i.e., management of encryption keys. For example, when the new data is created and is supposed to be stored/backed up/replicated. Before performing any action on this, the data would be encrypted first and then processed further for any action. When the data is supposed to be deleted, rather than searching the data references in your infrastructure, it simply deletes the encryption keys to make the data undecipherable.
Till now, we have understood the strengths of crypto-shredding. Let’s look at the weaknesses as well:
If the encryption applied to the data is not strong enough, the data breach could still occur, and in this case, the process of crypto-shredding won’t be useful.
Since the crypto-shredding deletes the keys only, the encrypted data still exists, and that would require the management of storage in your environment.
As the whole concept of crypto-shredding revolves around the key deletion, the organizations must have an efficient key management system that involves secure key deletion.
Conclusion
Currently, there are no standards in place for crypto-shredding as such. However, certain compliance standards require something called “the right to be forgotten” where the customer has the right to ask that all their personal data be completely deleted without undue delay. Crypto-shredding is an efficient technique to manage the passive encrypted data, but with its own limitations. Many organizations still do not use crypto-shredding as it’s not prescribed by authorities such as NIST, GDPR, etc. Instead of crypto-shredding, customers can take a look at NIST Special Publication 800-88 revision 1, which is a NIST document discussing the sanitization of data.
Dipanshu Bhatnagar is a Principal Consultant Cloud Security Specialty at Encryption Consulting working with PKIs, AWS Cloud Cryptographic services and tools, Google Cloud Cryptographic Services, and helping high profile clients towards their cloud journey with complete data privacy assurance.
Let’s define NIST Cyber Security Framework in brief.
The NIST Cyber Security Framework known as NIST CSF is a cybersecurity assessment-type framework developed by the NIST (National Institute of Standards and Technology). The core purpose of the NIST CSF is to protect the nation’s critical infrastructure using a set of cybersecurity best practices and recommendations. It’s a voluntary, risk-based, and outcome-oriented cybersecurity framework to help your organization to categorize its security activities around five key functions 1) Identify 2) Protect, 3) Detect, 4) Respond, and 5) Recover.
Let’s look at each function briefly:
Identify – The Identify function assist you to evolve an overall cybersecurity risk management approach to systems, people, assets, data, and capabilities in the organization. It helps you to identify the critical assets, overall business environment, governance model, and supply chain.
Protect – The protect function helps you to set up defensive controls based on the inputs from identify function such as critical assets, risk tolerance/acceptance levels. It also emphasizes the importance of access control & identity management, protecting data, and training & awareness to users.
Detect – The detection functions help you to detect anomalies, malicious activities, and other events effectively by continuous security monitoring and with the help of other detection processes & procedures.
Respond – To complete the detection function, respond helps you to take the right action immediately through incident response planning, mitigation actions for events, accurate analysis, communication to the designated stakeholders, and continuous improvement with each event.
Recover – Recover function assists you to get back to the pre-attack condition with the help of recovery planning, continuous improvement, and communication to the designated stakeholders.
NIST Cyber Security Framework Overview: Core, Tiers, and Profile
The NIST CSF consists of three sections:
The core section represents cybersecurity practices, technical, operational, process security controls, and outcomes that support the five risk management functions such as Identify, Protect, Detect, Respond, and Recover.
The tiers section emphasizes the organization’s processes of managing risks while remaining aligned with NIST CSF.
The profiles characterize how effectively an organization’s cybersecurity program is managing its risk. It also expresses the state of an organization’s “as is” and ‘’to be’’ cybersecurity postures.
NIST Cyber Security Framework and AWS Cloud
Earlier AWS team published a guide on how to implement the NIST CSF in an AWS cloud environment. AWS recommends using NIST CSF as a mechanism to have baseline security in place that can improve the cloud security objectives of an organization. NIST CSF contains a comprehensive controls catalogue derived from the ISO/IEC 27001 (1), NIST SP 800-53 (2), COBIT (3), ANSI/ISA-62443 (4), and the Top 20 Critical Security Controls (CSC) (5).
There is a listing on the AWS portal that specifies the alignment of NIST CSF to various AWS services that are known as “AWS Services and Customer Responsibility matrix for Alignment to the CSF” (6). This is a comprehensive list that customers can use to align their needs with the CSF in the AWS cloud for their security requirements. Also, this enables the customer to design their baseline security requirements to meet their security goals.
AWS Cloud Adoption Framework
Before setting up a baseline, it is important for a customer to have a clear understanding of their business use cases and the customer-owned responsibilities for “security in the AWS cloud”. The customer should review the “AWS Cloud Adoption Framework” (7) to evaluate the governance model that will be required while implementing the NIST CSF into the AWS cloud services. The AWS CAF (Cloud Adoption Framework) lists pointers known as “CAF Perspectives” to identify gaps in security skills, capabilities, and cybersecurity processes.
NIST CSF Functions and Responsibilities (Customer-owned & AWS-owned)
AWS team has come up with the concept of NIST CSF Functions categories & sub-categories into 108-outcome based security activities. Every function depicts the Customer-owned and AWS-owned responsibilities that mean security of the cloud owned by AWS and security in the cloud owned by the Customer. Business owners/stakeholders can use the AWS link of “AWS Services and Customer Responsibility matrix for Alignment to the CSF” to tailor their needs as per the organization’s tiers and profile level in the CSF.
The below figure represents the CSF core functions (Identify, Protect, Detect, Respond, and Recover) with categories defined and those that have been converted to 108-outcome based security activities (8) by AWS.
Till now we have discussed the NIST CSF alignment with the AWS Cloud Services and how the customer can use CAF (Cloud Adoption Framework) to evaluate the skill gap, capability, and cybersecurity processes using the CAF Perspectives.
Let’s discuss how appropriate AWS services can be leveraged to set up effective Security Architecture using NIST Cyber Security Framework.
The table below provides a summarized view of AWS Cloud Services categorized into the NIST CSF Core Functions based on the nature of the service:
#
Identify
Protect
Detect
Respond
Recover
1
Organizations
Shield
GuardDuty
CloudWatch
OpsWorks
2
Security Hub
Certificate Manager
Macie
Lambda
CloudFormation
3
Config
KMS
Inspector
Detective
S3 Glacier
4
Trusted Advisor
Network Firewall
Security Hub
CloudTrail
Snapshot
5
Systems Manager
WAF
Systems Manager
Archive
6
Control Tower
Firewall Manager
Step Functions
CloudEndure Disaster Recovery
7
CloudHSM
8
IAM
9
Direct Connect
10
VPC
11
Single-Sign-On
Conclusion:
Having the AWS Cloud Services aligned with the NIST CSF enables the customer to improve their cloud security posture with appropriate risk management and industry-compliant cloud services. Encryption Consulting, a leading cyber-security firm, offers various AWS and NIST related cybersecurity consulting Services catering to its customers a risk and security control maturity assessment based on the outlined standards. Encryption Consulting helps customers to get them familiarized with NIST CSF and AWS security tools & documentation and assist them in conducting a meaningful and quantifiable cybersecurity assessment while keeping the organization’s business goals intact.
Resources:
ISO/IEC 27001:2013, Information Technology – Security techniques – Information Security management systems – Requirements. ISO. Retrieved February 18, 2021, from: https://www.iso.org/standard/54534.html
NIST Special Publication (SP) 800-53, Rev. 5, Security and Privacy Controls for Information Systems and Organizations. National Institute for Standards and Technology. Retrieved February 18, 2021, from: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
Control Objectives for Information and Related Technology (COBIT), an ISACA Framework. Information Systems Audit and Control Association (ISACA). Retrieved February 18, 2021 from: https://www.isaca.org/resources/cobit
ANSI/ISA-62443-2-4-2018 / IEC 62443-2-4:2015+AMD1:2017 CSV, Security for industrial automation and control systems. International Society of Automation (ISACA).
Dipanshu Bhatnagar is a Principal Consultant Cloud Security Specialty at Encryption Consulting working with PKIs, AWS Cloud Cryptographic services and tools, Google Cloud Cryptographic Services, and helping high profile clients towards their cloud journey with complete data privacy assurance.
In today’s world, protecting your data is the most critical job at hand for any security expert. Once the data is protected with the help of some data protection tool and passphrases or passwords, then the next challenge is how to protect the passphrases or passwords or secrets itself. That’s when you need a software or hardware tool which can help you manage the secrets effectively and efficiently. AWS Secrets Manager is one such tool that can manage, retrieve, and rotate the passwords, database credentials, API keys, and other secrets throughout their lifecycle. It provides the central credential management with security at its best, resulting in avoidance of hard coding of credentials in the code.
Today, we will discuss the AWS Secrets Manager and its role in credential management facilitating some of the critical security use cases.
Characteristics of AWS Secrets Manager
AWS Secrets Manager provides various characteristics with respect to credentials management, such as:
Integration with AWS KMS:AWS Secrets Manager is fully integrated with AWS KMS service and encrypts secrets as data-at-rest encryption with the Customer managed KMS keys. While retrieving the secrets, it decrypts the secrets using the same CMK KMS keys used earlier for encryption and transmits the secrets to your local environment securely.
Secret Rotation: AWS Secrets Manager enables you to meet security and compliance requirements as per your organization’s goal. It provides you the secret rotation functionality on-demand or on a scheduled basis through the AWS management console, AWS SDK, or AWS CLI.
Integrating with AWS Database services: AWS Secrets Manager supports native AWS database services such as Amazon RDS, Amazon DocumentDB, and Amazon Redshift. It also provides you the capability to rotate other types of secrets such as API Keys, OAuth tokens, and other credentials with the help of customized lambda functions.
Contains multiple versions of secrets: AWS Secrets Manager can contain multiple versions of secrets with the help of staging labels attached with the version while rotating the secrets. Each secrets’ version contains a copy of the encrypted secret value.
Manage access with fine-grained policies: AWS Secrets Manager provides you flexible access management using IAM policies and resource-based policies. For e.g., you can retrieve secrets from your custom application running on EC2 to connect to a specific database instance (on-prem or cloud).
Secure and audit secrets centrally: AWS Secrets Manager is fully integrated with AWS CloudTrail service for logging and audit purposes. For e.g., AWS CloudTrail will show the API calls related to creating the secret, retrieving the secret, deleting the secret, etc.
We have discussed some of the characteristics of the Secrets Manager. Now, below are the key points to be kept in mind while working with Secrets Manager:
You can manage secrets for databases, resources in On-prem & AWS cloud, SaaS applications, third-party API keys, and SSH keys, etc.
AWS Secrets Manager provides compliance with all the major industry standards such as HIPAA, PCI-DSS, ISO, FedRAMP, SOC, etc.
Secrets Manager doesn’t store the secrets in plaintext in persistent storage.
Since the Secrets Manager provides the secrets over the secure channel, it doesn’t allow any request from any host in an unsecure fashion.
Secrets Manager supports the AWS tags feature, so you can implement tag-based access control on secrets managed by the secrets manager.
To keep the traffic secured and without passing through the open internet, you can configure a private endpoint within your VPC to allow communication between your VPC and Secrets Manager.
Secrets Manager doesn’t delete the secrets immediately; rather, it schedules the deletion for a minimum period of 7 days. Within those 7 days, you may recover the secrets depending upon your requirements and post the scheduled period; the secrets are deleted permanently. However, through the AWS CLI, you may delete any secrets on an immediate basis.
The AWS Secrets Manager offers a cost-effective pricing model where it charges $0.40 per secret per month or $0.05 per 10K API calls.
Use cases for AWS Secrets Manager
Secrets Manager avoids the need for hard-coding the credentials or sensitive information in your application code. It serves the purpose of having an API call to the secrets manager to retrieve the secret programmatically. Having this mechanism in place restricts anyone from compromising sensitive information or credentials as secret information doesn’t exist in the plaintext in the code.
Secrets Manager provides centralized credential management, which reduces the operational burden resulting in the active rotation of credentials at regular intervals to improve the security posture of the organization.
Secret management plays a critical role in data protection for any organization in any environment (On-prem or Cloud). AWS Secrets Manager provides a rich feature set when it comes to secret management solutions. It supports a wide variety of secrets such as database credentials, credentials for On-prem resources, SaaS application credentials, API keys, and SSH keys, etc. In today’s security world, there are a number of secret management solutions available; however, considering the fact that AWS Secrets Manager works seamlessly in the AWS environment, it also provides great compatibility with other environments (On-prem) as well.
Dipanshu Bhatnagar is a Principal Consultant Cloud Security Specialty at Encryption Consulting working with PKIs, AWS Cloud Cryptographic services and tools, Google Cloud Cryptographic Services, and helping high profile clients towards their cloud journey with complete data privacy assurance.
Private and Public Keys:PKI uses these asymmetric keys to establish and secure an encrypted connection over the network using asymmetric encryption.
Public Key Certificates: These are issued by Certificate Authorities which prove the ownership of a public key. They state the authenticity of the keyholder.
Certificate Authority: Certificate Authorities, or CAs, are trusted entities which verify the organization and generate digital certificates which contain information about the organization, as well as the public key of that organization. The digital certificate is signed by the private key of the Certification Authority. This digital certificate can also serve as the identity of the organization and verify them as owners of the public key.
Certificate Repository: A location where all certificates are stored as well as their public keys, validity details, revocation lists, and root certificates. These locations are accessible through LDAP, FTP or web servers.
Automating PKI Operations: These help in issuing, revoking, and renewing certifications. They are done through certificate management software. A PKI is created for having robust security, and if these tasks aren’t automated, or if one invalid or revoked certificate is out there, bringing productivity or the network to a halt, then it may be catastrophic.
PKI is helping us create secure networks. It uses asymmetric encryption to secure data-in-transit. A PKI also issues certificates, which help in verifying the identity of computers, routers, IOT devices, and other devices in the network. This decreases the chance of Man in the Middle attacks (MITM) and other spoofing attacks. It can also be used to create digital certificates which can further strengthen someone’s identity and establish trust.
If PKI was not used, it may be difficult for one computer to trust the other, and there arises the possibility of MITM attacks. Today’s internet has tons of devices including mobile phones, smartwatches, and IOT devices, where privacy and security of transferring data might be a concern. Payment systems also need a seamless encrypted network with both endpoints being trusted, which is created with ease with the help of a PKI.
PKI can be used in:
Establishing Secure Networks and encrypted connections
The authenticity of those sending emails or running websites is questioned every day, as attackers will pretend to be someone they are not to compromise sensitive data of Internet users. The easiest way to prove this authenticity is through use of a digital certificate. Digital certificates utilize key pairs that only the creator of the key pair can own, thus proving they are who they say they are. The certificates are also created and signed by trusted authorities called Certificate Authorities, or CAs. CAs utilize a Chain of Trust, leading back to the original CA which is kept offline and secure, to ensure it cannot be compromised.
Certificates are not just created and given to users, however. They follow an important lifecycle which works to protect and renew certificates, so they can be continually used without fear of attackers stealing them and masking themselves as the owner of the certificate. The trust in certificates created by a certificate authority begins with the assurance that its certificate lifecycle is well managed and immune to compromise. The certificate lifecycle is extremely important to implement, as it is the equivalent of the identity of the user it is issued to.
Why is the Certificate Lifecycle important?
One of the reasons implementing the certificate lifecycle is important is due to what certificates are used for. Certificates identify websites and users on the Internet, meaning if a certificate were compromised at any point in its lifecycle, an attacker could pretend to be that person, and the user who that certificate belongs to would be blamed for any attacks associated with that certificate. Also, since the user’s key is associated with their digital certificate, that key would also be compromised, as would any data that was encrypted by that same key.
Another reason to maintain a strong certificate lifecycle is its use with websites. A compromise of a website’s digital certificate can result in outages, causing losses for the organization whose website it is. The website could also be used to infect user’s computers with malware or execute phishing campaigns, under the guise of the website owner. The first step to the proper implementation of a certificate lifecycle is knowing what each stage of the lifecycle is, and how to protect each stage.
What are the stages of the Certificate Lifecycle?
The stages of the certificate lifecycle are as follows:
Discovery
Creation/Purchasing
Installation
Storing
Monitoring
Renewal
Revocation
Replacement
Discovery: The discovery phase of the certificate lifecycle involves searching the network for missing, expired, compromised, or unused certificates that must be revoked, renewed, or replaced. This is an important part of the process, as it finds gaps in the security of certificates and relays these gaps to the monitoring phase, allowing for the sealing of these breaches. Normally, this phase also deals with the inventorying of certificates to help in future Discovery phases, along with any certificate audits that may occur.
Creation/Purchasing: This is the phase where the certificate is created. An online user, organization, or device requests a certificate from a Certificate Authority, which contains the public key and other enrollment information needed to enroll the user. The CA then verifies the given information and, if it is legitimate, creates the certificate. The Certificate Authority used to create the certificate can be owned by the organization that desires the certificate, or by a third-party. If the certificate is obtained from a third-party, then it must purchased from them.
Installation: The installation of the certificate is straightforward, but still just as important. The certificate must be installed in a secure, but reachable, location, as users attempting to verify the authenticity of the certificate must have access to it. When the certificate is installed, the CA puts policies in place to ensure the security and proper handling of the certificate.
Storage: As previously mentioned, when the certificate is installed, it must be in a secure location to prevent compromise. It should not, however, be so secure that the users that need to read the certificate cannot reach it. The proper policies and regulations to implement for storage of certificates will be discussed later in this document.
Monitoring: Monitoring is one of the most important stages of the certificate lifecycle. This is an almost constant phase where the certificate management systems, whether automatic or manual, watch for breaches, expirations, or compromises of digital certificates. The Monitoring stage uses the inventory created in the Discovery phase to keep track of when certificates should be revoked, renewed, or replaced. The certificate management system then moves those certificates to the next phase, which can be renewal, revocation, or replacement.
Renewal: Renewal of a certificate occurs when the expiry date of the certificate is reached. This occurs naturally with certificates, as best practice is to not use a certificate for more than 5 years at the most. Certificates can be set to renew automatically, or a list can be kept of certificate expiration dates and the administrator of the certificates can renew it at the proper time.
Revocation: If a certificate is found to be compromised, stolen, or otherwise negatively affected, then that certificate will be revoked. When a certificate is revoked, it is put on a Certificate Revocation List (CRL). This list ensures that other CAs know that this is no longer a valid certificate.
Replacement: When users switch from paying for certificates to creating their own Public Key Infrastructures (PKIs) and CAs, the certificate is replaced. This is rarely done, as it is much easier to just renew a certificate from the original provider rather than replace that certificate.
Protection of each phase of the Lifecycle
Each portion of the certificate lifecycle requires its own level and methods of protection. The Discovery phase acts as a security measure in and of itself. By searching for expired or missing certificates, breaches can be detected before they become an issue. The Monitoring phase is similar, as it monitors for expired, improperly implemented, or compromised certificates. Both of these phases can be automated to allow for a better detection process. There is the potential for a manual management system missing a compromised or expired certificate.
The remaining phases require a strong level of protection and authentication. The Creation stage should ensure that the CA issuing the certificates has a valid Chain of Trust each time a new certificate is created. Installation should be correctly, as poorly implemented certificates are a breach of security that an attacker can leverage for malicious purposes. The Storage phase needs to have strong security, so that the certificates are not compromised and misused by threat actors. The revocation, renewal, and replacement of certificates must also be done securely and correctly, as these stages begin the cycle again from the beginning.
Digital certificates are used across the Internet to authenticate users exchanging data with one another. Since every legitimate website uses a certificate, certificate management is extremely important. If a certificate were to be stolen and misused, an attacker could pose as another, more legitimate, source and infect a user with malware via their website. The expiration of a certificate of a certificate can result in an outage, causing an organization to lose out on potential customers. These are just a few reasons to learn more about certificate management.
What is Certificate Management?
Certificate management is the process of monitoring, processing, and executing every process in a certificate’s lifecycle. Certificate management is responsible for issuing, renewing, and deploying certificates to endpoints (servers, appliances, devices, etc.) so that network services are uninterrupted. Certificate management should also automate tasks (issuing, renewal, and so on), as well as provide real time status of the infrastructure of the network.
Certificate management helps manage the network and prevent interruptions and downtime, while providing a detailed monitoring of the whole infrastructure. Good certificate management plans should be able to handle any network, even ones with thousands of devices. If a certificate expires or is misconfigured, catastrophic outages all over the network may occur.
What is a Digital Certificate?
Any discussion of certificate management would be incomplete without explaining what a digital certificate is. A certificate, also known as an SSL/TLS certificate, is a digital identifier for users, devices, and other endpoints within a network. Certificates are linked with a public/private key pair and verify that the public key, which is matched with the valid certificate, can be trusted. The main job of a certificate is to ensure that data sent across a connection between a user and a server is kept private. The certificates does this by encrypting and decrypting data as it is sent across the connection. This is achieved through something called an SSL/TLS Handshake.
TLS Handshake
A TLS Handshake is executed as follows:
1. Client Hello:The client hello occurs when the client sends a request to the server to communicate. The TLS version, the cipher suites supported, and a string of random bytes known as the “client random” are included in the hello.
2. Server Hello: In the server hello, the server acknowledges the client hello. It then ensures it is using a TLS version that is compatible with the client TLS version, selects a compatible cipher suite from the ones offered by the client, and sends its certificate, the server random (similar to the client random), and the public key to the client.
3.Certificate Validation: The validity of the server’s certificate is first checked by the client through the certificate authority. The certificate authority, or CA, is a highly trusted entity given the responsibility of signing and generating digital certificates.
4. Pre-Master String: The client then encrypts a random string of bytes, called the “Pre-Master String” with the server’s public key and sends it back to the server. This ensures that only the server can decrypt the key with its own private key, acting as another level of security.
5. Session Key Creation: The server decrypts the pre-master key, and then both the client and server create session keys from the client random, the server random, and the premaster string.
6. Finished Messaging: The client and server then send each other messages saying they have finished creating their keys, and they compare keys with each other. If the session keys match, the TLS Handshake is completed, and the session keys are used to encrypt and decrypt any data sent between the server and client.
Once created, certificates can be used for authentication of servers, clients, or other devices. Certificates are considered valid for a certain time period, and expire after that time frame. Certificates follow a constant lifecycle which include phases such as creation, renewal, suspension, expiration, and more. If certificates are left to expire, then the certificate holder will no longer be trusted, resulting in a loss of service for the website or device being used. To receive a certificate, a user or website must first go through a certificate authority or sign one themselves.
Certificate Authorities
Certificates can be generated through either a trusted certificate authority or by signing a certificate themselves. Certificate authorities, or CAs, generate certificates for users to be used for TLS/SSL authentication. To ensure a certificate authority can be trusted, the chain of trust of the CA can be followed back to the source CA. A chain of trust is a chain of certificates published by trusted CAs, leading all the way back to the Root CA. To start the process of acquiring a digital certificate, the requestor must send out a Certificate Signing Request (CSR) to the CA. The CSR must have the public key of a key pair created by the requestor, along with information to confirm the identity of the requestor, such as a social security number or driver’s license. Once the requestors identity has been confirmed, the certificate is signed and returned by the CA and can be used for identification of the requestor.
The other option to get a certificate is to create one yourself using the same information, and then to self-sign it. This is used less often, because the identity of the signer cannot be verified with other trusted CAs, thus rendering the self-signed certificate suspicious. Due to this, many will not accept a self-signed certificate, so using a CA to create a certificate is the suggested method.
Certificate Lifecycle
There are several distinct stages to the certificate lifecycle, which are shown below.
Discovery
Creation/Purchasing
Installation
Storing
Monitoring
Renewal
Revocation
Replacement
Discovery: Discovery is the first stage of the certificate lifecycle. In the discovery phase, the network is scanned for missing, expired, or unusable certificates. This phase also ensures any certificates already in place have been deployed properly. Certificates with vulnerabilities and other weaknesses can also be detected and fixed or replaced. The different certificates are commonly inventoried together in this phase to allow for tracking of certificate statuses, or grouping of related certificate types.
Creation/Purchasing: In this stage the CA creates the certificate itself, or the user purchases a certificate from a trusted CA. The key pair for the certificate is created and the public key, CSR, and personally identifiable information are sent to the CA for certificate creation. If an organization or user does not have or does not wish to create a chain of trusted CAs, a certificate is purchased instead of being created.
Installation: This stage deals with the distribution and installation of the certificate in its proper place. All aspects of the certificate’s configuration are checked in the installation phase, including the key pairs, the cipher suites, and the digital signature. The certificate is then installed onto the appropriate endpoint it was created for, and begins authentication of that endpoint.
Storing: One of the most important stages of the certificate lifecycle is the storing phase. Certificates must be accessible, but not reusable by attackers, thus they must be kept in a secure and centralized location. The storing phase can also inventory the certificates into groups, if inventorying was not done in the discovery phase.
Monitoring: This is the longest phase, where the certificates are monitored throughout the duration of their expiration period. Once the expiration date is reached, or sometimes right before, certain certificate management systems will automatically renew certificates. If automatic certificate management systems are not being used, then a system administrator will need to monitor the network’s certificates and renew, revoke, or replace any certificate that reaches its expiration date.
There are benefits to both manual and automatic monitoring, which will be discussed in-depth in the next section, but there are two important benefits which stand above the rest. The biggest benefit of manual monitoring is that if an unexpected issue occurs, then the monitor can react in real time to the problem, whereas an automatic system will not know what to do. On the other hand, an automatic monitor’s biggest benefit is that certificate renewals, revocations, etc. will not be forgotten, which can occur if a human is monitoring certificates for years.
Renewal: The renewal process of certificates begins once the validity of the certificate has run out. Once the user or automated systems decide to renew the certificate, a CSR is resent to the original issuing CA to get the certificate renewed. The process occurs as it did with originally creating the certificate, but much more quickly.
Revocation: If the issuing CA has be decommissioned, a certificate is being misused, or for a host of other reasons, then a certificate can be revoked. Once revoked, the certificate is placed on a Certificate Revocation List, or CRL, if a CRL is in use. A CRL is a list of certificates revoked by the CA that should no longer be trusted. If an Issuing CA’s certificate is on a CRL, then that CA cannot be used in a chain of trust for other CAs or certificates. A downside to using CRLs is that revoked certificates are only published periodically, not every time a certificate is revoked. This issue means a user could renew their certificate with their issuing CA, even though a few hours ago their certificate was revoked for illegitimate usage.
Replacement: If a CA’s certificate is revoked or if the certificate owner wishes to move from paid certificates to their own Public Key Infrastructure, then the replacement phase occurs. This occurs less often, as it is easier to just renew a certificate with the original issuing CA.
The certificate lifecycle is not set in stone. Different organizations will have different stages, combine stages, or leave out entire stages entirely. As long as the certificates are discovered, created, stored, monitored, and renewed, then that is considered a certificate lifecycle.
Manual vs Automated Infrastructure
One of the most important parts of a company’s data security policy is the certificate management infrastructure put into place within the organization. A manual infrastructure involves having an employee create a spreadsheet to keep track of validity periods, policies, revocations, and configuration data of all the certificates within the organization. This method will work with a smaller company with an infrastructure only dealing with a few certificates, but many larger companies can have thousands upon thousands of certificates, making manual infrastructures too complicated. The other option is to create an automated certificate lifecycle infrastructure, which is the more common method. Below is a table highlighting the differences between manual and automated certificate management infrastructures.
Manual Infrastructure
Automated Infrastructure
Lifecycle Stages
Handled via a spreadsheet and a user keeping track of all the certificates within the organization
Streamlined and handled automatically; Certificates renewed/replaced/revoked as soon as necessary
Operational Cost
Costs many man hours
Less cost and no man hours needed
Security
Must be constantly kept track of by the employee in charge to ensure certificates do not expire
Is constantly watched by the software set up in the infrastructure, allowing for quick renewal or replacement of certificates
Implementation
Easy and quick to implement; Only a spreadsheet is required
The software must be implemented correctly, or certificates will not be monitored correctly
These reasons, and more, are why automated certificate lifecycle management systems are used in Public Key Infrastructures.
The Importance of Certificate Management
One of the most important reasons to have a strong, automated certificate management system is if you have your own Public Key Infrastructure (PKI). A PKI is an infrastructure created to authenticate users based on digital certificates. PKIs can encrypt communications as well. The most common PKI is TLS/SSL, which uses both symmetric and asymmetric encryption in securing connections between two users. The core trust of a PKI comes from the certificates traded between the two sides of the connection. Most PKIs use a two layer architecture, which includes a Root CA and an Issuing CA.
Root CA is a certificate authority that is kept offline and creates a certificate for the online Issuing CA. This creates a chain of trust with all certificates issued by the Issuing CA, as the Root CA is kept offline so it is therefore secure from malicious intent. Issuing CAs distribute certificates for end users and devices. The less commonly used three tier architecture for a PKI includes an Intermediate CA between the Root and Issuing CA, which act as a go between for the Root and Issuing CA. The reason automated certificate management is mainly used by PKIs is because it is more secure to create a PKI correctly once and then let the automated services keep the certificates up to date. This cuts down on the cost to the company, the man hours required to keep the PKI running, and human error. Since so many organizations are creating their own PKI, proper certificate management is key to any company’s security plan.
Another reason that so much importance is put onto certificate management is the need for every device and user that is connected to the Internet to have a digital certificate. Whenever a user or a device connects to a website, the authenticity of their digital certificate is checked, along with the certificate of the website. By having a strong chain of trust and a valid certificate, you can go anywhere on the Internet. However, a certificate is invalid or expired, if the user or device that certificate belongs to cannot go to most websites, as a secure connection cannot be established. The same holds true for website certificates. If their digital certificate is invalid, then users will not or cannot use that website, for fear of getting malware or viruses on their device.
One more reason to ensure strong certificate management is so that breaches do not occur in an organization. If a certificate were to be allowed into a network, even though it has untrusted CAs in its chain of trust, then the owner of that certificate could steal sensitive data or otherwise misuse company data for malicious purposes. Also, if the certificates are not stored properly, then an attacker could steal that certificate and pose as a legitimate user, while stealing, changing, or deleting sensitive data.
Other Certificate Uses
There are a number of other uses for digital certificates, which are listed below.
Intranet Portals
Ecommerce websites
VPNs
Point of Sales System
Internet of Things Devices
App Development
Code Signing
Email Signing
SSH Key Management
Financial Services
Customer Service Websites
Cloud Authentication
Certificate Management with Encryption Consulting
Encryption Consulting provides a variety of services relating to certificate management. We offer PKI assessments,CP/CPS development for PKIs, and PKI Design and Implementation services. Our PKI assessment will assess the current certificate management practices of our customer and help with the development of a strategy and roadmap for certificate management. Our CP/CPS development and PKI design and implementation services provide assistance in creating and implementing all the stages of a PKI, from on-premises to the cloud. We can provide our services via video or in person, at the customer’s behest. We also provide services to help develop and implement certificate management systems into new and current infrastructure.
When a user connects to a website via HTTPS, asymmetric encryption is used. For that to happen, the user uses the server’s public key to initiate the connection. To confirm the authenticity of that public key, certificates are used. The certificate will have details such as who does this certificate belong to, who issued it, a serial number, expiration date and the public key.
This can establish trust where the certificate and the key can be trusted and thereafter the communication between the user and the server is also trusted.
Anish Bhattacharya is a Consultant at Encryption Consulting, working with PKIs, HSMs, creating Google Cloud applications, and working as a consultant with high-profile clients.
Data encryption of a table in SQL Server is done at the column level, column by column, and utilizes symmetric encryption. The following steps detail how this process occurs within SQL Server:
A database master key is created
A self-signed certificate is created which will be protected by the database master key
A symmetric encryption key to be used for the column level encryption is created from the certificate
The table is then encrypted with the EncryptByKey function using the symmetric key and the name of the certificate
To decrypt data, the DecryptByKey function is called, which also requires the symmetric key and the name of the certificate.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
