Skip to content

Why older TLS protocols are unsafe for your organization?

In the early 1990s, Netscape began developing SSL; therefore, an initial draft was submitted for SSL v2.0 in 1995. SSL v2.0 had major security flaws that led to the creation of SSL v3.0. The draft for SSL v3.0 was submitted to the IETF in 1996. In Netscape’s words, SSL v3.0 could be a security protocol that prevents eavesdropping, tampering, or message forgery over the Internet. The IETF published RFC 61012 (Request for Comment) as specification for SSL v 3.0.

SSL began to be known as TLS, and the next version of TLS came in 1999 with RFC 22463. In a nutshell, SSL v 3.0 and TLS 1.0 don’t have variations that a developer should worry about; however, it’s better to use TLS 1.0. The next version of TLS, TLS 1.1, came into existence in 2006 and is outlined in RFC 43464. TLS 1.1 has enhancements over TLS 1.0. The next version, TLS 1.2, was released in 2008 and is defined through RFC 52465.

TLS 1.2 has had major changes since TLS 1.1, and it includes support for newer and secure cryptographic algorithms. In August 2018, TLS 1.3 was released. The differences between TLS 1.2 and 1.3 are extensive and significant, improving each performance and security. Simultaneously, TLS 1.2 remains in widespread use given its absence of known vulnerabilities and its continued usage in enterprise environments.

Outdated TLS versions

Sensitive data always require robust protection. TLS protocols provide confidentiality, integrity, and often authenticity protections to information while in transit over a network. This can be achieved by providing a secured channel between a server and a client to communicate for a session. Over time, new TLS versions are developed, and some of the previous versions become outdated for vulnerabilities or technical reasons; and, therefore, should no longer be used to protect data.

TLS 1.2 or TLS 1.3 should be used, and any organizations should not use SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1.

Outdated Cipher suits

In TLS 1.2, the term “cipher suites” refers to the negotiated and agreed-upon set of cryptographic algorithms for the TLS transmission. The TLS client offers a list of cipher suites, and the server selects negotiated cipher suites from the list. The cipher suites in TLS 1.2 consist of an encryption algorithm, a key exchange algorithm, an authentication mechanism, and a key derivation mechanism.

Cipher suites are identified as obsolete when one or more of the mechanisms is weak. Fragile encryption algorithms in TLS 1.2 are defined as NULL, RC2, RC4, DES, IDEA, and TDES/3DES; organizations should not use cipher suits with these algorithms. TLS 1.3 removes these cipher suites, but implementations supporting TLS 1.3 and organizations should check TLS 1.2 for obsolete cipher suites.

Outdated Key exchange mechanisms

Weaker key exchange mechanisms indicated by cipher suite include those designated as EXPORT or ANON. Cipher suites that use these key exchange mechanisms should not be used. In TLS sessions, even if the cipher suite is acceptable, key exchange mechanisms may use weak keys that allow exploitation. TLS key exchange methods include RSA key transport and DH or ECDH key establishment.

DH and ECDH have static as well as ephemeral mechanisms. NSA recommends RSA key transport and ephemeral DH (DHE) or ECDH (ECDHE) mechanisms, with RSA or DHE key exchange using at least 3072-bit keys and ECDHE key exchanges using the secp384r1 elliptic curve. For RSA key transport and DH/DHE key exchange, keys less than 2048 bits should not be used, and ECDH/ECDHE using custom curves should not be used.

Risk of outdated TLS protocols

Outdated TLS protocols use cipher suites that are not supported or recommended, and using older TLS versions would require effort to keep the libraries and drive up the cost of product maintenance. Apart from the above-discussed scenario, some additional ones can be:

  • Using outdated TLS versions would force organizations to use outdated, vulnerable cipher suites and not support newer recommended cipher suits.
  • TLS 1.0 and 1.1 are vulnerable to downgrade attacks since they rely on SHA-1 hash for the integrity of exchanged messages. Even authentication of handshakes is done based on SHA-1, which makes it easier for an attacker to impersonate a server for MITM attacks. TLS 1.1 or below does not provide the option to select more robust hashing algorithms, which the newer protocols do.
  • Supporting older protocols drive up cost as all vulnerabilities need to be patched, libraries need to be supported, and the attack surface increases.

Tailored Encryption Services

We assess, strategize & implement encryption strategies and solutions.

Learn More

Identifying and analyzing outdated TLS protocols

Since there are many ways that obsolete TLS configurations may be exhibited in traffic, the following detection strategy is recommended. Signatures can be simplified using this strategy:

  • First, identify the client’s offering and servers negotiating obsolete TLS versions. If a client offers or a server negotiates SSL 2.0, SSL 3.0, or an outdated TLS version, no further traffic analysis is required, and remediation strategies should be employed.
  • Next, for sessions using TLS 1.2, organizations should identify and remediate devices using obsolete cipher suites. Identify clients only offering and servers negotiating outdated TLS cipher suites and update their configurations to be compliant.
  • Finally, organizations should identify and remediate devices using weak key exchange methods for sessions using TLS 1.2 or TLS 1.3 and recommended cipher suites.

Benefits of upgrading to newer protocols

Apart from getting rid of vulnerabilities and having better security for the environment, organizations do tend to gain a few benefits by upgrading to newer protocols:

  • Increase performance in the overall environment.
  • Improved security.
  • Better support and patches for the vulnerabilities found, along with research for new vulnerabilities.
  • Better hashing algorithms for integrity check and authentication of handshakes.

Conclusion

Organizations encrypt network traffic to protect data in transit. However, using obsolete TLS configurations provides a false sense of security since it looks like the data is protected, even though it is not. Organizations should plan to discontinue outdated TLS configurations in the environment by detecting, remediating, and then blocking obsolete TLS versions, cipher suites, and key exchange methods.

Resources

Ensure that the best encryption practices are implemented for your organization with Elliptic Curve Cryptography

Elliptic curve cryptography (ECC) offers an equivalent level and kind of security as RSA (or Diffie-Hellman) with abundant shorter keys. Table one compares the most effective current estimates of the key sizes for three different encryption approaches for comparable security levels against brute-force attacks.

Bruteforcing, a symmetric-key cipher like AES, suggests that looking through the complete key-space means integer factorization for an algorithm like RSA and resolving the digital-logarithm problem for an algorithm like ECC. This table is a lot more significant due to the process burdens of RSA and ECC being comparable for comparable key lengths, which implies that it takes a sixth of the processing effort with ECC to supply an equivalent level of cryptographic security that we tend to get with 1024-bit RSA.

Symmetric Encryption in bits RSA and Diffie-Hellman “Key” size in bits ECC “Key” size in bits
80 1024 160
112 2048 224
128 3072 256
192 7680 384
256 15360 512

Table 1: Best estimates of the key sizes needed to achieve an equivalent level of security with three different methods.

Since the key sizes are much smaller, smartcards can use ECC algorithms without mathematical coprocessors. Contactless smart cards work only with ECC as other systems require too much induction energy. Since shorter key lengths translate into faster handshaking protocols, ECC is becoming increasingly crucial for wireless communications. For the same reasons, we can also expect ECC to become essential for wireless sensor networks.

ECDH Cryptosystem

Elliptic Curve Diffie-Hellman (ECDH) is a version of the Diffie-Hellman key exchange algorithm for elliptic curves, that determines how two communication participants A and B, can generate key pairs and exchange their public keys via insecure channels. The algorithm determines only how key pairs are generated, and the user defines the relation between encryption keys and data to be encrypted. After the keys have been exchanged, it is common to use symmetric encryption methods. In practice, the ECDH cryptosystem can be successfully adapted to different data security solutions.

ECDSA Crypto System

Elliptic Curve Digital Signature Algorithm (ECDSA) is DSA (Digital Signature Algorithm) digital signature standard analog for elliptic curves. Similar to DSA, the goal of ECDSA is to provide verifiable digital signatures for data messages. The author signs the data message by using his private key, and the digital signature is added to the content of the message and can be freely validated by using the message author’s public key. Private keys are generated very much like to ECDH cryptosystem. If P and Q are two points on an elliptic curve, the private key is the discrete logarithm m=logPQ.

Implementation Issues

Implementation issues of elliptic curve-based cryptosystems can be divided into four abstract categories.

  • The first category includes technical errors concerning hardware and software implementations in the form of lack of authentication, inadequate RAM and media protection, errors in algorithms, incorrect network infrastructure, etc. For those security problems, it is expected that the sensitive information, including private encryption keys, can come at the disposal of third parties without attempts to break the cryptosystem’s fundamental security background but by accessing the data directly through the hardware and software security holes.

    This is the most common implementation issue and is not related to the security of the fundamentals of a cryptosystem, and it is associated with insufficient software testing and computer system security audits.

  • The second type of implementation issue is associated with selecting underlying elliptic curves and prime fields. There are classes of weak elliptic curves. For instance, it is possible to solve the discrete logarithm problem in polynomial time for a specific type of curve where #E(Fp) = p – the number of points on a curve is equal to the number of elements in a finite field. Also, it is essential to select large enough subgroups of E(Fp) to avoid feasible calculation of discrete logarithms by methods such as the Pollard-p method.

    To ensure maximum security of the cryptosystem, it is advisable to use verifiably random elliptic curves and prime fields such that the order of group #E(Fp) is divisible by a sufficiently large prime number n where n > 2160.

  • The third type of implementations issues is associated with the performance of E(Fp) group operations like addition and scalar multiplication. It is advisable to use Mersenne primes, which can significantly improve the scalar multiplication operation. This result is related to the processor architecture that enables the effective execution of module arithmetic operations with the binary representation of the number, which is close to the power of two. Also, it is essential to select the most appropriate coordinate system to improve the performance of group operations.

    Depending on the selected coordinate system, the performance of group operations may vary. For instance, the performance of scalar multiplication can be improved by using the Jacobi coordinate system when the scalar multiplication takes place with an even number (point doubling).

  • The fourth type of implementations problems is associated with private key management. It is required to ensure that the private keys are being re-calculated and re-issued regularly. Usage of constant private keys seriously increases the risk of keys being intercepted by a third party. The most typical example is the interception of a private key from 2010 with the Sony PlayStation application signature cryptosystem, where a constant private key was used for all issued digital signatures.

