One question we are often asked with regards to cryptographic controls is how does SSL work with HTTPS? And as we are using HTTPS to secure our data in transit, how do we describe this in terms of cryptographic controls in ISO 27001?
We take a look in this article at what HTTPS is, how SSL (or TLS) helps to protect the confidentiality and integrity of data in transit, and finally how this can be described within your information security management system to protect data under cryptographic controls.
What is HTTPS?
Those who are familiar with the Internet will know that HyperText Transfer Protocol, or HTTP, is the application layer protocol that is used all over the World Wide Web to distribute web pages. You will notice that websites begin with HTTP:// (or HTTPS://) which defines the use of HTTP for communicating web pages from servers to clients.
Well, HTTPS is simply a secure version of HTTP, in that it provides an SSL/TLS encryption layer on top of the communications channel. In essence, the same communications protocol is used, however, a layer of encryption is provided to protect data in transit from attacks such as man in the middle (MiTM).
The Secure Socket Layer (SSL), or Transport Layer Security (TLS), protocol enables the server to authenticate itself to the client (you) as well as ensuring that only you can read messages sent from the server to you and only the server can read messages sent from you to the server. This ensures that any communications intercepted between you and the server cannot be read by a third party, and that third party cannot inject messages into the stream pretending to be you, for example. How is this achieved though?
Initially a handshake occurs between the client and server. This is to ensure that the client is speaking to the right server, that both parties agree on the correct cipher and encryption algorithm to use and to agree on encryption keys (public, private keys). This can be thought of in the same way as a conversation with a shop keeper in a country you are visiting.
Firstly, you must establish you are in the right shop, and this can be achieved by reviewing signs outside and inside the shop. Once you are sure you are in the right shop, you can then ask the shop owner whether they speak your language and, if not, what language you both speak to enable communication.
Once the above factors have been agreed, the communications channel is established and both client and server are aware of how they will securely exchange messages (including how to encrypt/decrypt these messages). Following this, the server (and sometimes client) exchange certificates.
This begins with the server proving its identity to the client by issuing its SSL certificate. A certificate can be thought of like a passport or driving license, and identifies the server through details such as its owner, domain name, public key and digital signature. Certificates are validated by a third party known as a Certificate Authority (CA) who sign the certificate to confirm the server is who it says it is.
When the client is happy that the server has confirmed its identity, the communications channel will be encrypted and decrypted using a key generated using a symmetric algorithm agreed at the initial handshake stage. The client then generates a random key for the encryption channel based on the algorithm agreed at the handshake phase and the servers public key. This encrypted key is sent over to the server, where it is decrypted using the servers private key, and the communications channel is established.
Using HTTPS, and other secure algorithms such as SFTP/FTPS (secure file transfer protocol), enables communications streams to be encrypted and man in the middle attacks to be prevented. But are use of these protocols sufficient to meet ISO 27001 cryptographic control requirements? And how can these be identified in cryptographic control policies?
How does SSL work in ISO 27001?
The use of secure protocols is obviously encouraged in ISO 27001, and information security in general. SSL, or TLS, enables organisations to securely transmit data and preserve the confidentiality and integrity of information in transit. But in some instances, the use of encryption may not be desirable as communications paths cannot be monitored or inspected for misuse.
ISO 27001 therefore requires organisations to identify where and when encryption should be used, and what methods of encryption are suitable. This may be as simple as saying data classified as SECRET or TOP SECRET must only be transmitted via SSL encrypted channels, and that it cannot be sent via clear text protocols such as HTTP or SMTP.
Organisations should therefore define an encryption policy that identifies encryption methods and when/how these should be used. The organisation should also identify when encryption shouldn’t be used, and for what reasons. In addition to identifying methods of encryption, the organisation should specify key management procedures to ensure that any encryption keys cannot be compromised.
In summary, a well defined encryption policy identifies secure methods of encrypting data in transit and at rest. The methods defined should be well understood and users should be made aware of when and how to use these methods to protect data transiting the network.
