Questions you may want to start with when moving to the #cloud

Last week one of my customers called me into a meeting to discuss moving a critical application to the cloud. This application is very sensitive to the customer and the data it holds is very sensitive to my customers customer. The results of this meeting turned into a list of questions forwarded the customers executive staff and also a set of questions for the cloud vendor.

This Cloud vendor is providing a COTS solution storing personally identifiable information tax and other very sensitive information. Because of this a number of the questions focus on the protection of PII and the destruction of unneeded copies of data.

I have redacted customer and vendor information from this list of questions,  these questions may serve as a baseline for your organization to come up with questions for your Cloud vendors. Point of note the answers to these questions will more likely than not cause follow-up questions.

Here is the list of questions for the customers executive staff to address.


As <REDACTED> moves towards cloud based computing solutions, <REDACTED> must consider the following to create standards for all cloud based systems going forward:

  • Will <REDACTED> require TLS on day 1? If not, vendor must have a plan and a deadline to get off SSL and on to TLS?
  • Will <REDACTED> require DISA STIG standards (Fed DOD standard) for all off site cloud data?
  • Will <REDACTED> require PENetration testing and at what frequency (Federal standard is 1 year)?
  • What level of data destruction is required for <REDACTED>’s secure/PII data being stored on a cloud based system controlled by non-<REDACTED> vendors?
  • Will <REDACTED> hold AES256 as the minimum encryption standard for cloud based systems?
  • Will <REDACTED> require 3DES minimum 168 bits?
  • Will <REDACTED> require a minimum of 7 wipes for secure/PII data stored on cloud based systems?
  • Will <REDACTED> require in sales contract with stated frequencies, independent audits to ensure <REDACTED>’s stated audit, encryption and data destruction plans are in effect and compliant?
  • Will <REDACTED> require internal <REDACTED> audits and/or legislative audits be performed on <REDACTED> systems?
  • The sales contract must state the “break up” plan for all <REDACTED> data including the delivery back to <REDACTED>, the destruction of the data on vendor systems and the certification that all data has been destroyed according to the <REDACTED> standards. Independent audit to verify results.
  • Will <REDACTED> require all data stay within the United States, with no data ever leaving the US?
  • What will <REDACTED> require regarding the vetting standard for cloud vendor trusted inside employees?
  • What will <REDACTED> require regarding liability insurance in the event of a security incident?

Here is a list of questions for the cloud vendor.


As <REDACTED> data is highly sensitive and contains a great deal of PII for each firm, the following are questions to be answered:

1.    Regarding the destruction of sensitive/PII data on <REDACTED> systems, how will you destroy unnecessary copies of data and ensure the necessary copies are encrypted and secure?

2.    Is the use of AES256 and 3DES encryption consistent throughout <REDACTED> enterprise as referenced on page 10 of the Security Management Plan? How many bits are used for 3DES?

3.    Initial Source Data/Document Load files (via sftp per <REDACTED> docs): Controls/Audit – <REDACTED> should know exactly who touched the load files and for what purpose via audit reports.

4.    Additionally, after migration is complete, <REDACTED> to certify (via independent audit) that all source data has been destroyed and no ghost data remains on servers or work stations.

5.    Cross boarder – will the data leave the United States for any reason at any time?

6.    What analytics software packages are in use to monitor account activity for our <REDACTED> employees as well as <REDACTED> trusted inside employees? How will audit reports be delivered to <REDACTED>?

7.    What does “in compliance with Cyber Security Standard” refer to as mentioned on page 6 of the <REDACTED> Security Management Plan? Is this a subset or superset of NIST?

8.    On page 7 of the <REDACTED> Security Management Plan in reference to Export Servers under System Architecture, how is the use of these Export Servers audited and after the export is no longer required, how will you certify that the data has been destroyed? If used, can an unencrypted copy of the export be made?

9.    Will all backups be encrypted with 3DES and at what bit level? How will <REDACTED> certify the destruction of old backups?

10.   What is the plan for <REDACTED>’s system using TLS?

11.   Does <REDACTED> harden sqlserver to DISA STIG standards? If not, is it a superset or a subset?

12.   What is the end of contract plan for all <REDACTED> data including the delivery back to <REDACTED>, the destruction of the data on <REDACTED> systems and the certification that all data has been destroyed according to the <REDACTED> standards.

13.   In the event of a security incident, does <REDACTED> have liability insurance to cover associated losses?