Tailored Encryption Services

We assess, strategize & implement encryption strategies and solutions.

Learn More

Benefits of elliptic curve-based cryptosystems versus RSA cryptosystem

  • Key size

    The key of an elliptical curve-based cryptosystem takes significantly less memory, and the ratio increases rapidly with the increase of security levels. For instance, an RSA cryptosystem with a key length of 1024 bits is equivalent to an elliptic curve cryptosystem with a key length of 160 bits.

  • Cryptographic operations performance

    Cryptographic operations such as key and digital signature generation are carried out significantly faster thanks to the smaller keys. For instance, an elliptic curve cryptosystem with a key length of 233 bits corresponds to the RSA cryptosystem with 2240 bits. In the first case, the key is generated approximately 40 times faster.

  • Resource savings

    Due to the smaller key sizes, algorithms of the elliptic curve-based cryptosystems can be executed on minimal resources.

Disadvantages of elliptic curve-based cryptosystems versus RSA cryptosystem

  • Significantly more complex mathematical backgrounds.
  • A relatively large group of weak elliptic curves.
  • Lack of research.

Conclusion

Despite the several decades-long histories of elliptic curve cryptography, there is still a lack of research. The popular RSA cryptosystem is more widely studied. A significant lack of research is one of the main reasons elliptic curve-based crypto systems have shown low popularity nowadays. It is possible to conclude that the lack of research is related to the relatively complex mathematical foundation of elliptic curves and the lack of interest from the systems developers. It is expected that elliptic curves will play a growing role in various implementations.

The discrete logarithm problem is algorithmically more complex than the integer factorization problem, allowing a significant reduction in the public key cryptographic key size, thus speeding up various cryptographic operations.

Elliptic curve-based cryptosystems can be effectively used on low resources and power system solutions such as smart cards, mobile devices, sensors, and so on.

Everything About Man-in-the-Middle (MITM) Attack

As the name suggests, Man in the Middle Attack is a type of Cyberattack that happens when a cybercriminal sits between two users. An intruder places himself between user and network to steal or distort data/information. In this attack, the attacker can either be a silent and quiet listener, an active user altering your data or even the person you are talking to. 

A MITM attack can happen to any network, whether internal or external, affecting any IP ports.

Mechanism of MITM

MITM is a type of attack where a hacker uses transit data to intercept, secretly rerouting traffic and changing the connection parameters between endpoints that don’t know they are compromised. So, they are hard to detect as it doesn’t affect the network directly.

Let’s see this with a scenario:

  1. Imagine two persons X and Y are communicating on a confidential channel, and Z(hacker) silently break into their pipeline to listen to what they are talking
  2. X passes a message to Y.
  3. Z enters between and reads the message, which was supposed to be seen only by Y, without X or Y knowing.
  4. Z(Hacker) changes the message causing harmful/unwanted results.

Signs of being Victim

Here are the signs which will tell you that we might have an unwanted guest:

  • Always double-check for addresses in your address bar. If you see anything abnormal in the address bar, cross-check it, even a little one.

    For example: if you see https://spooFing.com instead of www.spoofing.com, take precautions.

  • Continuously monitor for repeated disconnections. Attackers usually disconnect users to gain access over username and passwords whenever the user tries to re-login.
  • So, always check out these signs of being a Victim.

Types of MITM Attacks

  • Wifi-Eavesdropping

    WiFi-Eavesdropping is a type of MITM attack that traps unconscious users from login into malicious wifi Networks. To perform this type of attack, a hacker usually spreads a wifi network to a public location like Stations, Hospitals, Restaurant, etc., and names the web with similar public network ones. Some people usually keep their devices to auto-connect falls into the trap. Since the user is trapped, hackers can perform various MITM attacking techniques like SSL stripping attacks, forcing users to undergo multiple unencrypted websites. So, it is advised not to connect to the public network.

  • Session Hijacking

    In Session Hijacking, any user in the session can be hijacked by the attacker and can lose control of the session. All of his data/information can easily be stolen. It can be done with sessions, but it is commonly seen in browser sessions on web applications. There are several ways to do session hijacking, but here are some common ways through which it can be achieved:

    • Session side jacking

    • Cross-site scripting (XSS)

      To prevent Session Hijacking, organizations use various encryptions in certificates using: SSL and TLS.

  • HTTPS Spoofing

    In HTTPS, the word S stands for Secure. Attackers mostly take advantage of this only as the user thinks he is into the safeguard. Attackers put up HTTP websites whose domain looks very similar to the original one. In this tactic, known as “homograph attack,” attackers replace the character in the target domain with non-ASCII characters, which look very similar to the original field. The unsuspected user will not notice this slight difference and will fall into this trap easily.

Tailored Encryption Services

We assess, strategize & implement encryption strategies and solutions.

Learn More

How Encryption can prevent MITM Attacks

The most used way to prevent a MITM attack is by encrypting the process of communication.

The process works like this: when a server is transferring data, it provides a digital certificate for identifying the client. Then, the channel between client and server is encrypted.

In Encryption, a key is needed to encrypt and decrypt messages shared between Sender and Receiver. We will need that key to decipher the notes; the same is the case for attackers. Without that key, no one can access our information. There are two ways of encrypting data:

  • Symmetric Encryption is a process that uses one encryption key for encrypting and decrypting messages, and the key is shared secretly between the sender and receiver. This method is widely used due to its high encryption speed, but the disadvantage is that we need a secure means to transfer the keys. If the hacker somehow gets the key, they can easily access our transmitted data. Symmetric Encryption is the most popular and widely used way to protect data.
  • Asymmetric Encryption is a process that requires two keys, namely public and private keys, for encrypting data. The public key is open to all and is transmitted through an open channel, while the Private key is only known to the recipient and is used for decrypting data. The advantage of this Encryption is that it is more reliable and secure than symmetric, whereas the drawback is that it takes more time.

General practices for MITM Attack Prevention

Specific ways by which we can probably prevent MITM Attacks are:

  1. By using Virtual Private Networks (VPN), we can prevent such attacks. VPNs are used within a local area network for creating a secure environment for sensitive information that is being used.
  2. Avoiding Public Networks while doing sensitive work involving high risks. Avoid using Public Networks while doing transactions, online banking, and other tasks which include sensitive details.
  3. Avoid using auto fill-ins on websites that are marked as unsecured. Never let any unsecured websites use your auto-filled usernames or passwords as it can be a high risk, and use multi-factor authentication wherever available.
  4. By installing proper Anti-Virus and securing the network with Network Intrusion Detection System.
  5. Always use Password Manager to protect your passwords.

Conclusion

MITM attack is a type of attack in which a Hacker places himself, in-between two users to steal and modify sensitive information. There are various ways a hacker can perform MITM attacks, such as WiFi-Eavesdropping, session hijacking, https spoofing, etc. We can use Encryption to prevent these attacks to some extent as encrypt messages are way more complex for anyone to read. Symmetric and Asymmetric Encryption are the two techniques by which we can ensure that the data transferred is protected. Following a set of instructions and some standard practices can somehow prevent us from being the target of these attacks.

Your Guide To Understanding Active Directory Certificate Services

Active Directory Certificate Services (AD CS) is one of the server roles introduced in Windows Server 2008 that provides users with customizable services for creating and managing Public Key Infrastructure (PKI) certificates, which can be used for encrypting and digitally signing electronic documents, emails, and messages.

The applications supported by AD CS are secure wireless networks, Virtual Private Networks (VPN), Internet Protocol Security (IPSec), Network Access Protection (NAP), Encrypting File Systems (EFS), smart card logon, and more.

Features

