June - 2010 issue > Technology

By Rajesh Parthasarathy

Many define sensitive information as personal or corporate data like social security numbers or credit card numbers or sales figures. But sensitive information is any data asset that you have a fiduciary responsibility to protect, and there is a gamut of them - from personal information, corporate information, customer and vendor information, to intellectual property. All of this is stored in enterprise-wide relational databases and applications.

Applications and databases were architected in a more carefree, less security-conscious era. They simply aren't built to protect data. In fact, they are built to make access to data easier. But the real issue is that it’s extremely difficult to know where all of the sensitive information actually is located within those databases and applications.

When these databases and applications were designed, organizations wanted to share information, both internally and externally. This resulted in deployment of enterprise-wide relational databases with complex data models and architectures. The vendors don’t document the locations of sensitive information – primarily because they don’t know what data is sensitive for a given organization.

Since you cannot secure data if you don’t know where it is, you have to locate all of the places that the database or application has designated for storage and map it to your application security and other access controls. But there’s an Achilles’ heel to this process and this is where the risk of data exposure becomes acute, which is undocumented locations of sensitive information.

For a very long time, information was put into databases and applications without worrying about exposure. For example, at one of our client sites, we found all the employees’ social security numbers in a table where the payroll clerk had copied them in order to simplify the check writing process. This was not just a few numbers; it was thousands of them in an undocumented, unknown, and totally unexpected location. Another example is of a developer creating a payables report that included vendor tax codes and addresses - a breach of several privacy acts.

If you have more query about magazine please send mail to

Feb 12	Jan 12	Dec 11	Nov 11