Feb 12, 2019 9:22:51 AM by Jeff Surretsky
So what is PII and why should it matter to me?
PII, pronounced by many like the word “pie”, is definitely something we don’t eat; yet still something highly sought after by certain parties. PII is Personally Identifiable Information, otherwise known as Sensitive Data. To quote Wikipedia, “PII is information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context.” In other words, this is highly personal information, which we want to protect. Needless to say, this information is valuable and in the wrong hands can be exploited to commit criminal acts such as identity theft.
If your role in an IT organization involves being an administrator, steward or protector of data in any shape or form, chances are you are responsible for PII or sensitive data stored within your databases. All you have to do is read the news to know that data breaches are certainly an issue. Several large organizations have had their data compromised.
In fact, there are many regulations specifically defined to protect sensitive data, categorized either by industry or by something more encompassing, like GDPR (the European Union’s General Data Protection Regulation). I don’t plan on getting into any more details on these regulations; there are many sources you can read to learn more. Just know that these regulations do exist and that there are penalties for violating them.
With that very brief yet level-setting introduction, I would like to introduce new features available in Toad for Oracle that make it easier to identify and protect this sensitive data. These new enhancements are designed to simplify the tasks related to identifying and protecting sensitive data in your database and, as a result, can help you implement your existing data protection policies and strategies. Doing so without any type of automation could be quite involved and potentially error prone.
I would like to give a brief overview of what you can expect. For more details, please see the Release Notes for Toad for Oracle 13.1.
We can separate these features into two categories: Sensitive Data Awareness and Sensitive Data Search. While Sensitive Data Awareness is included in Toad for Oracle 13.1 and above, Quest plans to implement Sensitive Data Search as an add-on module. Called the Sensitive Data Protection Module, it will provide enhanced features for search and protection, and will be coming soon to ToadWorld . In this post, I’ll focus on Sensitive Data Awareness.
With Sensitive Data Awareness, Toad will interactively flag columns within your database containing potentially sensitive data. It does this when you interact with a table either through writing SQL in the Editor window or Creating/Altering a table from the Schema Browser.
Let’s see how this works.
To enable Sensitive Data Awareness, select View | Toad Options | Sensitive Data | General and then select Enable Sensitive Data Protection.
Figure 1. In Toad Options, select Sensitive Data then General
Figure 2. Enabling Sensitive Data Protection
Once this is enabled, you can have Toad, based upon a set of default yet user-customizable rules, identify sensitive columns either as you interactively type in the Editor and/or if you Create/Alter a table though the Create/Alter window from the Schema Browser.
Figure 3. Toad identifies sensitive data based on set criteria
As you can see, after typing a SELECT statement against the “C_CUSTOMER” table, the “C_PHONE” column met specific criteria classifying it as sensitive and is underlined by a squiggly red line.
If you hover over the underlined word, you’ll see the underlying notification as well as which specific rule is being violated.
Figure 4. Hover over the identified sensitive data to see notification details
Additionally, if I were to right-click on this very same table from the Schema Browser and choose Alter, I would see the following:
Figure 5. Toad flags potentially sensitive data in the Schema Browser
Note that there is a Yellow ellipse next to the “C_PHONE” column.
This type of interactive flagging is useful, as it identifies columns with potentially sensitive data and allows you to proactively apply protection measures as you create and edit objects. By increasing the visibility of potentially sensitive data, Toad allows you to monitor the levels and scope of data protection in your database as you work and warns users of the possibility of sensitive data as they access data. Doing this on your own would be a lot more work, and you could even miss something. So having a set of good rules do this work for you will save you time and eliminate the possibility of errors. I say “good rules” because this process is only as good as the rules you have in place.
As mentioned, there is a set of out-of-the-box Search Rules that are used to identify columns that contain sensitive data. These rules are defined using General Expressions, so you can create your own or clone/modify our existing rules to meet your specific needs. (These search rules are also used by the Sensitive Data Search capability in the new Sensitive Data Protection add-on module—which I’ll be discussing in an upcoming article.)
Figure 6. The Sensitive Data Search Rules
This was a brief overview of Sensitive Data Awareness, which is included in Toad for Oracle 13.1. in the Toad Professional Edition and higher.
Stay tuned for my follow-on article discussing the Sensitive Data Search capability in the new Sensitive Data Protection module.
Toad has always and will continue to make your job easier when managing your databases. I encourage you to download the latest version of Toad for Oracle today and start using this new feature! You should find it will help you manage and protect your sensitive data much more effectively and efficiently. Then you’ll have enough time to eat pie for dessert!
Tags: Toad for Oracle
Written by Jeff Surretsky
Jeffrey Surretsky has been working at Quest since 2000 as a Sales Engineer focusing on a wide variety of solutions including Foglight, SharePlex and the TOAD Family of Products. Before working at Quest, he was a DBA for various organizations spanning a diverse range of industries including but not limited to Insurance and Telephony . With almost 35 years of experience in the Information Technology industry, Jeffrey has a Bachelor’s Degree in Computer Science and a Masters Degree in Management of Information Systems.