There are many features of AD CS, including:

  • Certificate Authority (CA):

     The Certificate Authority in AD CS is mainly concerned with managing and issuing public-key certificates. Multiple CAs can be linked to form a PKI. A typical PKI is a combination of software, hardware, standards, services, and policies to manage the digital certificates used in a PKI. A CA can be of two types:

    • Enterprise CA
    • Stand-alone CA

    The enterprise CA must be a domain member and can issue certificates for digital signatures, authentication to access protected web browsers, and can secure e-mail transactions. A stand-alone CA does not require Active Directory Domain Services, it can function offline. As a matter of fact, it should not even be connected to a network at all.

  • Certification Authority Web Enrollment

    The CA Web Enrollment in AD CS permits external clients, who are not part of the domain network, to connect to the CA via an Internet browser. CA Web Enrollment only supports interactive requests that the requester makes and uploads manually through the site. The certificate can be downloaded from the browser after the issuance of the certificate by the CA. This can also be used to request the Certificate Revocation List (CRL), which includes all the certificates expired or revoked within the PKI.

    In the case of users who are a part of the domain, the trust relationship allows the CA to issue certificates securely. Web enrollment allows the external clients to request certificates and revoke certificates from the CA. The enrollment could also be done across forests, which means the clients in one forest can obtain certificates from a CA in another forest. In order to use enrollment across forests, you must establish trust between all the involved forests, and the forest trust and forest level must be set to Windows Server 2008 R2, or other concerned versions.

  • Online Responder

    The Online Responder is a Microsoft Windows Service that runs on the OCSP server with Network service privileges. In AD CS, the online responder receives and processes requests regarding the status of the certificates. The validity of the certificate and digital signature is verified in order to identify whether the certificate is genuine or not. In addition to this, the certificate is checked to identify if it is a part of the Certificate Revocation List (CRL).

    Due to various reasons, the certificates can be revoked temporarily or can be stripped of their rights permanently before the certificate’s expiry period by the CA and such certificates are listed in the CRL. Apart from the CRL, revocation checking can also be done by the Online Certificate Status Protocol (OCSP) response. The OCSP checks the status of the website in question by sending the URL to the Certificate Authority. The Certificate Authority gives a signed response containing the requested certificate’s status.

  • Network Device Enrollment Service

    The Network Device Enrollment Service (NDES) is a function of AD CS that has the ability to issue certificates to network devices managing traffic such as routers, firewalls, and switches. These devices are not Active Directory domain members and therefore don’t possess exclusive Active Directory credentials. NDES enables one-time enrollment passwords for these network devices. These password requests are then sent to the CA for processing and the certificates obtained from the CA are forwarded to the device. Thus, NDES is used by the administrators for authentication of such networking devices.

  • Certificate Enrollment Web Service

    The Certificate Enrollment Web Service in AD CS permits users and computers to enroll and renew certificates using the HTTPS protocol. A non-enterprise member/user who is outside the security boundary of the domain can avail this service. The Certificate Enrollment Web Service focuses mainly on automated client requests and processes certificate requests with the help of a native client.

  • Certificate Enrollment Policy Web Service

    The Certificate Enrollment Policy Web Service in AD CS enables computers and users to retrieve information about their certificate enrollment policy. The certificate enrollment policy gives the precise location of the CAs and the types of certificates requested from them. Along with the Certificate Enrollment Web Service, this service will allow policy-based web enrollment to a non-enterprise client or member outside the domain. The enrollment policy can be enabled both by using group policy settings or by applying it individually to client computers. Thus, AD CS proves to be an efficient method for managing certificate infrastructure for any entity in a Windows domain network.

Enterprise PKI Services

Get complete end-to-end consultation support for all your PKI requirements!

Learn More

Benefits of Active Directory Certificate Services

AD CS can be used by organisations to enhance security by binding the identity of a person, device, or service to a corresponding private key. AD CS also gives enterprises a cost-effective, efficient, and secure way to manage the distribution and use of certificates.

AD CS provides an organization with the PKI required for using digital certificates to secure web servers (SSL/TLS), certificate-based authentication, digital signatures for documents, encrypting emails (S/MIME), etc. Without AD CS, an organization would have to rely on a third party to provide these services or forgo deploying certificates.

Downsides of Active Directory Certificate Services

  • It’s not an easy task deploying and dealing with a Microsoft CA. You will need a dedicated team with PKI experience in order for the implementation to go smoothly. After the setup, your team needs to stay updated with best PKI practices to maintain uptime and reliability.
  • It can be expensive with the overhead cost of hardware, deployment and maintenance by a team of experts.
  • AD CS has a binding issue with MAC OS devices.
  • XSS or Cross-site scripting attacks can happen in AD CS because the Web Enrollment does not properly sanitize user input, which means nothing checks the user input before it’s stored in a database. Unsanitized user input can also lead to SQL injections.

Conclusion

Active Directory Certificate Services or AD CS is used to establish an on-premises Public Key Infrastructure (PKI). It has the ability to create, validate and revoke public key certificates. These certificates have various uses such as encrypting files, emails, network traffic.

Is Your Organization Secure From DNS-Based Cyber Attacks?

Cybersecurity threats grow more complex every day, and one of the different types of attacks that are seen are DNS-based cyber-attacks. DNS-based cyber-attacks can come in a variety of different forms, from DNS spoofing, DNS hijacking, and DNS cache poisoning. These DNS-based attacks focus on redirecting a victim’s web traffic to either malicious webpages, like phishing webpages, or to fake web servers.

These types of attacks utilize Man in the Middle Attacks, DNS server hijacking, and DNS cache poisoning, via spam emails or other phishing methods, to implement these DNS attacks. To learn more about DNS-based attacks, we need to first learn about DNS in general and how it works.

Domain Name System (DNS)

The Domain Name System, or DNS, translates a domain into its corresponding Internet Protocol (IP) address. A domain is a text version of an IP address, connecting you to a website’s web server. This text version is meant to make web addresses easier to remember for humans. An example of a domain is www.google.com. An IP address is a string of numbers that uniquely identifies a computer or web server.

Working along with IP addresses and domains are DNS servers. These servers come in four types: resolving name server, root name servers, top-level domain name servers (TLD name servers), and an authoritative name server. Each of these types of DNS servers has a different function, but the most important one is the resolving name server. The resolving name server takes the IP address and queries a number of different web servers until it connects the user to the web server that they desire. 

The main process taken advantage of with DNS-based attacks is the method of DNS Lookup. DNS Lookup has several different steps

  1. The user’s web browser and Operating System (OS) work together to try and recall the IP address of the domain the user is attempting to reach. If the user has connected to the domain address previously, that IP address will most likely have been cached and allow the user to quickly connect to the domain address.
  2. If that IP address has not been previously cached, then it moves to the next step which is the OS querying the DNS resolving server. The resolving server queries web servers, until it reaches the required IP address it is attempting to find for the user.
  3. The resolver will then find the IP address, and send it back to the host OS, who then sends it to the user’s web browser.

DNS Lookup is the core of the Internet, providing everyone with access to the domains that they need to reach. This gives attackers a number of different methods to steal data, such as Man in the Middle Attacks, phishing attempts, and DNS server hijacking.

Methods of DNS-Based Attacks

DNS-based attacks, like I mentioned, can be done through a number of different methods, and the most common method is a Man in the Middle attack. The way a Man in the Middle attack works is that a threat actor will intercept messages between a victim and server they are attempting to reach. Those messages, whether they are encrypted or not, will be collected by the attacker and they will read the messages if they aren’t encrypted, or they will attempt to decrypt them and then read the messages. This attack is not that complicated to implement, which is one of the reasons it is done most commonly.

Another method threat actors use for DNS-based attacks is phishing attempts. Phishing via spam is used to trick victims into heading to illegitimate web pages with malicious URLs that the victims then click. Once that malicious URL is clicked, a malware payload containing anything from spyware to DNS cache poisoning tools can be downloaded to the victim machine. Many different phishing methods exist, with spam emails containing the malicious links being the one most often used for DNS cache poisoning. When dealing with DNS cache poisoning, which we will discuss more later, your web browser’s attempts to access webpages will be redirected to spoofed or false webpage that seem legitimate. 

One other method used for DNS-based attacks is DNS server hijacking. DNS server hijacking involves the hijacker redirecting the targeted web server to either spoofed or false webpages.  This attack method injects a false DNS entry into the server, which then redirects those victims to the desired false webpage. Now that we know how DNS-based cyber attacks occur, we can take at what those types of attacks are, how they work, and the types of data that they target.

Tailored Encryption Services

We assess, strategize & implement encryption strategies and solutions.

Learn More

DNS Attacks

The first type of DNS attack we will discuss is DNS spoofing. Spoofing is the idea of faking a communication between two different points. These two points are normally a client and server, or a sender and recipient. With DNS spoofing, this is where a DNS entry, like I mentioned previously, is spoofed with a false DNS entry. This means that when a client has a spoofed DNS entry, any time it attempts to access that domain name from that web server, it will be sent to a completely different, malicious web address. This will then allow the threat actors to implement malware payloads onto the victim devices.

The next type of DNS attack is a DNS cache poisoning attack. These types of attack are similar to DNS spoofing, except instead of targeting the DNS entry, the DNS cache is instead the target. What happens is a more directed attack is carried out in an attempt to replace the DNS cache responses with false DNS responses. Usually, DNS cache poisoning is done by sending a large number of fake DNS responses to the recursive server, and changing the query on each message until the targeted value’s ID is guessed correctly.

Protecting against these sorts of attacks are difficult, while the payoff for a successful attack is huge for threat actors. If a big-name DNS server relating to a commonly used domain name, like google.com, can be successfully poisoned, then thousands or even hundreds of thousands of victims could be infected.

Conclusion

As you can see DNS-based are common, can be undergone with relative ease, and can lead to a big payoff for threat actors if they are successful. A number of different methods can be used for protection against DNS-based attacks, but they are not the perfect defense. DNSSEC is a tool that can guard against these types of attacks, especially against DNS cache poisoning. Getting organizations, like Encryption Consulting, to do encryption, PKI, or HSM assessments to check for any types of gaps that may be in place in your IT infrastructure. To learn more about Encryption Consulting’s assessments, training, or implementation, visit our website at www.encryptionconsulting.com.

What goes into Developing an Enterprise Encryption Policy?

An Enterprise Encryption Policy is vital to the security of an organization. This policy provides a uniform way of ensuring encryption best practices are properly implemented throughout your organization. Additionally, a strong Enterprise Encryption Policy can be tailored to the encryption strategy your organization has created, giving you an organization-specific solution to your encryption gaps.

Creating an encryption policy takes a lot of planning and organization, to properly implement. Your Enterprise Encryption Policy will likely suggest different tools to be used for data encryption, like code signing solutions, to give your data the security it deserves.

Encryption Basics

The first step to designing a strong Enterprise Encryption Policy is to ensure you understand the basics of encryption. There are two different types of encryption methods: asymmetric and symmetric encryption. Symmetric encryption utilizes one key when encrypting data. This means both the person encrypting data and the person decrypting data use the same key.

