Archive for the ‘db’ Category


Interesting question came up on an internal database security alias that I thought should be shared.

The question posed on behalf of a database customer was around seeding random routines.  Was it more secure to provide a seed to the random number generator routines or not?  The question was extended to say that if seeding the routines was more secure, what new security issues were introduced in storing the seed values used?   To seed or not to seed, that is the question.

In this particular case, the answer is NOT to provide the seed the database random routines in production.  Seeding is similar to the cryptographic concepts of salts and even nonces, but within databases, it is used slightly differently.  In the Oracle DB world, generating a random numbers are the domain of the DBMS_RANDOM package.  It specifically states it should not be used for cryptography.

Like salts and nonces, a seed is used to add some increased entropy to the generation of random values.  Computers, for all their advanced capabilities, are still psuedo-random generators, not pure random generators.  Given the same input, they will generate the same output.  So to add some additional complexity to the random number generation to make it appear more a true random number, the DBMS_RANDOM routines allow the developer to “seed” any random number calculation. So one would think adding a seed to the generation would make the overall system more secure because the seed would better enhance the randomness of the pseudo random generation.

But, by supplying this seed to the calculation, the developer now introduces an added security complexity.  Where to store the “seed” securely between calculations? It is in effect a secret key if used (inappropriately I might add) to encrypt or protect information in the database.  Even with the documentation saying to do this, we have seen this done again and again.

What most developers miss is the DBMS_RANDOM package is a random package, not an encryption package.  If one does not supply a seed to the random number generator, the routine creates a random seed on its own, based on userid, date, and process id.  Not a truly random seed, but does add some entropy to the random generation.

In fact, the reason the routines allow the code to pass a seed instead of random generation of the seed is to allow testing.  By passing the same seed to the random number generator, you get the same random number back, which allows testing across runs.  As long as the seed remains fixed (non-null) the random number generator will pass back the same number. So, the thought that adding a seed to the random number generator to improve randomness actually fixes the generator to producing the same number, not a random one.  Plus, you have a security problem of where to store the seed.

So the answer is NOT to seed the routine in DBMS_RANDOM, but let it generate its own “random” seed when called. Remember, this discussion is around this implementation of one random number generation routine in an Oracle database package and should not be applied to other random number generation routines. But be dutiful of the seeding documentation.    Also, be aware that if you are using random numbers to do cryptographic encryption, you need to be sure the random routines are strong enough to insure the resulting security is trustworthy.  You need to use cryptographically secure routines. Not all psuedo-random routines are designed with that in mind.




Read Full Post »


Try not to make this a blog an outpost for plugging my company’s wares, but want to make an exception in this case as I think many can benefit from it.

Got word yesterday that our long awaited data masking templates for Oracle E-Business Suite 12.1.3 were released to production.

Okay, I hear you whimper.  Why is that so important?

Because unmasked test data is one of the easiest targets for thieves to hit.  And its so simple to plug this hole.

For those who need the short background version:  companies go to great pains to set up identity management and secure their data in production, rich with credit card numbers, ssn’s, PII, etc.  ERP applications like Oracle’s E-Business Suite 12.1.3 capture and store a great deal of this information in their databases and do a lot to make sure it is secure in production.

But many of my customers think nothing about taking a snapshot of the database for QA and testing purposes. Maybe once or twice a month, they clone the database into testing, because “nothing tests our new code better than our production data”.  They now have a new copy of production in an less secured testing environment.

Often, these test/QA folks are with the development team (maybe even outsourced) and often have privileged accounts into the database and the application so they can test full functionality and affect changes in the test environment.  Your production site might be under strong lock and key, but it would take a dev tester mere minutes to clone yet another copy of sensitive data on that SD card they brought with them to work that day.

So data masking is just that.  A the production data is cloned, key elements of the database are masked, obfuscating the actual data.  Masking may randomize user’s SSN’s, exchange phone numbers and addresses between user records, etc.

Masking is a little more involved than just scrambling data.  You still need the data set to behave as it does in production.  You just cannot swap everyone’s zip codes if your software uses it to do reports by region.  An 07405 zip code with a California address will not test cleanly.  Plus, you need to track the changes to the database so you can do them again with some consistency, so refreshes of the masked data behave in a like and similar fashion.

So what’s the big deal with the announcement?  The problem with masking, particularly complex ERP systems, is to know where the sensitive data is in the system and how best to mask it for protection, yet still have it behave properly for testing.  ERP systems have their own way of building relationships between the tables the are built on and often these table can run into the hundreds.  So the good news is the development team for EBS worked with our masking team to create templates specifically for the EBS 12.1.3 suite.  This will significantly compress the time to get a masking program in place and plug that security hole. You can leave a copy of your masked production data on a SD card at the counter at Starbuck’s and its safe as can be.

So if your company runs EBS 12 and runs copies of production data in testing, you should look into these new data masking templates. And I know there are a lot of you.  You can find out more about the the Oracle Data Masking Pack with Oracle Enterprise Manager.  You will need to purchase a license for the Data Masking Pack, but the EBS templates are available free in the following patch:

Read Full Post »

Fox and egg

We all know the biggest security risk are not external threats, although they do pose a substantial problem area, but internal privileged users. We also know the majority of the at risk information is contained in databases. So why do we leave the fox to watch the hen house?

I run into this situation all the time, at companies that believe they have a strong security posture.  However, they have a team of dba’s maintaining their corporate databases.  If it is like most database teams, they are a small, elite group of database technologists, many with root access to the database farm.  Most databases manage their own security, so a common practice is to share dba accounts and keep user ID’s and passwords in a shared spreadsheet.

When we point out the huge opportunity for one of the dba’s to go rogue, we often hear “that can’t happen here, we trust our dba’s”.

Until the next breach is recorded.  Then you will find out it was DBAFIN12 who accessed the personnel database and that could have been anyone of 5 dba’s and that’s if it was one of the dba’s, not someone who just happened across a copy of the password spreadsheet.

So what to do?  First, centralize DBA user management into a directory.  Most databases can use an LDAP directory as the user store.  This not only puts all accounts that have privileged access to the database farm, it also does two things.  Requires each DBA have an identifiable user account so sharing is discouraged.

Second, by placing account management in a directory, you often place account management into the hands of a team external to the DBA team.  Gone are the days where one DBA can grant high privilege access to a data table to another team mate.  Now, if they have to go through a directory team, the DBA’s will have to justify why they have access and when they no longer need it. Hey! Instant separation of duty!

Many database companies, including my company Oracle, also have more sophisticated central user management. Oracle’s Enterprise User Security (EUS) has been in the database for several versions now. It provides an additional layer in the LDAP directory of Enterprise Roles and schema mapping.

An elegant solution to having the foxes run the hen house.

Read Full Post »