More DB2 Family Security Best Practices Part 5

The next part of this DB2 Family Security Best Practices blog series talks about developing a unique corporate security. This security is unique within your organization and unique within your applications.

Given that encryption can have performance overhead, can complicate management procedures, and require application changes, sometime it’s not an option. So another DB2 security practice, an advanced procedure, is to leverage and design your database with steganography techniques and characteristics within your database table and element design.

DB2 security steganography techniques can be very simple or very complex. In either case DB2 security and all types of data can be dramatically enhanced through steganography techniques.
Steganography may be new to you but it has been around for ages. Simple steganography is the common method for hiding data in text or encoding data with additional data or numbers. By hashing, encoding or adding digits or subtracting values these steganography techniques are a great security practice for all types of DB2 databases, other databases, flat files, or any sensitive data within your enterprise.

For example, the social security number could involve steganography by using a formula to subtract a prime number from the real social security number. This subtraction routine could be put into a standard called module that could easily be referenced before the dynamic or static SQL is executed.

Another common steganography technique is to “Salt and Pepper” your sensitive data columns with extra digits or extra positions. For example a social security number definition could be defined as 11 bytes instead of 9 bytes. A minor overhead of two extra bytes with an extra “salt” digit before the real SSN and a “pepper” digit after. This steganography “salt and pepper” pattern could also be modified to be a different scheme based on the person’s first, last name, their zip code, or state of residence.

For example, all the people in California could have their real social security number wrap from the starting position 3 because California starts with the third letter of the alphabet. Any developer or corporately imaginable technique can be used as a corporate steganography application secret for scrambling and hiding the sensitive data.

In this example a steganography processing routine is used to “salt and pepper” the data when inserted and retrieved. The steganography routine knows to modify the value for the SQL INSERT and for the SQL SELECT host variable value. Before the SQL INSERT the real SSN value is shifted one byte and right and left padded with a fake digit. These fake digits are taken from the input in a standardized company application specific method. In this steganography example the corporate application secret is to use the forth digit and sixth digit as the “salt and pepper” digits to start and end the 11-digit SSN data.

So the INSERT uses a first “salt” digit of “4” and “pepper” digit of “6” for the 11 bytes SSN. When the data is stored in the database and at rest, it is in the state of 41234567896. If hackers get the data, it is useless because they don’t know the extra intelligence of the company’s steganography routine. When the SQL for SELECT for retrieval is executed, the routine knows the social security number “salt and pepper” to retrieve the appropriate customer row.

Steganography techniques can also be incorporate in DB2 very easily through standard routines, stored procedures, field procs or edit procs on your tables or columns within your object definition. Another option is to have a standard access process that handles your input variables for your dynamic or static SQL modules that modifies the input to the steganography technique.

Steganography techniques can also be easily incorporated in RESTful Java architectures that use Hibernate and other Data Access Object (DAO) modules.

These DB2 security steganography techniques are very easy to understand and offer extraordinary protection. If a rogue SQL statement is done against the database table, the SSN at rest within the data is scrambled through the steganography routine. So the data hacker not only has to hack and get your table data but also has to capture the secret steganography business logic techniques that “salt and pepper” your data. This combination helps add another layer to protecting your database sensitive data and is a great way to augment your DB2 security with another security layer that protects your data in motion and at rest.

In this second example the steganography processing routine uses the state code of California “CA” that starts with the third letter of the alphabet to modify the SQL INSERT value and SQL SELECT output value. Before the SQL INSERT the real SSN value is shifted three bytes. When the SQL for SELECT for retrieval the routine shifts the social security number to retrieve the customer row. So when the data is stored in the database and at rest it is in the state of 456789123. Again this protects the data at rest.

Steganography techniques, specialize routines, and data shifting can be another layer to incorporate into your DB2 security best practices that prevent your data from being useful and leveraged for illegal activities if stolen. Designing and implementing simple or complex steganography techniques are easy to do and can greatly improve your entire DB2 security implementation.

DB2 development is trying to understand the new open source application projects that need connectivity to DB2. Please help out by taking the survey below to help them understand your DB2 connection requirements.

http://it.toolbox.com/blogs/db2zos/open-source-development-and-db2-connect-68529?rss=1

Support IDUG through the European IDUG conference in Dublin, Ireland November 15-20. For more details go to www.idug.org.

I will be presenting “Defending against the Legions of Doom: DB2 Security Best Practices” at the local DB2 User Groups in September in:

• St. Louis, Missouri September 15th
  • Agenda at https://ibm.biz/STLDUG201509
  • Register at https://ibm.biz/STLDUG201509_Registration
• Milwaukee, Wisconsin September 16th
  • Agenda at www.wdug.org for the meeting more information
  • Register at http://wdug.com/joomla/index.php/registration
• Chicago, Illinois September 17th
  • Agenda at www.mwdug.org
  • Register at http://www.mwdug.org/2009QUARTERLY

Also I look forward to seeing everyone at this year’s IBM Insight (formerly Information on Demand-IOD conference). I will be presenting two presentation “Performance Enterprise Architectures for Analytic Design Patterns” and “Defending against the Legions of Doom: DB2 Security Best Practices”.

For more details go here (http://www-01.ibm.com/software/events/insight/).

I authored two CIO DB2 Security Audit white papers and a technical DB2 Security Audit white paper for SEGUS. Also at the link is a webinar talking about the SEGUS security and DB2 audit considerations. The How to establish a Security Audit for DB2 z/OS white paper can be found here (https://www.segus.com/media/wp-security-audit-dba-en.pdf)” and the Is 339° Security Audit Sufficient? White paper is here (https://www.segus.com/media/wp-PSI-339-security-cto-en.pdf) and the Powerpoint webinar discussion presentation with SEGUS is here (https://www.segus.com/events/webinars/db2-for-zos-security-audit-protecting-your-assets/).

Here’s a list with links to other posts that may help you improve your DB2 performance, security, and ease-of-use:

5 More DB2 SQL Performance Tips
Another 5 More DB2 SQL Performance Tips
5 Big Data SQL Performance Tips – Fixing Generated SQL
DB2 11 SQL Performance Improvements
5 More SQL Performance Tips for your Big Data
Hadoop SQL: 4 Reasons Why BigInsights Is the Best
Vital Java DB2 SQL Performance Considerations
More DB2 Family Security Best Practices Part 7: Preventing SQL Injection
DB2 SQL Security Audits

Dave Beulke is a system strategist, application architect, and performance expert specializing in Big Data, data warehouses, and high performance internet business solutions. He is an IBM Gold Consultant, Information Champion, President of DAMA-NCR, former President of International DB2 User Group, and frequent speaker at national and international conferences. His architectures, designs, and performance tuning techniques help organization better leverage their information assets, saving millions in processing costs. Follow him on Twitter here (@DBeulke) or connect through LinkedIn here (https://www.linkedin.com/in/davebeulke).