The initial plaintext data is encrypted with the symmetric key and turned into ciphertext. This ciphertext is then decrypted later with the same key used to encrypt it, thus reproducing the plaintext. The key should be securely transmitted to both the person decrypting and encrypting the data, as only those individuals who need to encrypt or decrypt the data should access to the key.

If the security of the key is improperly handled, then a malicious threat actor could steal the plaintext data and use it for unwanted purposes.

The other type of encryption is asymmetric encryption. This mode of encryption deals with an encryption key pair as opposed to a single encryption key.  The key pair is created with a public and private key. As their names suggest, the public key is available to anyone while the private key is known only to the key pair creator. This key pair is mathematically linked, such that if the private key or public key encrypts any plaintext, the other key is able to decrypt the resulting ciphertext.

The way the asymmetric encryption process works with data-in-transit is that the sender of the data encrypts the data with the private key of their key pair. The public key is then sent along to the recipient of the data who uses that public key to decrypt the data. Since these keys are linked, the recipient knows that the data is actually from the person they think it is from. In this way, asymmetric encryption provides a valid way to authenticate that the data-in-transit has not been changed and to validate the identity of the data sender.

Now, one final component of encryption we should understand is the different states data can be in, which include data-in-transit/data-in-motion, data-at-rest, and data-in-use:

Now that we understand the basics of encryption, let’s take a look at what you need to consider when developing an Enterprise Encryption Policy Strategy.

What to Consider when Strategizing?

Strategizing for the development of an Enterprise Encryption Policy is an extremely important step in actually developing the Policy. There are a number of different points to consider when strategizing for your Enterprise Encryption Policy, which begins with collaboration. An organization creating a Policy should work with every team that may be included in this policy or who may have useful information for the Policy. This includes compliance teams, as they will be able to help determine what types of data must be discovered and classified, as well as what methods for encryption or key protection are necessary.

The other stakeholders included in this project can also assist in connecting this policy to other policies already in place in your organization, such as key protection policies. The teams actually implementing the Enterprise Encryption Policy controls should also be included in the strategizing process.

The next step to consider when strategizing for your Enterprise Encryption Policy creation is classifying data. Using the compliance team’s knowledge, you should determine what the different standards and compliance regulations you need to follow are, as that will tell your organization if or what data must be classified and how that data should be protected. To classify data, an organization must sift through all their data to determine the different types of data they are storing. If certain types of data, like Social Security Numbers, phone numbers, or addresses, are stored or utilized in some way, then that data must be protected.

Once data is classified, it makes it much easier to protect via encryption, tokenization, or other methods. Data is normally classified in 1 of 4 different ways. Public is the first classification level, which is data that is open to the public or will be open to the public. If this data is lost or stolen, it does not cause any issues, as it is publicly known.

The second level is Business Use, which is data that is used in day-to-day business use cases. This is the classification level of most data, and while it would be a hinderance to loss it, it would not cripple your organization. The third level is Confidential data, which is data that less people have access to and that would cause a competitive advantage to be lost if it were leaked. Finally, there is Restricted data, which is the least accessible information in the organization.

Tailored Encryption Services

We assess, strategize & implement encryption strategies and solutions.

Learn More

Restricted data could cause millions of dollars in revenue loss if it were leaked, and could end up leading to law suits if that data is lost or stolen.

Another key point to strategize for when creating your organization’s policy is roles and access control of data. Ensuring only those who need access to certain data is very important to data security, as allowing someone to access restricted data who should not be able to could leave to data being stolen or lost that is vital to the organization. You can implement proper access control by assigning roles to users. These roles can be based off data classification levels, job title, or even the section of a company a user works in. That means someone could have a restricted data role, a sales associate role, or a human resources role respectively.

Another important point to consider with access control is segregation of duties. Segregation of duties is the idea that multiple people are needed to complete a certain task, so if someone requests access to restricted data, one or more approvers would have to allow them access to that data before they could actually access and use the restricted data. This offers more chances to stop a potential insider threat, as there would have to be multiple people in on the insider threat to steal data.

Now, one of the keys when creating a strategy for your policy, you must consider the types of encryption you want to put in place. These can vary based on the compliance regulations and standards your organization is required to follow and the level of security you desire to implement in your IT infrastructure. Every organization should strive to have the strongest possible encryption and security in place that does not cripple or slow their operations.

Your company can utilize any kind of encryption algorithm, but ensuring data is protected in all formats is key. If data is only protected in motion, then data can be compromised either at rest or in use. Also, keep track of the National Institute of Science and Technology’s (NIST’s) updates to regulations and standards, as these provide organizations with the best possible practices to follow to ensure they are using the strongest encryption algorithms, key lengths, etc.

Your enterprise can manage your different encryption methods either manually, or with Enterprise Encryption Platform Services, like MicroFocus or Protegrity. This should also you help you determine the next step in your strategy, which is encryption key management.

Encryption key management is arguably the most important part of your encryption strategy, as many of the most recent supply chain attacks have shown. The first target a threat actor will try and find is the private key of the asymmetric encryption key pair. 

Now, keys can be stored in a variety of places, but not all of them are secure. Some organizations store their keys in plaintext on their devices, which is the least secure method of storing keys. Software based key security is available, but this is still not the best practice, as these keys are still prone to being stolen.

The best practice, as purported by the NIST, is to use Federal Information Processing Standards (FIPS) validated Hardware Security Modules, as they provide the most secure method of protecting encryption keys, or keys of any type. FIPS validated HSMs can range from FIPS 140-2 Level 1 to Level 4. Level 1 provides the least amount of security, requiring a working encryption algorithm of any type and production-grade equipment. Level 2 takes all of level 1’s requirements and adds role-based authentication, tamper evident physical devices, and an Operating System approved by Common Criteria at EAL2.

The majority of organizations tend to use a FIPS 140-2 level 3 HSM, as it provides all of level 2’s requirements, and adds tamper-resistant devices, a separation of the logical and physical interfaces that have “critical security parameters” enter or leave the system, and identity-based authentication. Private keys leaving or entering the system must also be encrypted before they can be moved to or from the system. The final level, level 4, requires everything in level 3 along with the ability of the device to be tamper active and that the contents of the device be able to be erased if certain environmental attacks are detected.

Tailored Encryption Services

We assess, strategize & implement encryption strategies and solutions.

Learn More

The final part of a strong strategy for creating your Enterprise Encryption Policy should be determining what solutions you want to implement. These can range from certificate management solutions, enterprise encryption platform services, code signing solutions, key management solutions, and Public Key Infrastructures. Choosing the right solution for your organization is extremely important, as you will have many different business needs that need to be met by these solutions.

Choosing the best solution can be difficult, but focusing on the different compliance standards you must follow, as well as the best practices put forth by NIST standards, will give your enterprise the best possible solutions to meet the project requirements. Now that we’ve developed a strategy for your Enterprise Encryption Policy, let’s see what the key components of that policy are.

Key Enterprise Encryption Policy Areas

  • Encryption Technical Standards:

    The encryption technical standards portion of the Enterprise Encryption Policy deals with the technical details of the different keys, encryption algorithms, etc. for the enterprise. This section includes key length, key strength, key types, and other technical key details. The strength of the encryption algorithms used, the types of encryption algorithms used, and the strength of any ciphers used are all additional portions of the encryption technical standards. The point of this policy area is to ensure that there is uniformity between all business units within the enterprise, with respect to the keys and other aspects of encryption.

  • Data to Encrypt:

    This policy area is meant to deal with the idea of what data needs to be encrypted why. This works with data classification methods, data classification policies, and other data identification methods. Data can be classified into a number of different categories, and an example of this can be found in the what to consider when strategizing section of this document.

  • What Stage to Encrypt at:

    This deals with the different types of data and where to encrypt data at. In this policy area, you should determine the best solutions to encrypting data-at-rest, data-in-motion, and data-in-use. These solutions can be determined based on the compliance standards and best practices that your organization must follow.

  • Key Protection:

    This policy area handles the strength of keys and how those keys are protected. The most common method is to follow NIST standards and have Multi-Factor Authentication in place for key storage and access. Additionally, tools like Hardware Security Modules secure encryption private keys in the strongest way possible.

  • Key Escrow:

    Key escrow refers to retrieving keys when legal reasons, like compliance audits, or disaster recovery. If an unforeseen disaster were to occur at your organization, and keys needed to be recovered or reset, then key escrow would need to be in place in the Enterprise Encryption Policy.

  • Training:

    Training is vital to an organization, as every team member and business unit should know how to access data, what data types they can access, how they should classify new data, and protect new encryption keys or data. As long as everyone knows how to access and handle data, they can work well within the organization.

  • Monitoring:

    Monitoring encryption and data throughout your enterprise is vital, as audit trail must be created, certificates and keys must be tracked, and strong access control must be in place.

Encryption Consulting Products and Services

If your organization is planning on creating a strong Enterprise Encryption Policy, Encryption Consulting can help. We offer a wide range of products and services that will help keep your enterprise secure. For our services, we offer encryption, Public Key Infrastructure (PKI), and Hardware Security Module (HSM) assessment, design, and implementation services for your organization.

We can also train your employees on the use of HSMs, PKI, and Amazon Web Services. We also provide a code signing solution, CodeSign Secure 3.0, which has monitoring, virus/malware scanning, and Multi-Factor Authentication, among other tools. Our PKI-as-a-Service is another great way to have a strong Enterprise Encryption Policy, without the need to manage every part of the PKI. If you have any questions about Encryption Consulting’s services or products, please visit our website at www.encryptionconsulting.com .

