Friday, July 3, 2015

Guide for building an Encryption Policy: The Policy in Summary - part 4

Well, now it is time to give a summary on topics I have talked about in the other parts of this blog-series. In this post I will set-out the guidelines and if you want more background information on why I choose for some directions, please check the other posts.

I will setup the policy as much as possible on the way business rules are handled. This to maintain the audit-ability of the policy.

The series of posts are divided over the following topics.

The Encryption and Hashing Security Policy

General Policy

Every algorithm that is being used...
  • complies to the Kerckhoff's Principle.
  • is NOT theoretically or practically compromised or cracked.
  • is publically known and commonly used.
  • is sufficient enough to keep the data secret for as long as it needs to be secret.
  • is considered as part of a Life Cycle program in the organisation.
Comply or explain...
  • Every implementation and use of any encryption algorithm complies to the entire policy.
  • When it is not technically possible to comply to the policy then:
    • Always choose the next best possible option.
    • Always do an additional risk-analyses on the chosen option.
    • Always implement additional controls when the risk-analyses suggest you should.
    • Always perform penetration testing to test for weaknesses.
    • Always document the chosen option (explain).

Hashing Policy

Hashing Algorithm
  • The chosen algorithm is at least SHA-2.
    • Block size: at least 512-bit, but preferably 1024-bit or higher.
    • Output size: at least 256-bit (SHA-256), but preferably 384-bit (SHA-384) or higher
  • MD5 and SHA-1 are never used.
Salting with Hashing
  • Always salt a message before hashing when used to store passwords / passphrases and other session identifiers.
  • Every salt is unique, randomized and not reused anywhere else.
  • Every salt is as long as the output size in bytes of a hash.
  • Only use one hashing technique for one message.

Encryption Policy

Symmetric Encryption
  • The chosen Stream Cipher algorithms are ChaCha20.
    • The key-length is at least 128-bit.
    • The key-length is preferably 256-bit.
  • The chosen Block Cipher algorithm is AES or TwoFish.
    • The key-length is at least 192-bit.
    • The key-length is preferably 256-bit.
Asymmetric Encryption
  • The chosen algorithm is RSA.
    • The key-length is at least 2048-bit.
    • The key-length is preferably 3072-bit.
    • The key-length of 1024-bit is never used.
  • The Key Agreement is always based on Diffie-Hellman Key Exchange

Implementation Policy

Data in Transit
  • IPSec is used when ever possible.
  • IPv6 is used when ever possible.
  • If TLS is used, it is always version 1.2.
  • If SSH is used, it is always version 2
  • SSL (any version) is never used.
Data at Rest

Every option selected for encryption of data at rest...
  • is currently maintained by the developer.
  • has undergone extensive penetration testing.
  • is publically know for its security and is commonly used.
  • can use modern day Encryption and Hashing techniques.

Traveling Policy

The Wassenaar Arrangement is an international arrangement between a set of countries to control the use and export of dual-use goods and technology (Wikipedia & Wassenaar).  Encryption is considered a technological dual use good. Therefore, it might be prohibited for people to use certain encryption technologies (or strengths) in countries that may be considered as non-friendly or even hostile. This might mean you cannot take an encrypted phone or laptop with you when traveling. 

There is also a chance that when traveling a person must give away his or her encryption keys when arriving at the customs of the destination country. Many countries have these laws to check for data on the device that potentially violate the country's laws. And when the device is holding critical business data, it's security (and secrecy) might be violated.

When traveling...
  • the encryption technologies that are used in hardware and software that is taken by the traveler are checked for legality of export by the legal department.
  • the devices that are taken do not ever have sensitive data stored locally.
  • sensitive data is always collected through a VPN tunnel secured with proper encryption from the organisation's servers when the person has arrived at its destination.


That's about it about the subject of encryption, hashing and its policies. If you feel that something is wrong or should otherwise be adjusted or enhanced, please feel free to comment below. If you have any questions or whatsoever, please feel free to comment also.

Thank you for your time to read my blog-series about the Guidelines for an Encryption and Hashing Policy.

This post has the tag: update, meaning it will be updated when new information becomes available and/or relevant.


Post a Comment