We have mentioned in previous principles the importance of protecting specific pieces of information whilst they are in transit and we will expand on that now. The requirement to protect data in transit is not a new requirement but it is something that applications often fail to implement correctly.
This is perhaps the simplest principle to get right, make sure your applications enforce the use of secure transport mechanisms such as SSL, TLS or SSH. You must also make sure that your application enforces specific secure versions of these mechanisms such as SSL version 3 or SSH version 2.
So if this principle is so simple why do we continue to get this wrong? The problems often arise from two main decisions:
1. When to use these mechanisms
2. Which version to use
The common failure surrounding decision number 1 is the failure to protect the start of a session and the session information after an authentication. You must start the protection as soon as a user lands on your site; this means making the logon pages you have HTTPS instead of HTTP. In addition to encrypting the session from the get go you need to continue this protection throughout the whole session and not only for the submission of logon credentials. If the data is highly sensitive you should continue to provide secure transport mechanisms internally from your application server to systems such as database servers.
The final thing to address is using a mechanism that is cryptographically secure and does not have a flawed design. A good example of a protection mechanism that is not secure is SSLv2; several of its vulnerabilities come from weaknesses in its design and not through a cryptographic weakness. We mentioned two protection mechanisms earlier and they are examples of how to protect your data in transit. If you are selecting a transmission protection mechanism you should use one which is accepted as being secure such as SSLv3, TLSv1 and SSHv2.