by Robert Buda | Feb 26, 2019 | Best Practices, Oracle, virtual storage
Virtualization brought with it some other amazing technologies, one of which was thin provisioning for storage. Thin provisioning offers significant value by allowing an administrator to create a server with a large supply of storage, while actually allocating only what is currently needed.
Thin provisioning is a good option when used in a development environment or other scenario where only test data would reside on the virtual server. But there are some thin provisioning disadvantages for production environments because of the high potential for downtime and data loss.
Over-Subscription
Thin provisioning causes trouble when more storage is provisioned than is available in the underlying hardware. For instance, when you thin provision, you can store a 4 TB virtual disk on a 400 GB physical volume. As long as you use less than 400 GB of space inside the virtual volume, the setup works well. But what happens when you use 401 GB?
Over-subscription is what happens when you subscribe more storage than is available. This will cause I/O errors on your server, which can lead to irreparable damage to your virtual server and/or application. The damage is exacerbated in a production environment because it can result in partial or total data loss.
Two Ways To Remedy Over-Subscription
There are two approaches that help to remedy an over-subscription problem.
Increase Your Virtual Disk Repository
The first is to increase the over-subscribed virtual disk repository. This usually requires a SAN administrator to increase the repository volume in the SAN storage manager and rescan the volume via the SCSI bus.
Create A New Virtual Disk Repository
If you cannot extend the initial volume, the second approach is to create a new virtual disk repository and migrate some of your virtual servers to this new storage.
One of our Oracle clients is using Oracle virtualization software for storage. The original DBA (before we were involved), created 30 TB of thinly provisioned vdisks. But the entire size of the volume on which these vdisks were subscribed was only 20 TB. Everything worked fine until the total actual usage of those vdisks reached 20 TB, at which point I/O errors signaled that something was very wrong.
After gaining access to Oracle’s VM manager, we were able to see that the volume was oversubscribed. We corrected the problem using the second approach described above. We created a new disk repository and moved data files one at a time until everything was moved over and the space issue was resolved.
Conclusion
In summary, using thin provisioning can be wonderful if managed correctly with proper forecasting. But if not managed carefully, it can lead to negative disadvantages that outweigh the storage saving benefits.
If you’re using thin provisioning today, or looking for other ways to make the best use of your physical and virtual storage, contact Buda Consulting to talk over potential options and what’s right for your environment.
by Robert Buda | Mar 30, 2018 | Database Security
How well do you protect your database?
You may think you are protecting it pretty well, but lets challenge that. Lets apply the same thinking to the database as you would to something more tangible.
Precious Personal Possessions
Imagine that you live in a gated community. Nobody can get in without passing the guard booth and giving the proper passcode and reporting who they are visiting.
Now you are about to leave the house for the evening and you don’t want to take that 150 year old priceless diamond pendant that you inherited from your grandmother with you. You know that the security guard at the gate has your back, right?
So what would you do?
- Leave the diamond out on the table and don’t bother locking the front door, because the security guard has your back.
- Put the diamond in the drawer, cover it with a few pairs of sox, and lock your front door.
- Put the diamond in your safety vault, lock your front door, and engage the alarm system. You do this because you know that someone might get past the gate.
Precious Company Data
Now think about the precious data that runs your business in your database. It is worth hundreds of thousands or even millions of dollars to your business. So you want to protect it, right?
You know that the doors to the data center are locked at night, and the security guard has your back. You know that the your network firewall is secure and your security team has done penetration tests to make sure nobody can get in.
So what do you do?
- You don’t worry too much about the database, because the firewall and the security guard have your back.
- You implement strong database password policies and you encrypt your data to make it harder for people to use the data if they get to it.
- You implement strong database security like Oracle Database Vault, Virtual Private Database, Data Masking, and Transparent Sensitive Data Protection. You conduct security audits, penetration tests, and security assessments on the database itself. You implement ongoing database monitoring. You do this because you understand that someone might get past the gate.
In the case of a very precious heirloom, most people would not even consider the first choice, and if the items are very valuable, will insist on the third option, strong security in a tight perimeter around the valuable object.
But some businesses rely only on option 1 for the data that runs their entire business. They lock the doors of their office at night, but do little to protect the data that is far more valuable than the office space.
If you would like to talk about options for securing your precious data. Looks for us at www.budaconsulting.com/security
by Robert Buda | Mar 16, 2018 | Database Security
Shrink Your Sensitive Data Footprint
Protecting data is hard. Knowing for sure that you have identified and mitigated every vulnerability takes a lot of work and constant vigilance. The more servers you have to harden, the more databases you have to protect, the more work it is, and the more likely you will leave a hole somewhere. So it makes sense to reduce your sensitive data footprint as much as possible.
Data Masking
The concept of data masking has been around for a long time, but we have found that many companies don’t yet use it in their development environments. By having full production data sets in dev and QA environments, we needlessly expand our sensitive data footprint and add significant vulnerability.
Think about it, our development environments are the least protected of all of our systems, and they are the most exposed. Developers frequently have full access to all the data in the development environment, and even have the ability to extract data, typically loading subsets of it into their own, even less protected, systems, in order to do local development and testing. Many companies are now using cloud technology for development environments as well, which are outside of their corporate firewalls, adding even more risk.
This significant risk is relatively easily mitigated by masking all data in development and QA environments.
How it works
Typically, data masking vendors will have a tool that enables the discovery of sensitive data. Discovering this data is helpful even if you don’t plan to mask your data. The tools have default, expected, search patterns for sensitive data, and you can add your own as well if you feel that your system contains sensitive data that is not represented by the default patterns.
After discovering the data, you can specify a pattern or function that will be used to alter or obfuscate the data as it is stored in the database (or in the case of SQL Server, will alter it as it is extracted from the database). For example, you can choose to randomize the numbers within a phone number field in order to change the values but keep the formatting so development and testing can still be done using the data.
Data Masking offerings by Oracle and SQL Server
Oracle has a very robust Data Masking solution called Data Masking and Subsetting. It is not cheap but the cost is not significant compared to the costs associated with a data breach. And after you thoroughly mask the data, you no longer have to spend as much time and effort hardening the target environments, so the costs are further mitigated. It works by identifying and then masking data that will be placed into development environments. So the development environments never have the real data.
SQL server’s data masking offering, Dynamic Data Masking (DDM), masks data as it is retrieved by sql queries. This is less secure because the target databases do have the real data in them. Only users with unmask privileged users can view the real data but that does require additional security administration on the development environments. So while this is an improvement over having no masking, it is not as secure as using Oracle’s approach.
Third Party Data Masking Offerings
There are also third party tools for data masking such as DataVeil, which has a free version that includes some standard masking functions and a paid version that includes some more advanced masking functions. Data Veil works on both Oracle and SQL Server, as well as other databases.
Just Mask It
So the bottom line is that there are good options available for masking data in your development environments and doing so can significantly reduce your vulnerability to data leaks . With any of these tools, it will take a little work up front to discover and to determine the proper masking functions for the data, but once done, it can be re-applied easily each time you refresh your dev environments and it is definitely worth the effort.
If you know of any other great data masking tools please leave a comment. If you would like to chat about data masking or have any questions you can find us at www.budaconsulting.com.
by Robert Buda | Mar 13, 2018 | Database Security
Discovering Sensitive Data
Oracle has long had strong database encryption functionality and it keeps getting better. But they have been lacking a simple way to identify sensitive data in the database so you know what to encrypt, audit or protect via policies. I thought that might have improved recently with the release of a new database security assessment tool called DBSAT.
New Oracle Security Tool
I was very excited when Oracle released their new free database security assessment tool (DBSAT). It is very easy to install and use so it lowers the barriers to properly securing your data. This is good and I think if you use no other tool, then this is a good place to start with your database security if you are using Oracle. The tool helps you find many common vulnerabilities relating to missing patches, poor configuration, excessive access rights, and other database vulnerabilities that can be very dangerous if they go unnoticed.
However, I found what I consider to be a serious deficiency in the tool and a missed opportunity,
There are three parts to the DBSAT tool. These are called the Collector, the Reporter, and the Discoverer.
The Collector collects information about vulnerabilities such as missing patches, poor configuration, etc. It does a pretty good job here, although I did find some vulnerabilities identified by other scanning tools that that it did not catch. More on that in a future article.
The Reporter takes the results of the Collector step and presents them in an easy to read PDF report. This is very helpful but it lacks the ability to sort and filter vulnerabilities that some of the other tools have, and there can be a very large number of vulnerabilities so this can be a material deficiency as you begin to take steps to mitigate the vulnerabilities that are reported. More on that in a the future article.
Discoverer Doesn’t Discover Everything
The Discover is the real topic of this article. The Discover is intended to identify sensitive data in the database. I was very excited to see this feature in DBSAT because the only Oracle tool available to do this previously was a feature of Application Data Modeling (ADM) which is an element of the Data Masking and Subsetting package. This package requires an extra license and it is a bit cumbersome to use for this purpose. ADM gives the user the ability to identify sensitive data and together with Transparent Sensitive Data Protection (TDSP), the ability to enforce rules protecting that data.
As I tested DBSAT, I was disappointed to find that it is significantly less robust then the alternate method using ADM. The more robust ADM method allows the user to specify three patterns to search for sensitive data. These patterns are checked against the Column Names, Column Comments, and the data itself. You can specify a regex expression looking for certain patterns or words in the data, for example, ^\d{3}-\d{2}-\d{4}$ for a string that looks like a social security number. Unfortunately, DBSAT seems to only allow searching for patterns within the Column Name and the Column Comments, and does not provide the ability to search for patterns in the data. This approach relies heavily on the designers having used descriptive column names or comments and I think this leaves significant potential to miss sensitive data.
Application Data Modeling
To use ADM in order to find the sensitive data in your database, you must license the Data Masking and Subsetting package. You find ADM in OEM by navigating to Enterprise/Quality Management/Data Discovery and Modeling. The process involves creating a data model which collects meta data about your schema including table and column information. Then you define patterns for finding sensitive data in the tables, and a job will be executed in the background that will identify columns with names, comments, or data that match the patterns that you specify. The job will produce an XML file that can be used with Transparent Sensitive Data Protection or for other purposes.
If you specified a robust set of sensitive data patterns, then this XML file is a much more robust list of potential sensitive data than the list provided by DBSAT Discoverer.
Example
Lets say you have a the following table in an organization that uses An Employee’s Social Security Number as his Employee Number. For simplicity, lets also assume that no column comments have been assigned.
Employee (Employee Name, EmployeeAddress, EmployeeNbr)
“John Smith”, “18 Main Street, Exton, PA”, “721-99-2998”
“Peter Jones”, “20-42 Broadway, NYC, 10019”, “782-48-2332”
“Anna Newman”,”Anchorage AL, 22884″,”773-33-2002″
Without knowing the actual name of the EmployeeNbr column, or that it uses the SSN, we might set up search criteria similar to this:
- Column Name: Contains SSN, Identifier, Social
- Column Comment: Contains SSN, Identifier, Social
Using DBSAT, you can only specify these two criteria, so we would miss the entire EmployeeNbr column because it does not match the criteria for names or column comments.
But if you use the Application Data Model functionality to identify the sensitive data, you can specify a pattern to match against the data in the table. Then it will pick up this column despite the vague column name. A Pattern might look like this:
Data Pattern: ^\d{3}-\d{2}-\d{4}$
Use ADM With Transparent Sensitive Data Protection
So if you can license Data Masking and Subsetting, then I recommend using ADM to identify sensitive data in your database. Then encrypt that data and/or protect it with Transparent Sensitive Data Protection.
Either way, the other features of DBSAT such as finding vulnerabilities related to patching and poor configuration make it a good addition to the database security administrator’s toolkit.
Other Tools
This article only discusses tools provided by Oracle. There are numerous other vendors that provide external tools to discover sensitive data including Imperva and Spirion.
If you would like more information about how to keep your Oracle data safe contact us or request an Oracle database health check.
by Robert Buda | Feb 7, 2018 | Best Practices, Database Security
New Security Assessment Tool — Why it matters?
Oracle just released a database security assessment tool (DBSAT) that identifies security vulnerabilities in Oracle Databases. I will be writing about that tool in a coming article but the release got me thinking about how little many companies do to protect their data. Since this was prompted by the Oracle Release, this post will be Oracle tinted, but the concepts hold true for all database management vendors. And what does this all have to do with teenage drivers? Stick with me, I will tie it all together, I promise.
You Have Gaps
Yes, that’s right, there are gaps in your database security. You may think there aren’t. You may kind of know there are but you know that you can’t really make it totally secure, so you rely on your network security layer, close one eye, and tell yourself that you are secure. But you are not. Not really.
Like Kids and Cars
The truth is you can never be totally secure. There will always be a hole somewhere. But the best play is to minimize the risk wherever you can. Like when you help your kids buy their first car. You know that putting a 17 year old behind the wheel is dangerous. You know that locking them in their room is much safer then letting them behind the wheel. But you must let them drive. So you do everything possible to protect them.
Reducing the Risks
You help them buy the biggest, safest car that you can afford. You give them the best driving lessons that you can find. You teach them for hours and hours how to anticipate and avoid others on the road that are looking at their phones instead of the road. You insist on a standard shift car so they can’t text and drive. And then you hope for the best. But you did everything in your power to mitigate the risk before hoping for the best.
The same must be true for your data. Your data will never be 100% safe. Anyone who tells you that you are is either lying or fooling themselves. But there are steps that you can take today to dramatically lower your risk, and you are probably not taking them.
You secure the network layer. You enforce strong passwords. You encrypt data in transit throughout the network. That is all great. But if that is all you do then it is like buying your kid a big old pickup truck with a strong body but no airbags or seatbelts. You are strengthening the outside, but you are neglecting the inside, where the kids are. (OK I know its an imperfect analogy but work with me!)
To really mitigate the risk to your precious data, you must secure your data from the inside, not just the outside. Your database software provides the capability to add significant layers of security. You have basic features available such as data encryption, role based security, and strong internal password policies. And you have advanced security features such as Virtual Private Database, Label Security, and Transparent Sensitive Data Protection.
Missed Opportunities
In most organizations, these security features are either unused, underused, or misused. It is an opportunity to significantly reduce data risk that is being widely missed. If you are serious about protecting your data assets, you can approximate total data security by properly implementing the appropriate combination of these strong database security features in addition to the network security that you already practice. The cost of implementing stronger security may be tiny compared to the cost of damage to your business that can be done by a breach.
Take the next step to secure your data
If you are serious about protecting your database assets, give us a call and we can help you protect your data using the tools that are available from your database vendor.
And good luck with the kids!
