×

Eliminate blind spots in your SSL/TLS encrypted traffic.

Sign Up


    What goes into Developing an Enterprise Encryption Policy?

    What goes into Developing an Enterprise Encryption Policy?
    31 Aug 2021

    What goes into Developing an Enterprise Encryption Policy?

    /
    Posted By

    Read time: 12 minutes, 37 seconds

    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:

    • Data-in-Transit: Data-in-transit, or data-in-motion, is any data being transported to another location. This type of data is viable to threat actors via Man in the Middle Attacks. These attacks intercept the data while it is on the way to its destination, allowing the data to be read or stolen while in transit. This is a big issue if data like a piece of software or a firmware update were to be sent to a client and a Man in the Middle attack occurred. If the software was not encrypted, then the threat actor could edit that software/update to contain a malware payload and send it along to the recipient. That recipient would then update their software or utilize that software and have a malware payload downloaded to their machine. Luckily, there are a number of different methods used to protect data-in-transit, including: Secure Sockets Layer (SSL)/ Transport Layer Security (TLS), Secure Shell (SSH), and Virtual Private Networks (VPNs).
    • Data-at-Rest: Data-at-rest refers to any data stored on a device or in a database that is not currently in use or in transit. A lot of attacks on organizations target data-at-rest, as it is easily accessible if improper data protection controls are in place and Personally Identifiable Information, PII, is also normally stored in a database or device storage. This is why organizations use different encryption techniques to protect data-at-rest. These techniques include: Database Encryption, Full Disk Encryption (FDE), File and Folder Encryption (FFE), and Virtual Encryption. Additionally, Hardware Security Modules, HSMs, are used to store keys used to encrypt data-at-rest and data-in-transit.
    • Data-in-Use: Data-in-use is data currently having operations done on it. This includes data being generated, updated, erased, or viewed. Data-in-use is the hardest type of data to protect, as using the data requires it to be decrypted, so all encryption methods are not the perfect ways to protect data-in-use. Certain types of encryption, like Format Preserving Encryption (FPE), can be used to protect data-in-use. FPE encrypts the data, but leaves it in the same format that it was originally in, so performing computations on data encrypted via FPE is possible. Another way to protect data is to ensure that only those users who need to have access to the data actually have access to the data. This also applies to the encryption keys that may be used when the data is at rest. As long as proper management and approvals for encryption keys and data are in place, your data-in-use should remain secure.

    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. 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. 

    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 .

    Want to learn from HSM Experts

    We train some of the biggest names in the industry through virtual & Live Classes

    Get a Free Quote for your HSM training

    Free Downloads for Encryption consulting Advisory