How PKI-as-a-Service (PKIaaS) Secures Remote Working?

In this discussion whiteboard, let us understand what is PKI? What are several components involved in Public Key Infrastructure (PKI)? Most importantly, how the recent global pandemic situation across the world is forcing companies to prefer remote working facilities and this in turn is posing a lot of threat for firm’s sensitive data. To secure the sensitive data, we need to understand how to scale the Public Key Infrastructure remotely in order to defend various data breach attacks. What is Public Key Infrastructure as a Service (PKIaaS)? What are the benefits of using PKIaaS and how will it secure the data stored/used remotely? Let’s get into the topic:

Global Pandemic in 2020 has thrown new challenges to the world not only in terms of medical and health parameters but also for many businesses. Firms has to move their working conditions from offline to online. Employees has to work remotely to meet the business needs. With employees working remotely there are high chances of facing cyber security attacks and data leakage. Public Key Infrastructure (PKI) plays a crucial role in providing cyber security to the sensitive data residing across the globe with remotely working employees.

Is still Cyber security practices such as Public Key Infrastructure still relevant during COVID-19 Pandemic Era?

To answer this question we need to understand the findings from the survey conducted by PwC to understand the financial measures CFOs are considering during COVID-19 global pandemic to reduce the business impact and continue sustainability. One of the interesting reveal from this survey is that out of all the CFOs responded to the survey 67% are considering to cancel or defer the planned investments to reduce the financial burden on the firms.

Out of the 67%, only as low as 2% are considering to cut the planned activities in Cyber security and rest are not willing to slide down the budget on data protection. This clearly indicates the importance of Cyber security especially encryption, PKI during pandemic situation where data is spread across places as many of the employees are working from remote locations. 

What made Cyber Security especially Public Key Infrastructure (PKI) critical during COVID-19?

It is a well-known fact that Cyber Security is always critical to any firm with sensitive data even before the COVID-19 pandemic hit the globe. During the COVID-19 pandemic crisis, this aspect of cyber security became even more critical with employees handling sensitive data are all over the world working remotely. This complicates process of tracking down the sensitive data (at rest, in transit and in use) and protecting it.

So, handling Public Key Infrastructure (PKI) remotely became critical for the revocation of short lived certificates and managing the existing live certificates. Also, managing PKI remotely is highly critical for compliance purpose as there might be huge penalties companies has to face for non-compliance to several international standards. Public Key Infrastructure (PKI) can be leveraged for protecting and performing email, VPN, user authentication and website certificates management. PKI has become a business critical asset during the COVID-19 global pandemic in Cyber Security domain.

What is Public Key Infrastructure – PKI?

PKI or Public Key Infrastructure is cyber security technology framework which protects the client – server communications. Certificates are used for authenticating the communication between client and server. PKI also uses X.509 certificates and Public keys for providing end-to-end encryption.

In this way, both server and client can ensure trust on each other and check the authenticity for proving the integrity of the transaction. With the increase in digital transformation across the globe, it is highly critical to use Public Key Infrastructure for ensuring safe and secure transactions. PKI has vast use cases across several sectors and industries including Medical and Finance.

What are important components in Public Key Infrastructure – PKI?

There are three key components: Digital Certificates, Certificate Authority, and Registration Authority. PKI can protect the environment using the three critical components. These components play a crucial role in protecting and securing digital communications, electronic transactions.

  • Digital Certificates:

    Most critical component in Public Key Infrastructure (PKI) is Digital certificates. These certificates are used to validate and identify the connections between server and client. This way, the connections formed are very secure and trusted. Certificates can be created individually depending on the scale of operations. If the requirement is for a large firm, PKI digital certificates can be purchased from trusted third party issuers.

  • Certificate Authority:

    Certificate Authority (CA) provides authentication and safeguards trust for the certificates used by the users. Whether it might be individual computer systems or servers, Certificate Authority ensures digital identities of the users is authenticated. Digital certificates issued through certificate authorities are trusted by devices.

  • Registration Authority:

    Registration Authority (RA) is an approved component by Certificate Authority for issuing certificates for authenticated users based requests. RA certificate requests ranges from individual digital certificate to sign email messages to companies planning to setup their own private certificate authority. RA sends all the approved requests to CA for certificate processing.

Enterprise PKI Services

Get complete end-to-end consultation support for all your PKI requirements!

Learn More

Why should firms worry about scaling PKI remotely?

COVID-19 has not only created health crisis across the globe but also created a havoc in cyber space creating cyber pandemic. There is multi-fold increase in the number of cyber-attacks right from the start of the COVID-19 pandemic. Cyber-criminals are exploiting the current situation of remote working facility of employees and newly deployed remote access solutions for cyber-attacks. Numbers suggest that during the initial days of global pandemic there is an increase in volume of cyber-attacks by 33%. Recent attacks on one of the largest gas pipeline and Meat supplier suggest that even major firm with huge infrastructure is no exception for these attacks.

Why to use Public Key Infrastructure – PKI?

There are several good traditional cyber security mechanisms such as multi-factor authentication and password based protection implemented for securing the sensitive data in remotely. But these techniques are now not fool proof with cyber criminals easily manipulating the mentioned mechanisms and breaching the secured walls. Cybercriminals are able to breach these techniques and many cyber security research organizations are suggesting to move away from these approaches. Leveraging Public Key Infrastructure (PKI) to implement certificate based authentication provides better enhanced security for sensitive data when compared to the traditional approaches.

PKIaaS – Public Key Infrastructure as a Service

Public Key Infrastructure as a Service (PKIaaS) is a cloud based security service enabling cyber security across the globe. PKIaaS adapts to multiple security scenarios and can be quickly deployed for remote working. An on-demand PKIaaS solution can significantly reduce those costs and keep them under control. Public Key Infrastructure (PKI) can provide a better and stronger security standards when compared with password based protection or multi-factor authentication which are currently in use for protecting the sensitive data.

As several research firms such as Forrester and Gartner says, it is always preferred to go with “Zero Trust Security Model” to reduce the risk exposure of your business and employees. PKI can be one of the founding layers in achieving “Zero Trust” strategy. There are three critical steps that can be followed by your organization to scale Public Key Infrastructure as a Service (PKIaaS) remotely to protect the data spread across places.

Why to use PKI as a Service – PKIaaS?

PKI as a Service (PKIaaS) is a cloud based cyber security provision to protect sensitive data. Firms will have the option to choose either on premise PKI setup or PKIaaS cloud or Hybrid model involving both on premise and Cloud Public Key Infrastructure.  So, why should firms choose PKIaaS for their key management and lifecycle? There are three important benefits:

  • Efficiency

    Eliminate software and hardware investment costs and opt for a custom-built pay-as-you-scale service.

  • Scalability

    Scale from zero to millions of certificates on-demand, and expand your PKI’s scope to other systems (IoT, DevOps, Cloud etc.) using our library of pre-built integrations.

  • Security

    PKIaaS is set up with high security in compliance with Cyber regulations and standards. Firms will retain the full control over the root certificate Authority (CA) and management system.

Enterprise PKI Services

Get complete end-to-end consultation support for all your PKI requirements!

Learn More

Critical steps involved in PKI as a Service (PKIaaS)

PKI as a Service (PKIaaS) became highly critical for the firms dealing with sensitive data remotely. It is easy to setup PKIaaS and can be scaled as per the requirement of the firm.

  1. PKI certificate based authentication to replace traditional password based protection.
  2. PKI certificate authentication to replace traditional multi-factor authentication.
  3. Automation of identity certificate management.

PKI Certificate based authentication vs Password based protection

As per the “Data Breach Investigations 2019 report by Verizon”, 62% of breaches are caused by either phishing, stolen credentials, or brute force. From this research data we can deduce that majority of the data breaches involved password leakage either willingly or by accident or through several hacking techniques such as brute force attack which makes this protection technique more vulnerable. 

On the other hand, PKI-based user identity certificates used in certificate based authentication can be considered as one of the strongest form of identity authentication. This also eases out the process for employees where they are not required to remember and update the passwords frequently. In certificate based authentication digital certificates are used for user authentication. 

Reasons why PKI based authentication is better​:

  • Private Key is used for authentication which can always resides on client environment.
  • Private Key/Certificates cannot be stolen in transit or at rest (in server repositories).
  • Unlike passwords, digital certificates would take several years to decrypt using brute force attacks.
  • There is no requirement to remember or frequently change digital certificates like passwords.

PKI certificate authentication vs Traditional multi factor authentication

It is a known fact that multi factor authentication either via hardware token device or mobile SMS/call based authentication will provide additional security when compared to only using password based protection. Unfortunately, this is a cumbersome process for employees as there are extra steps involved in going through authentication cycle. PKI certificate based authentication will help in eliminating this extra step and still be able to provide better and stronger data security. 

Advantages of using PKI authentication over traditional multi factor authentication are:

  • Employees need not worry about carrying and securing extra hardware token or devices for additional security.
  • Extra step of entering secure token ID or One time password (OTP) can be avoided.
  • Devices connected can be trusted and authenticated.
  • Using PKI certificate authentication you can achieve several use cases and for multiple entities such as users, machines and devices (mobile).

Using PKI, you can satisfy multiple use cases such as user authentication, machine authentication, windows logon, accessing corporate emails, VPN access to name a few.

Automation of identity certificate management using PKIaaS

Final step in scaling PKI remotely through PKIaaS is to automate the process of certificate management. This will reduce the burden on IT staff by eliminating the technical intensive process of certificate deployment, renewal and revocation process. This will help in quickly replacing or revoking certificates by IT staff.

