Fri Mar 28 04:50:01 PDT 2014

Content control: Data in motion: When should I transmit content encrypted?


Options are split into three dimensions.
Dimension 1: Dimension 2: Dimension 3:


Identify requirements for encrtyption of data in motion.

Sensitivity Location Low Risk Medium Risk High Risk
all internal never required required
all external required required required
sensitive internal convenient always always
sensitive external required always always
What to encrypt when in motion


Some content should always be encrypted in transit.

When convenient and available:
In many cases, encryption is readily available and convenient to use. For example, using an SSL Web service rather than an unencrypted service is almost never problematic, and unless performance is too low for the application, there is no reason not to use it.

When required by others:
Whether by contract, government mandate, or by customer demand, when encryption is required, it should be used.

Never use encryption:
Internal low risk content should not be encrypted unless it is easier to encrypt than to not encrypt.

Sensitive information:
Information that must be protected from observation either because it is confidential or because it revels operational information that could be used in intelligence, should be encrypted in transit to prevent exploitation.

All information:
Not all information is sensitive and the rest of the information may be treated differently. A good example is content of public Web servers which often has integrity requirements, but usually has no confidentiality requirements.

Within internal infrastructure:
Within internal infrastructure, encryption may be harder to do on a uniform basis, and it is certainly more expensive. If physical or other protective mechanisms are adequate to the need, there is no need to encrypt internally, but this does not apply to remote connections to "internal" resources at another location.

When transiting untrusted networks:
This applies to the Internet as well as other connections that pass through areas of lesser trust.

The use of encryption for information in transit, as opposed to other techniques, is specifically and solely for the purpose of preventing unauthorized revelation of content or information about the systems exchanging the content. It is expensive to do well and prevents internal surveillance that may be important to intrusion detection, network debugging, and other similar uses. Therefore, the only justification for encryption in transit comes from external requirements or risks.

Low risk: In low risk situations, never encrypt all content traveling through internal networks. It is expensive, unnecessary, and difficult to manage. If required for some contractual or other reason, external traffic should be encrypted. Sensitive information should be internally encrypted if it is convenient because, while the risk is low, the cost is also low in this situation. External sensitive information should be encrypted if required for regulatory, public perception, or contractual reasons.

Medium risk: In medium risk situations, all internal network traffic should only be encrypted if required. Most information is not likely to be important if leaked, and this keeps unnecessary costs down without sacrificing anything critical. All external and internal sensitive information should be encrypted if it is convenient because, in the case of external information, it increases the difficulty of understanding which information is important, and for internal information, it doesn't hurt to encrypt if it is convenient. Sensitive information with value this high and identified threats should always be encrypted in transit, even internally.

High risk: In high risk situations, loss of life or similar high consequences may be the result of sensitive information leaks. As a result, all sensitive information should be encrypted in transit. Non-sensitive information should be encrypted internally if convenient and externally if required, for the same reasons as the medium risk situation.

Copyright(c) Fred Cohen, 1988-2012 - All Rights Reserved