Which mode of attack are you trying to harden against? What are your expectations for what database encryption will buy you?

Hi @CRUNDELL ,

What is your goal with respect to encryption?

Are you trying to have your at rest data encrypted at all times? 

Oracle Advanced Security Transparent Data Encryption will provide encryption at the database level without application changes.  I’m not sure of the impact on performance so you’ll want to research the overhead to make sure you have enough memory and CPU to handle the additional load.

I believe Oracle Advanced Security Option requires Oracle Enterprise Edition in order to license the technology but you’ll want to consult with either Oracle or IFS depending on who you licensed your Oracle database.

Regards,

William Klotz

Hi durette, I’ve been thinking in terms of best practices for sensitive data without a particular type of attack in mind but it’s something we should consider. Let me know if you have any suggestions for tables that are likely to contain sensitive info. We don’t use HR so looking at everything else.

Hi William. Yes we are looking in ot OAS. I’m just looking for a list of tables that might contain sensitive data. Wondering if anyone put a list like this together.

Hi @CRUNDELL ,

We currently do not use encryption at the database layer “Oracle TDE” we use a self encrypting disks for the database storage to give us data at rest encryption.  Although I Oracle TDE provides superior encryption within the database we’ve always been concerned with the performance impact of using Oracle TDE to enable encryption across all IFS tables.   We would prefer to encrypt all IFS tables instead of trying to figure out where IFS is storing all the data we consider sensitive.

Anyway we consider most things with financial or customer, supplier information to contain sensitive information.   If you’re in Europe or California you will have to consider contact information sensitive as well.   Below are a few tables we’d encrypt off the top of my head. 

ACCOUNTING_BALANCE_TAB
CUSTOMER_ORDER_TAB
CUSTOMER_ORDER_LINE_TAB
CUSTOMER_ORDER_CHARGE_TAB
INVOICE_TAB
INVOICE_ITEM_TAB
CUSTOMER_INFO_TAB
CUSTOMER_INFO_ADDRESS_TAB
COMM_METHOD_TAB
CUSTOMER_INFO_CONTACT_TAB
CUSTOMER_CREDIT_INFO_TAB
IDENTITY_PAY_INFO_TAB
CUST_ORD_CUSTOMER_TAB
SALES_PRICE_LIST_TAB
SALES_PRICE_LIST_PART_TAB
CUSTOMER_AGREEMENT_TAB
AGREEMENT_SALES_PART_DEAL_TAB
AGREEMENT_SALES_GROUP_DEAL_TAB
SALES_PART_BASE_PRICE_TAB
ORDER_QUOTATION_TAB
ORDER_QUOTATION_LINE_TAB
PURCHASE_ORDER_TAB
PURCHASE_ORDER_LINE_TAB
PURCHASE_ORDER_LINE_HIST_TAB
SUPPLIER_INFO_TAB
SUPPLIER_INFO_ADDRESS_TAB
SUPPLIER_INFO_CONTACT_TAB
IDENTITY_INVOICE_INFO_TAB
PURCHASE_PART_SUPPLIER_TAB
PURCHASE_QUANTITY_PRICE_TAB
COST_DEL_OH_SUPP_PER_PART_TAB
PERSON_INFO_TAB
PERSON_INFO_ADDRESS_TAB
PERS_DOCUMENT_TAB

Regards,

William Klotz

You can’t know whether you’re actually protected without consulting with a true expert. You can put yourself in a situation where it looks like you’re protected--where it reports encryption is enabled--but you’re actually not.

This is not something you want to do just to say you did. You should understand your attack surface so you can validate it has been closed.

Consider this…. If you start the server, your operating system is going to know how to start your Oracle Database software, and then Oracle is going to know how to start your database instance, mount your control file, open your database, and expose your database service on your network. If your operating system and software can do all of that without user or network intervention, then there’s nothing stopping a sophisticated attacker from running a simulation that does the same thing. If you leave the key in an Oracle wallet on the server, for example, you may not be contributing to the security to the system.

I think you should reach out to a DBA to get this set up and validated. You need to consider things like how to manage the master key.

There are some really good answers here already from @durette and @william.klotz so I’ll just add that what is considered sensitive data for one customer may not be for others.  This could potentially be dependent on customer specifics, industry or even location (e.g. state or country).

For example, some customers might consider their Supplier or Customer info to be business sensitive but it isn’t in any legal sense (e.g. not likely subject to ITAR controls like technical data might be).

So at the risk of stating the obvious, there is likely a core group of tables that might be considered sensitive in most cases (financials or HR), and then a separate group of tables that could potentially be sensitive based on business type or location etc (customer info, work guidelines, project information), and finally a group that in most cases might be generally not be sensitive but could be based on specific business sensitivity or how the system is used (pretty much everything else).

Nick