Benefits of automating certificate lifecycle:

  • Certificate discovery

    Performing discover activity to identify certificates in use across the business landscape.

  • Certificate Deployment

    Automated issuance of certificates and installation.

  • Certificate Review

    Automatically renew the certificates wherever necessary and revoke them if expired.

Encryption Consulting’s Managed PKI

Encryption Consulting LLC (EC) will completely offload the Public Key Infrastructure environment, which means EC will take care of building the PKI infrastructure to lead and manage the PKI environment (on-premises, PKI in the cloud, cloud-based hybrid PKI infrastructure) of your organization.

Encryption Consulting will deploy and support your PKI using a fully developed and tested set of procedures and audited processes. Admin rights to your Active Directory will not be required and control over your PKI and its associated business processes will always remain with you. Furthermore, for security reasons the CA keys will be held in FIPS140-2 Level 3 HSMs hosted either in in your secure datacentre or in our Encryption Consulting datacentre in Dallas, Texas.

Get familiar with the new concept of Crypto-Shredding

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.

Tailored Cloud Key Management Services

Get flexible and customizable consultation services that align with your cloud requirements.

Learn More

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:

  1. 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.
  2. Since the crypto-shredding deletes the keys only, the encrypted data still exists, and that would require the management of storage in your environment.
  3. 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. 

Resources

NIST.SP.800-88r1

Why does every developer need to know about Code Signing?

In this discussion whiteboard, we will be discussing about what is Code Signing process? What are the benefits of using Code Signing certificates for your software/code security? What makes the Code Signing certificates the best security solution for developers. Let’s get into the topic:

With the increase in penetration of mobile devices across the globe, there is a steep increase in demand for Cybersecurity. The enhancement in mobile and internet infrastructure and advancements in technology across the globe is propelling the adoption of smart devices among enterprises and consumers. At the same time, enterprises are rapidly embracing cloud platforms and other networking technologies. Because of these advancements, companies are becoming more vulnerable to various cyber-attacks.

In 2017, cyber-attacks on mobile devices increased by over 40% with an average of over 1.2 million attacks per month. Hence, cyber security modules such as cryptography, Data Loss Prevention became more and more critical for the end-users and organizations dealing with sensitive data. The global cybersecurity market is set to grow from its market value of more than $120 billion in 2019 to over $300 billion by 2024. The cybersecurity market is propelled by the increasing need among enterprises to minimize security risks.

Studies have shown that at least 93% of all mobile transactions were blocked in 2019 as they were fraudulent. It is necessary to enthuse a sense of trust in your customers that the software they are downloading is safe. It is also the reason why you must buy a code signing certificate.

All these factors combined contributed to the growth in demand for cybersecurity especially Code Signing certificates. Code signing certificates provide confidence and trust to end users on the code/software programs developed by the tech firms.

What is a Code Signing process?

Code signing is a process to confirm the authenticity and originality of digital information such as a piece of software code. It assures users that this digital information is valid and establishes the legitimacy of the author. Code signing also ensures that this piece of digital information has not changed or been revoked after it was validly signed.

Code Signing plays an important role as it can enable the identification of legitimate software versus malware or rogue code. Digitally signed code ensures that the software running on computers and devices is trusted and unmodified.

Software powers your organization and reflects the true value of your business. Protecting the software with a robust code signing process is vital without limiting access to the code, assuring this digital information is not malicious code and establishing the legitimacy of the author.

Encryption Consulting’s (EC) CodeSign Secure platform

Encryption consulting (EC) CodeSign secure platform provides you with the facility to sign your software code and programs digitally. Hardware security modules (HSMs) store all the private keys used for code signing and other digital signatures of your organization. Organizations leveraging CodeSign Secure platform by EC can enjoy the following benefits:

  • Easy integration with leading Hardware Security Module (HSM) vendors.
  • Authorized users only access to the platform.
  • Key management service to avoid any unsafe storage of keys.
  • Enhanced performance by eliminating any bottlenecks caused.

Why to use EC’s CodeSign Secure platform?

There are several benefits of using Encryption consulting’s CodeSign Secure for performing your code sign operations. CodeSign Secure helps customers stay ahead of the curve by providing a secure Code Signing solution with tamper-proof storage for the keys and complete visibility and control of Code Signing activities.

The private keys of the code-signing certificate can be stored in an HSM to eliminate the risks associated with stolen, corrupted, or misused keys. Client-side hashing ensures build performance and avoids unnecessary movement of files to provide a greater level of security. Client-side hashing ensures build performance and avoids unnecessary movement of files to provide a greater level of security. Client-side hashing ensures build performance and avoids unnecessary movement of files to provide a greater level of security.

Seamless authentication is provided to code signing clients via CodeSign Secure platform to make use of state-of-the-art security features including client-side hashing, multi-factor authentication, device authentication, and as well as multi-tier approvers workflows, and more.

Support for InfoSec policies to improve adoption of the solution and enable different business teams to have their own workflow for Code Signing. CodeSign Secure is embedded with a state-of-the-art client-side hash signing mechanism resulting in less data travelling over the network, making it a highly efficient Code Signing system for the complex cryptographic operations occurring in the HSM.

Enterprise Code-Signing Solution

Get One solution for all your software code-signing cryptographic needs with our code-signing solution.

Book a Demo

Code Signing process for developers

Code signing process also leverages the principle of public key cryptography (especially PKI). When a developer wants to perform code signing then he/she are actually pinning a digital cryptographic certificate to the piece of code or software program. There are two critical steps involved in the code signing process: 

  1. Encryption
  2. Hashing

As a first step, a unique private key needs to be generated by the developer that can be used to encrypt the information. According to the concept of public key cryptography, a private-public key pair is a set of encryption mechanisms to perform encryption/decryption.

Once the key pair has been generated, the public key is sent to a trusted issuing body called a Certificate Authority (CA) which verifies the developer’s authenticity, and then attaches their public key with a digitally signed certificate which is the developer’s proof that they are the rightful owner of the key. This certificate is the code-signing certificate in question. The CA sends the public key along with the certificate back to the developer who requested it.

As we have both the code-signing certificate and an encryption key pair, developer must leverage these certificate and key pair to hash the software’s code before they can encrypt and sign it. Hashing is a procedure in which a hash function is used to convert code into an arbitrary fixed value. The output of hashing, called a digest, is then encrypted using the private key. Next, the developer combines this digest with the code-signing certificate and the hash function to create something called a signature block, which is essentially all the above items combined into a piece of code that can be conveniently inserted into software.

Once the developer injects the signature block into the software, it is effectively code-signed, and can be distributed.

What are the benefits of Code Signing for developers?

Code signing is one of the safest process which provides maximum security for the software and code. This is the very aspect which makes code signing a highly sort after process for developers as well as tech firms. Let us understand some of the important benefits of using code signing for securing your code/software. Encryption consulting provides CodeSign Secure platform to perform the code signing activity. You would be able to protect the firm’s unique code and software programs by performing code signing process using this platform.

Protects code integrity

Code signing provides authentication to the code and/or software programs integrity using hash function. If the hash used to sign the application matches the hash on a downloaded application, the code integrity is intact. If the hash used does not match, users experience a security warning or the code fails to download.

Code Signing Certificates include an optional timestamp to extend the life of your digital signatures. Your code will remain valid even if your code signing certificate expires, because the validity of the code signing certificate at the time of the digital signature can be verified.

Streamlined security of the code

When your code/software programs are integrated with code signing portals using API integration. Encryption consulting’s Code Sign secure will make the process of code signing easy to manage and integrate with your code. Streamlined security helps you get to market faster while protecting the integrity of your code and reducing security warnings.

Minimize security warnings through trusted Certificate Authority

Code signing process creates and establishes trust as certificates from trusted Certificate Authority (CA) is leveraged. Root certificates of trusted and reputed certificates authorities will be installed on the client host machines. So, it is always advised to use standard Code signing providers such as CodeSign Secure. When you use code signing, your code is automatically accepted without any security warnings. This will pave way for seamless download of the software or code. With minimum security warnings, there will be better ease of usage for the end user.

Encryption Consulting’s CodeSign Secure platform use cases for developers

There are multiple use cases that can be implemented using CodeSign Secure platform by Encryption Consulting. Majority of the use cases can be relevant to digital signature concept discuss above. CodeSign Secure platform will cater to all round requirements of your organization. Let us look into some of the major use cases covered under Encryption Consulting’s CodeSign Secure:

  • Code Signing:

    Sign code from any platform, including Apple, Microsoft, Linux, and much more.

  • Document Signing:

    Digitally sign documents using keys that are secured in your HSMs.

  • Docker Image Signing:

    Digital fingerprinting to docker images while storing keys in HSMs.

  • Firmware Code Signing:

    Sign any type of firmware binaries to authenticate the manufacturer to avoid firmware code tampering.

Organizations with sensitive data, patented code/programs can benefit from CodeSign Secure platform. Online distribution of the software is becoming de-facto today considering the speed to market, reduced costs, scale, and efficiency advantages over traditional software distribution channels such as retail stores or software CDs shipped to customers.

Code signing is a must for online distribution. For example, third party software publishing platforms increasingly require applications (both desktop as well as mobile) to be signed before agreeing to publish them. Even if you are able to reach a large number of users, without code signing, the warnings shown during download and install of unsigned software are often enough to discourage the user from proceeding with the download and install.

Encryption Consulting will provide strongly secured keys in FIPS certified encrypted storage systems (HSMs) during the code signing operation. Faster code signing process can be achieved through CodeSign secure as the signing occurs locally in the build machine. Reporting and auditing features for full visibility on all private key access and usage to InfoSec and compliance teams.

Enterprise Code-Signing Solution

