We all hear about the very large very public data breaches but what about all of the ones that we do not hear about? Does your company have an employee that recently left? Do you know what data they had in their possession that they may have taken with them? In a study by Ponemon Institute 50% of employees leaving a company have taken data with them and 40% say that they will use it at their new company.
Once data moves out of the control of a corporate database, IT and the company effectively lose control of that data and can no longer apply any data access/ security policies that the organization may have. The organization has to rely on the employee that has possession of the data to continue to restrict access to only those that need to access.
Most organizations spend a lot of time ensuring that users have access to only the data they need to preform their job, but as “special projects”, new software implementations etc. occur additional data may be made available to resources on these activities.
Data is made available to resources of an organization in a number of ways:
- Via an application.
- Via an adhoc query tool.
Data being made available via an application should already have had data access/ security policies applied but a resource with access to a query tool may have unrestricted access to that data.
How can we limit the exposure of the data?
Data can be protected in a number of ways:
- Restrict access to tables.
- Restrict access to rows of data within a table.
- Restrict access to columns within a row.
Restricting access to tables is how organizations traditionally start to apply any type of data security, however this approach gives the authorized user access to all of the rows within the tables. When Oracle introduced Fined Grained Access control with version 8i of the database this gave organizations the ability to restrict access to more than just a table. Fined Grained Access control or Virtual Private Database (VPD) allow data access policies to be applied at the row and column level, this enables organizations to apply very simple data access policies e.g. A sales manager can only query customers within his territory to complex data access requirements e.g. All users of application “A” can access any customer and see all information, but users of application “B” can only access customers within their region and do not have access to the column ADDRESS_LINE1 & ADDRESS_LINE2. These data access policies could be built into the applications but a user that has adhoc query capabilities of the data could sidestep these rules and be able to view all rows and all columns. With the use of VPD these data access policies would be built into the database, so the adhoc query would still only be able to see the data that they are restricted too.
Gartner has predicted that by 2020, large global-enterprise use of data masking or similar pseudonymization techniques will increase to 40%, from 10% in 2016.[1]The use of VPD makes masking of data simple, the policy added to the table will include the columns that require masking. A column that is masked will either stop a row from being returned or the column will be returned as null, depending on how the VPD policy is defined.
With the use of VPD a policy can be created that will define the rows and columns of a table that a user has access too. Allowing a user access to just the data that matches the corporate data access/ security policies will reduce the exposure that the company may have and allow the user to focus on the data they need.
Although VPD will not solve the issue of a data breach it can help minimize the data exposure.