14.    How are your trusted inside employees are vetted (DBA’s, System Admins, Network Admins, etc)?

15.   If you perform PEN testing, what is the frequency of the testing and will <REDACTED> get a redacted copy of the results of each test?

#infosec issues on moving to the #cloud #DBaaS

Last week I was at Oracle Cloud World working at the ODTUG booth. This gave me the opportunity to talk to a lot of people who are seriously looking at moving their environment to the cloud. While chatting with these people, I started to pull together some thoughts on the security issues that come with moving to the cloud. Many of those issues are the same for hosting your own database applications. There are several issues with moving to the cloud and if you don’t address them it can become dark and stormy.

What security questions do you need to address prior to moving to the cloud? Note: many of these issues also applies to hosting your own databases! This subject is complex and I’m just touching on some of the issues.  If you don’t do your due diligence you will get burned.


Will and How will your data be encrypted? First off, all of your data should be encrypted by default. I am also of the <OPINION> cloud provider should not even offer to store your information unencrypted. </OPINION>. With the advent of hardware encryption modules, encryption performance is a non-issue.

There are a couple of options on encrypting your data, both have strengths and both have weaknesses. First of the easiest encryption option to implement is tablespace encryption. This option is used to encrypt all of your data stored in the tablespaces.  The down side is the data is unencrypted in the SGA.

The other option is column encryption.  This requires a bit of work upfront to setup. You are going to need to identify the atomic pieces of data that need to be encrypted then go through your indexing scheme to make sure you have not put indexes on columns that are encrypted with salt, and you don’t have foreign key constraints on columns that are encrypted. The upside of column encryption is the data stays encrypted in the SGA.

Will your backups be encrypted? Again, the answer must be yes and this is where it gets a bit tricky. RMAN backups are block level copies of the data files, so if your data is encrypted, your backups will be encrypted. However, if someone runs a datapump export of your data to refresh a lower environment and they do not specify encryption in the options, then your data will be saved unencrypted. The cloud provider must audit for this event and if it does happen, then you need to be informed and the cloud provider must make every effort to find and destroy that datapump file and any copies that have been made of it. You notice I used the word destroy as apposed to delete. Well there is good reason for that, if you delete a file there is still ghost data that can be recovered. So that or those file(s) will need to destroyed by a utility such as Linux shred.

The trusted insider attack surface has changed. <OPINION> It is safe to assume Oracle and other Tier 1 cloud providers will vet their system administrators. </OPINION> However; people change, that is just a fact of life. I frequently use the example of Edward Snowden. Prior to his leaking NSA documents he had gone through polygraph examinations, and his entire background put under a microscope, then he changed.

How will your cloud provider protect you against their trusted insider? The concept is easy, wall off your data from being seen by the system administrator. I’ve been a DBA for decades and can tell you with complete honesty, the DBA or SA does not need access to your data in order to do their job. <OPINION> Oracle has a great product Database Vault that is designed to wall off your data from the SAs. Any cloud solution should include the implementation of Database Vault. </OPINION>

Your cloud provider must provide a proven tool that protects your information from trusted insiders at the cloud provider.

Your cloud provider must also provide an integrated audit solution that tracks all audit events and allows you to report on audit events. Oracle Audit Vault comes with BI. You can use caned reports and customize those reports for your requirements.

Can you make customization’s to the security? Oracle Real Application Security (RAS) gives you, Redaction, Virtual Private Databases and audit on all connections. A full discussion of RAS is beyond the scope of this paper.

<OPIONION> At the very least, you should be able to implement, Virtual Private Databases, and Redaction to protect your data from the normal use of you applications. </OPINION> (I say normal use of you applications. Using different tools and grants it is possible to bypass these features.)

Will the cloud provider implement and configure Database Firewall. Database Firewall is a good tool to defend against sql injection attacks. It takes a lot of work to properly configure it especially if you are using a custom application. Will the cloud provider be responsible for the configuration of database firewall?

How are you going to get your data back if you decide to break up with your cloud provider?

If your cloud provider is using Oracle 12C multitennant an encryption key is generated with the container database and that is used to decrypt the encryption key for the pluggable database. I’m not going to dive too deep into this. The cloud provider can unplug your database and provide you with a set of keys to decrypt your data.

Then the worst happens, there is a data breach. You need to know, how will your cloud provider make you whole. The truth is, your customers will be upset with you and maybe your cloud provider.

End the end, you are the steward of your customers data and with that stewardship comes responsibilities.