Get One solution for all your software code-signing cryptographic needs with our code-signing solution.

Book a Demo

Encryption Consulting’s PKI complete package

Encryption Consulting LLC (EC) is offering a complete all-round package on training for Public Key Infrastructure (PKI). This PKI course can be taken by candidate who is at any level – be it a beginner, intermediate level or advanced level. PKI course is recommended for anyone using or managing certificates, designing or deploying a PKI enterprise solution, or evaluating & selecting a commercial PKI Technology Solution.

Planning a Public Key Infrastructure (PKI) can have a significant skill ceiling, as an organization’s authentication, encryption, and digital signing can depend on how the PKI is built. An organization needs a robust and secure PKI infrastructure to ensure security and privacy and meet regulations and compliance. Creating and managing a PKI requires ample knowledge about it, which Encryption Consulting brings along with the experience needed for organizations to have a custom solution for their needs.

In our three days, PKI Training delivered online, In-person focusing on Microsoft Active Directory Certificate Service (ADCS) Training, customers will learn how to deploy or design PKI solutions in the enterprise.

You will learn how to build a PKI on Windows Server 2019, focusing on areas such as integration with HSM, Two-tier PKI, Cloud PKI, and more.

There is a strong emphasis on: PKI Governance, PKI Design best practices, Certificate Lifecycle Management process and PKI operations and hands-on skills lab.

Difference between various Public Key Infrastructure (PKIs)

PKI, the abbreviation for Public Key Infrastructure, is a set of roles, procedures, and policies needed to create, distribute, manage, use, and revoke digital certificates and manage public-key encryption. PKI is used to confirm the identity of a user by providing ownership of a private key. It is a trusted service to verify that a sender or receiver of data is exactly who they claim to be.

PKI is built around components and procedures for managing the key pairs (public and private key pairs).

A typical PKI is made up of the following components:

  1. Certificate Authority (CA): A trusted CA is the only entity in PKI that can issue trusted digital certificates. CA accepts requests for certificates and verifies the information provided by the applicants based on certificate management policy. CA will sign the certificates with its private key and issue them to the applicants if the information is legal.
  2. Registration Authority (RA): RA is responsible for receiving certificate signing requests for the initial enrollment or renewal of certificates from users, servers, other applications. RA verifies the identity of an end-entity and forwards the request to a certificate authority (CA).
  3. Public Key: Public key can be distributed widely and does not require secure storage. Its corresponding private key can only decrypt messages/Data encrypted by the public key.
  4. Private Key: Private keys are used by the recipient to decrypt the message/data encrypted by its corresponding public key. This establishes the ownership of the private and public key pair, ensuring the message is only read by the approved parties
  5. Root Certificate Authority (Root CA): A certificate is considered valid when a trusted Root CA sign it. A Root CA is entitled to verify a person’s identity and signs the root certificate that is distributed to a user.
  6. Intermediate Certificate Authority: An Intermediate CA is also a trusted CA and is used as a chain between the root CA and the client certificate that the user enrolls for. Since the Root CA has signed and trusts the intermediate CA, certificates generated from the intermediate CA are also trusted.
  7. Hardware security module: A Hardware Security Module isn’t a mandatory component of a PKI, but it improves the security of the PKI when implemented. This device protects and manages digital keys and serves as the groundwork for building a secure enterprise PKI infrastructure. The HSM manages the complete lifecycle of cryptographic keys, including creation, rotation, deletion, auditing, and support for APIs to integrate with various applications.

Now we have a fair idea about some of the PKI components, let’s talk about different PKI vendors and their best practices:

Microsoft PKI

Below is few best practices that are recommended to use Microsoft PKI effectively.

  • Make a detailed plan of your PKI infrastructure before deployment.
  • Avoid installing ADCS on a domain controller.
  • Root CA should be standalone and offline.
  • Do not issue certificates to end-entity from a Root CA.
  • Enable auditing events for both Root and Issuing CA.
  • Secure the Private key with HSM (FIPS 140-2 level 3)
  • Install Enterprise CA only if your CA issues a certificate for devices or users.
  • It is not recommended to use default certificate templates.
  • CRL distribution point should be highly available.
  • Publish Root CA CRL to Active directory.
  • Hash Algorithm should be at least SHA-2 (SHA 256 bit).
  • The end-entity certificate validity period should be a maximum of 2 years.

AWS Certificate Manager

Here are the top 10 best practices we identified for AWS Certificate Manager (ACM):

  • ACM Certificate expiry check: Ensure removal of expired SSL/TLS certificates managed by ACM. This eliminates the risk of deploying an invalid SSL/TLS certificate in resources that trigger the front end. This might cause a loss of credibility for business as well.
  • ACM Certificate validity check: Ensure requests that arrive during the SSL/TLS certificate issue or renewal process are validated regularly.
  • Root Certificate Authority (CA) usage: It is always a best practice to minimize the use of Root CA. Amazon recommends creating a separate account for Root CA.
  • Transport layer protection is vital to ensure security. It is recommended to use only TLS version 1.1 or above and not use SSL as it is no longer secure.
  • Whenever you import certificates instead of ACM-issued certificates, ensure keys used to generate SSL/TLS certificate private keys have high key strength to avoid a data breach.
  • Avoid using wildcard domain certificates. Instead, try to issue ACM single domain certificate for each domain and subdomain with its own private key.
  • Allow usage of imported certificates only from authenticated and trusted partners of your organization in ACM. When wildcard certificates are imported into AWS Certificate Manager (ACM), security threat risk is high as the user might hold an unencrypted copy of the certificate’s private key.
  • Recommended best practice is to always use a Fully Qualified Domain Name (FQDN) in SSL/TLS ACM certificates.
  • To avoid misuse of generated certificates, perform frequent audits of AWS environment for trusted certificates and validate audit reports.
  • Turn on AWS CloudTrail and CloudWatch alarms: CloudTrail logging helps track the history of AWS API calls and monitor AWS deployments. CloudTrail can be integrated with applications for performing automated logging and monitoring activities. Enabling the CloudWatch alarm feature helps in alerting through notifications when configured metrics breach.

Enterprise PKI Services

Get complete end-to-end consultation support for all your PKI requirements!

Learn More

AWS ACM Private CA (ACM PCA)

Below are the recommended best practices that can help you use AWS ACM PCA more effectively.

  • AWS recommends documenting all your policies and practices for operating your CA, including CA hierarchy, architecture diagram, CA validation period policies, path length, etc.
    The CA structure and policies above can be captured in two documents known as Certificate Policy (CP) and Certificate Practice Statement (CPS). Refer to RFC 3647 for a framework for capturing important information about your CA operations.
  • Root CA should, in general, only be used to issue a certificate for intermediate CAs.
  • Creating a Root CA and Subordinate CA in two different AWS account is recommended best practice.
  • The CA administrator role should be separate from users who need access only to issue end-entity certificates.
  • Turn on CloudTrail logging before you create and start operating a private CA. With CloudTrail, you can retrieve a history of AWS API calls for your account to monitor your AWS deployments.
  • It is a best practice to update the private key for your private CA periodically. You can update a key by importing a new CA certificate or replacing the private CA with a new CA.
  • Delete the unused private CA permanently.
  • ACM Private CA recommends using the Amazon S3 Block Public Access (BPA) feature on buckets that contain CRLs. This avoids unnecessarily exposing details of your private PKI to potential enemies. BPA is an S3 best practice and is enabled by default on new buckets.

Google Cloud Certificate Authority Services

This topic outlines some of the best practices that can help you use Certificate Authority Service more effectively.

  • Role and access control: Individuals shouldn’t be assigned more than one role at any given time. Everyone holding an assigned role should be adequately briefed and trained on their responsibilities and security practices. If you want to assign a diverse set of permissions to an individual, it is recommended that you create a custom role using IAM.
  • In most cases, it is recommended to use the Enterprise tier to create a certificate authority (CA) pool that issues certificates to other CAs and end-entities.
  • While creating a CA pool, it is recommended to carefully consider the DevOps tier, as it does not support certificate revocation.
  • Secure CA signing keys by leveraging Cloud HSM.
  • Enable cloud audit logs to monitor access and use of Cloud HSM signing keys.
  • It is recommended not to import an existing external CA with issued certificates into CA service.
  • For a Root CA and Subordinate CA, it is recommended to use the most significant key size available for that algorithm family.
    • For RSA, the largest supported key size is 4096 bits.
    • For ECDSA, the largest supported key size is 384 bits.

    (For subordinate CAs with a shorter lifetime, it is sufficient to use smaller key sizes, such as 2048 bits for RSA or 256 bits for ECDSA.)

  • It is recommended that the authors of the certificate template grant the CA service user role to the members in the organization who might use that certificate template.
#CategoriesMicrosoft PKIAWS Certificate Manager (ACM)AWS ACM Private CA (ACM PCA)Google Cloud – Certificate Authority Services (CAS)
1Root CARoot CA is deployed on-premises and kept offlineAWS Certificate Manager is a service using which you can easily provision, manage and deploy public/private SSL/TLS certificates for use with AWS services and internal connected resources.Root CA can be deployed in AWS cloud or Issuing CA CSR can be Signed by the External Root CA.Root CA can be deployed in the google cloud – certificate authority services or Issuing CA CSR can be signed by the External Root CA.
2Certificate TemplateIt is not recommended to use the default Certificate template. Certificate templates can be configured.Use AWS CloudFormation templates to issue private certificates using AWS Certificate Manager (ACM).ACM Private CA supports four varieties of certificate template.

 

  1. Base template – pre-defined templates in which no passthrough parameters are allowed.
  2. CSRPassthrough templates – Templates that extend their corresponding base template versions by allowing CSR passthrough.
  3. APIPassthrough templates – Templates that extend their corresponding base template versions by allowing API passthrough.
  4. APICSRPassthrough templates – Templates that extend their corresponding base template versions by allowing both API and CSR passthrough.
