Database encryption in transit, why is this still a question?

As data flows between systems, applications and databases, valuable information is pass along either internal, external or a combination of both types of networks. The data can be intercepted by several different tools including monitoring tools that companies use to verify that the applications are working and network availability. There is a great deal of security focused on the network and encrypting information being sent back and forth. Even with minimizing risk and various network security in place, there are opportunities to sniff or pull data in transit. It would seem like this security control would be a default for a secure configuration. However, there are still questions and open issues with database encryption and data encryption from to and from the database.

This seems like a first place to start for database security. Data in transit and data at rest can be encrypted with basic implementation steps and become part of a standard database build. With several database platforms these types of encryption are transparent to applications and data users. The client configurations received the data encrypted because the server has setup the proper configuration for encrypting the data in transit.

The question is still, why is this not a standard?  It could be because of other focus areas for the business or resource issues.  It can also be because this is something that is being handled after the databases have been created, and because of concerns of how the applications might handle the secured settings of the database servers if changed. However, since this configuration is part of the server, even if not part of the initial install, it can be part of the configurations and the standard build of the databases. Database as a Service (DBaaS) can provide these types of configurations as a baseline installation of the database server. Using a service like this or having these configurations as part of the deployment of the database will eliminate the question of encryption in transit. 

Set up the DBaaS with the needed encryption configuration will take care of the future standard, new builds, migrations, etc. But what about existing servers? This will need to be planned to change the configuration. Just as changes to parameters and patches are made, these server side configurations can be made and tested in non-production. As much as I would normally like to do one change at a time, there are a few things I would group this change with especially because there are limited maintenance windows. 

The database servers need to be configured to use SSL which is on the server side for both Oracle and Microsoft SQL Server. This is a high level view of what needs to be done for each database environment, which is basically parameter changes and restarting of a service or listener.

For Oracle parameters are set in the sqlnet.ora file:

SQLNET.ENCRYPTION_SERVER = required

SQLNET.CRYPTO_CHECKSUM_SERVER = required

For SQL Server, the Server Configuration Manager will help set the Protocols under the Network Configuration for the server. The properties for should have Force Encryption set to Yes.

Should this still really be a question? Encryption of data should just be a standard. Start by verifying that the data in transit is encrypted. Data at rest encryption would be the next step, followed by other data access controls and protection.