A new Certificate template can be created in each project and location in Google cloud CAS service.
3key algorithm and Key SizeMicrosoft PKI supports the Key size as per NIST 800 standards. The minimum key size is 2048- bit. However, for any CA that has certificate expiration more than 15 years in the future, it is recommended to use RSA must be 4096 or greater or, if the CA key uses ECC, the CA key must use either the P-384 or P-521 curve.The following public key algorithms and key sizes are supported by ACM:
2048-bit RSA (RSA_2048)
3072-bit RSA (RSA_3072)
4096-bit RSA (RSA_4096)
Elliptic Prime Curve 256 bit (EC_prime256v1)
Elliptic Prime Curve 384 bit (EC_secp384r1)
Elliptic Prime Curve 384 bit (EC_secp384r1)		AWS ACM Private CA supports the following cryptographic algorithm and Key size for private key generation. With the advanced option, following algorithms are available: (This list applies only to certificates issued directly by ACM Private CA through its console, API, or command line.)

 

  • RSA 2048
  • RSA 4096
  • ECDSA P256
  • ECDSA P384
The following key algorithm and key size is used in Google cloud:

 

  • 2048-bit RSA (RSA_2048)
  • 3072-bit RSA (RSA_3072)
  • 4096-bit RSA (RSA_4096)
  • ECDSA P256
  • ECDSA P384

For a new root CA or a subordinate CA that is expected to have a lifetime in the order of years, google recommends that you use the largest key size available for that algorithm family. (For RSA, the largest supported key size is 4096 bits. and for ECDSA, the largest supported key size is 384 bits.)

4Hashing algorithmIt is recommended to use the advance hashing algorithm (SHA 256 and above) for the new deployment and the existing PKI.Certificates managed in AWS Certificate Manager use RSA keys with a 2048-bit modulus and SHA-256. ACM does not currently have the ability to manage other certificates such as ECDSA certificates.ACM Private CA supports the following certificate signing algorithm. This list applies only to certificates issued directly by ACM Private CA through its console, API, or command line.

 

  • SHA256WITHECDSA
  • SHA384WITHECDSA
  • SHA512WITHECDSA
  • SHA256WITHRSA
  • SHA384WITHRSA
  • SHA512WITHRSA
Google cloud certificate authority services supports SHA256, SHA384.
5RFC ComplianceCA Certificates within the Microsoft IT PKI shall be X.509 Version 3 and shall conform to the RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, dated May 2008. As applicable to the Certificate type, Certificates conform to the current version of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates.AWS Certificate Manager is responsible for protecting the infrastructure that runs AWS services in the AWS cloud. AWS also provides services that can be used securely. Third-party auditors regularly test and verify the effectiveness of the security as part of the AWS Compliance Programs (https://aws.amazon.com/compliance/programs/)Certain constraints appropriate to a private CA are enforced as per RFC 5280. However, ACM Private CA does not enforce all constraints defined in RFC 5280.Certificate Authority Service uses the ZLint tool to ensure that X.509 certificates are valid as per RFC 5280 rules. However, CA Service does not enforce all RFC 5280 requirements, and it is possible for a CA created using CA Service to issue a non-compliant certificate.
6CRL (Certificate Revocation List) Distribution pointMicrosoft PKI deposits the CRL under LDAP (Lightweight directory access protocol) and HTTP.AWS support centre can help to revoke a certificate in AWS Certificate Manager. You need to raise a support ticket/case for the same.ACM Private CA automatically deposits the CRL in the Amazon S3 bucket you designate.CRL Publication must be enabled on a CA pool for it to publish the CRL. CRL publication can be enabled during the creation of a CA pool.
7Storage of Private KeysIt is recommended to store the private keys in a FIPS 140-2 level 3 compliant HSMAWS certificate Manager stores the certificate and its corresponding private key and uses AWS Key Management Service (AWS KMS) to help protect the private key.By default, the private keys for private CAs are stored in AWS-managed hardware security model (HSMs). The HSMs comply with FIPS PUB 140-2 Security Requirements for Cryptographic Modules.CA keys are stored in Cloud HSM, FIPS 140-2 Level 3 validated and available in regions across the Americas, Europe, and the Asia Pacific.
8Audit reportsAuditing can be enabled on a CA in windows server to provide an audit log for all certificate services management tasks.AWS Certificate Manager (ACM) is integrated with AWS CloudTrail, a service that records actions taken by a user, role, or an AWS service in ACM. CloudTrail is enabled by default on your AWS account.Audit reports are created to list all the certificates that ACM private CA has issued or revoked. The report is saved in a new or existing specified S3 bucket.Cloud Audit logs can be used in Certificate Authority Services. Cloud Audit Logs provides the following audit logs for each Cloud project, folder, and organization:

 

  • Admin Activity audit logs
  • Data Access audit logs
  • System Event audit logs
  • Policy Denied audit logs
9Best Practices (high-level)
  1. Make a detailed plan of your PKI infrastructure before deployment.
  2. Avoid installing ADCS on a domain controller.
  3. Root CA should be standalone and offline.
  4. Do not issue certificates to end-entity from a Root CA.
  5. Enable auditing events for both Root and Issuing CA.
  6. Secure the Private key with HSM (FIPS 140-2 level 3)

(More details on the previous section)

ACM Certificate expiry check: Ensure removal of expired SSL/TLS certificates managed by ACM. This eliminates the risk of deploying an invalid SSL/TLS certificate in resources that trigger the front end. This might cause a loss of credibility for business as well.

 

  • ACM Certificate validity check: Ensure requests that arrive during the SSL/TLS certificate issue or renewal process are validated regularly.
  • Root Certificate Authority (CA) usage: It is always a best practice to minimize the use of Root CA. Amazon recommends creating a separate account for Root CA.
  • Transport layer protection is vital to ensure security. It is recommended to use only TLS version 1.1 or above and not use SSL as it is no longer secure.

(More details on the previous section)

Recommended best practices to use ACM PCA effectively:

 

  1. Documenting CA structure and Policies.
  2. Minimize use of Root CA.
  3. Give the Root CA its own AWS Account.
  4. Separate administrators and issuer roles.
  5. Turn on CloudTrail login.
  6. Rotate the CA private Key.
  7. Delete an unused CA (AWS bills you for a CA until it is deleted).
Role and access control: Individuals shouldn’t be assigned more than one role at any given time. Everyone holding an assigned role should be adequately briefed and trained on their responsibilities and security practices. If you want to assign a diverse set of permissions to an individual, it is recommended that you create a custom role using IAM.

 

  • In most cases, it is recommended to use the Enterprise tier to create a certificate authority (CA) pool that issues certificates to other CAs and end-entities.
  • While creating a CA pool, it is recommended to carefully consider the DevOps tier, as it does not support certificate revocation.

(More details on the previous section)

10CA hierarchyIn a hierarchical PKI (a typical deployment), there are generally three types of hierarchies – one-tier, two-tier, and three-tier.AWS Certificate Manager is a service using which you can easily provision, manage and deploy public/private SSL/TLS certificates with AWS services and internal connected resources.With ACM PCA, you can design and create a hierarchy of certificate authorities with up to five levels.When creating a subordinate CA that chains up to an external Root CA, the properties included in the CSR generated by CA Service must be preserved in the CA certificate signed by the external Root CA. The external CA can add additional extensions if it preserves the properties in the CSR. For example, the signed subordinate CA certificate must also include the same path length restriction if the CSR contains a path length restriction.
11Redundancy and Disaster RecoveryRedundancy and disaster recovery plans should be complete during a PKI deployment’s designing and implementation planning phase.ACM does not have an SLA. The ACM Private Certificate Authority managed private CA service has an SLA.ACM Private CA is available in multiple Regions, allowing the user to create redundant CAs. The ACM Private CA service operates with a service level agreement (SLA) of 99.9% availability.Google Cloud Certificate Authority services (CAS) are available in multiple regions, which allows redundancy. Google Cloud (CAS)operates with a service level agreement (SLA) of 99.9% availability.

Conclusion  

Public Key Infrastructure (PKI) plays a vital role in ensuring secure communication by utilizing digital certificates. The combination of key components like Certificate Authorities (CAs) and Registration Authorities (RAs) work together to authenticate entities and manage certificate lifecycles. By utilizing encryption through public and private key pairs, PKI ensures data confidentiality and authenticity, ensuring infrastructure security.

Different vendors provide tailored PKI solutions, each with different merits serving unique use cases. Microsoft PKI advocates for secure key management with offline Root CAs and Hardware Security Modules (HSMs). AWS Certificate Manager (ACM) offers automated certificate management, focusing on validation and security for cloud resources. Google Cloud’s Certificate Authority Service emphasizes role-based access control and the use of strong encryption keys. These vendor-specific recommendations ensure highly secure PKI deployment across various platforms and environments.

How can Encryption Consulting help?

At Encryption Consulting, we specialize in designing and migrating PKI infrastructures that align perfectly with your organization’s unique security needs. We provide comprehensive PKI design and implementation services for both existing and new PKI infrastructures. Our on-premises solutions include Microsoft PKI, while our cloud-based PKI solutions utilize leading cloud service providers such as AWS Certificate Manager, AWS Certificate Manager Private CA (ACM-PCA), Azure PKI, and Google Cloud Certificate Authority Manager.

Resources

PcaWelcome

Certificate Authority Service

Microsoft PKI Services CP