by Robert Buda | Feb 13, 2015 | Best Practices, Cloud, Database Security, Oracle
As I blogged about recently, Database-as-a-Service (DBaaS) is an important option for many Oracle database customers. But “data in the cloud” is not right for every business, and there are important issues to be aware of as you consider how or if to leverage DBaaS.
Following are five concerns that might limit your use of DBaaS. This is not an exhaustive list, but it covers the most critical areas:
One: Security constraints
Your data is your company’s most valuable asset. But in the wrong hands, it can also be a major threat to your reputation and even your operations. Likewise, many organizations in healthcare, financial services and other verticals face strict compliance requirements that encompass both data security and third-party relationships involving hosting or even transmitting data. When your data is in the cloud, security is largely outside your control. When (let’s be realistic: it’s not a question of “if”) the DBaaS provider’s comparatively large attack surface is breached, will your data be safe? How can you know for certain whether it was or wasn’t compromised? What, if any, additional precautions can you take when data is at rest or in transit to and from the cloud?
Two: Data governance/access
When your data is in the cloud and a third-party is managing it, who has access to it? And what levels of access do they have? With DBaaS, you don’t have direct control over that. People outside your organization, very possibly on another continent, could have access for a wide range of reasons; e.g., database administration or IT infrastructure monitoring. Privilege escalation vulnerabilities can be greater in DBaaS scenarios. Some classes of data (test/development data, non-sensitive data, etc.) are better suited to this scenario than others. What is your level of comfort with how your data is stored and accessed in the cloud?
Three: Database availability, performance and uptime
When you move a database from on-premise into the cloud, you increase the distance between your application and your data. You also introduce factors outside your control that could make your data unavailable or impact database uptime. WAN link failures and service provider outages are probably the two main concerns. What are the service provider’s availability and uptime guarantees? Do you know that your data is being properly and securely backed up? If problems occur, what is your recourse? What is your recovery plan?
Four: Database performance and user experience
When a database resides in a public cloud environment, there are multiple shared infrastructure components supporting it, including the Internet itself, which you can’t control and in many cases would be challenged to monitor. As a result, users’ experience with accessing the data can be very inconsistent. This issue can be made worse when the volumes of data involved are large. You or your users might also experience poor performance as a result of any number of issues with the service provider’s infrastructure. Will the data service provider do a good job with data management? If they don’t, how much time, energy and money will it take to rectify the situation?
Five: Vendor lock-in and interoperability concerns
DBaaS customers naturally want to be able to shift from one provider to another without a lot of trouble and expense. But cloud vendor lock-in can be burdensome and costly. It may not even be a matter of dissatisfaction with the provider; you may simply want to use different providers that are closer to your diverse customers, in order to minimize latency issues. Or your provider could go out of business. If you write/optimize application components for one DBaaS environment, will they run on another DBaaS provider’s infrastructure? Or are you stuck with that provider’s APIs?
Still thinking about using DBaaS? To get some expert advice on whether DBaaS is right for your Oracle databases, contact Buda Consulting. Concerned about data security? Sign up for a database security audit.
by Robert Buda | Feb 4, 2015 | Best Practices, Database Security, Oracle DBA
According to recent research, Database-as-a-Service (DBaaS) is projected to grow at almost 90% year over year, to about $2 billion by 2016. The key drivers, as you might expect, are costs and time saved. From SMBs to multinationals, organizations are moving Oracle databases to the cloud in droves.
Actually, there are two ways to run a database in the cloud: DBaaS and virtual machine images. With DBaaS, you purchase access to a database service from a cloud database provider. (The provider could even host and manage the database for you, which is essentially a managed hosting model.) Virtual machine images are purchased for a specified time and then uploaded to the cloud on a one-off basis.
Proponents of DBaaS say it lets businesses deploy new databases faster and cheaper than on-premise. Depending on your own IT compared with your service provider, you might also potentially get better performance. Many also claim that database security is stronger in the cloud as well—though that, of course, also depends on how your security stacks up against the service provider’s.
According to Javier Puerta, Oracle’s director of core-technology partner programs for EMEA: “DBaaS offers organizations accelerated deployment, elastic capacity, greater consolidation efficiency, higher availability, and lower overall operational cost and complexity.”
Other potential advantages for DBaaS include:
- Faster provisioning
- The ability to reduce database sprawl
- Automated and centralized database management
If your application only requires some simple remote storage and data retrieval, DBaaS might be a slam-dunk. But what if more extensive operations are required? Some of the potential disadvantages of DBaaS include:
- Security/privacy and compliance concerns—for many organizations, the sensitivity of the data outweighs all other considerations
- Potential loss of access to data in the event of a disaster or if the service provider goes out of business
- Bandwidth costs associated with the required Internet connectivity
- Runaway costs if usage is not well managed
- Potential for vendor lock-in
- Contractual concerns common to using service providers generally; e.g., who accepts the risk for compromised data (answer: ultimately you do)
Here’s a typical DBaaS use case: You’ve got lots of databases, each variation of which requires some special care. By moving that data online, you could consolidate all those instances under one service, and even partner with a cloud provider to co-manage them. This offers the potential to eliminate sprawl (or at least slow its rate of growth) on your on-premise servers. But you could still end up with “virtual sprawl” and drive up your DBaaS costs.
There’s no question that DBaaS offers compelling benefits for many organizations. But don’t just start making databases in the cloud somewhere without doing your due diligence.
Wherever your data resides, it still needs to be patched and upgraded, monitored, backed up and secured. Your data is your company’s most important asset, and there’s no such thing as a free lunch when it comes to Oracle database administration.
In future posts I’ll discuss some key concerns regarding DBaaS, and when to “proceed with caution.” I’ll also review alternatives to DBaaS, including a “private cloud” with multi-tenancy based on Oracle Enterprise Manager 12c.
To talk over the implications of DBaaS for your Oracle databases, contact Buda Consulting. Concerned about data security? Sign up for a database security audit.
by Robert Buda | Nov 25, 2014 | Backup and Recovery, Best Practices, Oracle DBA
Regulatory compliance issues are top-of-mind for today’s senior executives. New laws and industry regulations are changing how organizations acquire, store, manage, retain and dispose of data. Every Oracle DBA should be aware of these changes because of their sweeping impacts on the DBA job role.
Compliance goes hand-in-hand with security because regulations often mandate that organizations be able to attest or even prove that data—and therefore databases—are secure and controlled. In this context, Oracle DBAs are directly involved in implementing and managing the policies and technologies that support compliance.
What are some of the key regulations that impact Oracle DBAs? Here in the US, one of the most prevalent is Sarbanes-Oxley (SOX), aka the U.S. Public Accounting Reform and Investor Protection Act of 2002. SOX is meant to reduce fraud and improve financial reporting. Its impact on IT is sweeping. In particular, it holds the CFO responsible to guarantee the processes used to produce financial reports, which invariably involve software accessing data stored in databases via processes maintained by DBAs.
For healthcare organizations the major regulatory worry is HIPAA, the Health Insurance Portability and Accountability Act. HIPAA mandates security measures for patients’ personal health information (PHI)—to the extent that an organization must be able to document every time a PHI data element was viewed. HIPAA audits often focus on the processes that drive exception logs and reports. Database auditing is critical in this regard.
Here are some typical Oracle DBA tasks that directly relate to compliance:
- Data quality and metadata management. Ensuring data quality is key to regulatory compliance. If data or metadata aren’t accurate, how can the right data elements be subject to the appropriate regulatory controls?
- Database auditing. As mentioned above, robust database audit capabilities can be essential for compliance with HIPAA and other regulations and policies that mandate tracking database usage. What data was accessed when and by whom? Database audit software can tell you. Database auditing is also vital for overall information security and detection of security breaches, especially against internal threats.
- Data masking and obfuscation. Data masking practices are generally used to render original data suitable for testing purposes. It looks and functions consistently with the original data, but no longer constitutes personally identifiable information or credit card data, etc. for regulatory purposes. It’s also important for protecting sensitive data from staff (e.g., third-party contractors) working in non-production environments.
- Database archiving and long-term data retention. Regulations often mandate what data must be stored for what period of time. This is also important for legal/eDiscovery purposes.
- Database recovery. Database recovery is also a compliance issue, because it relates to database integrity and availability. If data is lost and can’t be recovered, that can be as problematic as a security breach from a regulatory perspective.
If you’re not sure whether your Oracle database policies, procedures and controls are adequate to support regulatory compliance, Buda Consulting can help. Contact us to discuss a database security assessment to identify areas of noncompliance and provide whatever assistance you need to address them.
by Robert Buda | Nov 20, 2014 | Oracle DBA
How much is bad data costing your organization?
Data is only useful if it is timely, relevant and reliable. Incorrect, redundant and incomplete data introduces risks that negatively impact business operations and skew business analytics/decision-making. Poor data quality also impacts information security and compliance programs. And as businesses amass more and more data, just the cost of storing bad data becomes significant.
Looking at “the big picture,” the cost of bad data to organizations is mind-boggling. For example, a Gartner study found that data quality affects overall labor productivity by as much as 20% and costs companies between 15% and 20% of their operating budgets. A recently published infographic from InsightSquared showed that the aggregate cost of bad data to US businesses exceeds $600 billion, while its total impact on the US economy is estimated at $3.1 trillion.
However, organizations from SMBs to major corporations often fail to address data quality issues in a systematic way. In one report, 68% of companies admitted that they don’t even attempt to measure the cost of poor data quality.
Even if organizations understand the value of improving data quality, they may not have the expertise or the bandwidth to identify and address problems. This is where an outsourced Oracle DBA expert can help.
The first step is usually to conduct an audit to assess what data quality problems are most prevalent in an organization. The most common data quality issues usually include: data duplication, invalid data/formats, incomplete data, data conflicts and outdated/obsolete data.
The next step is to put controls in place that address the root causes of data quality issues so that newly acquired data is of higher quality. There’s no point identifying and correcting erroneous data until such controls are in place. The role of the DBA in this context is to build constraints into the databases that help enforce value ranges, ensure uniqueness and so on.
Data quality controls, in turn, depend on accurate metadata—the data definitions against which controls are applied. In the same way that a building depends on a solid foundation, high data quality isn’t possible without high quality metadata. For consumers of data, metadata explains “who, what, when, where, why” the data is about. To apply regulations and policies to data, for example, the corresponding metadata must be correct.
Once controls and metadata have been improved, it’s time to correct the existing data itself. The challenges here can be daunting. According to data quality experts, billing records generally have error rates between 2% and 7%, for example. Data profiling is one way to isolate and prioritize the most problematic areas within the most valuable data assets, which are the “quick wins” where you want to invest effort to correct bad data.
Especially in markets like financial services, where data has a very short “shelf life” and timely, accurate decisions are the cornerstone of success, high data quality is paramount. It’s also vital in highly regulated industries like healthcare, where poor data quality can undermine compliance and literally constitute a crime.
To talk with an expert about how to assess and address data quality concerns in your business, contact Buda Consulting.
by Robert Buda | Oct 22, 2014 | Database Security, Oracle DBA
Data security is not a “set it and forget it” condition—it’s highly dynamic, changing as your environment evolves, new threats appear and new vulnerabilities are introduced. And as the recent rash of high-profile breaches in retail databases illustrate, securing your databases is at least as important as securing other parts of your infrastructure.
The end of the year is often a time when we get things organized and throw out what we don’t need. It’s also a great time to schedule a database security assessment and rid your organization of some data security vulnerabilities you definitely don’t need, like obsolete user and test accounts and inappropriate access privileges.
A database security assessment with Buda Consulting will identify and report on the full spectrum of vulnerabilities in your environment, including misconfiguration, non-applied security patches and “open door” passwords. It will also tell you exactly which vulnerabilities are most critical to mitigate.
We start with a discovery scan, which searches your entire network using automated tools and inventories all the database signatures it finds. This is the best way to locate “rogue” databases that users spin up on their own, which may contain confidential data and often don’t follow security policy.
Next we perform a password scan, which is a form of penetration test. We try to connect to all your databases by throwing easily guessed passwords (e.g., “user” and “123456”) at them. Do you have standard system accounts on older databases that aren’t locked and have default passwords that haven’t been changed? This scan will find them.
It’s amazing how much sensitive enterprise data is just waiting to be exposed in this way. For example, we discovered awhile back that one of our clients was using the default username and password for a very privileged account. I warned them that this was a critical vulnerability, but they failed to fix it and shortly thereafter were hacked big-time. It took them several weeks and an embarrassing amount of money to restore their systems and data.
The third part of the assessment is a comprehensive vulnerability scan. Our automated toolset will quickly uncover missing patches, configuration problems, and problematic settings or practices that can leave you vulnerable to escalation of privilege attacks, Denial of Service (DoS) and other forms of cybercrime.
Perhaps the most important part of the assessment is what we do with the thousands of vulnerabilities that our tools will almost certainly generate. We sit down with your DBAs and boil that list down to the critical vulnerabilities in your environment, which you should address immediately. We also check off the problems for which you have mitigating controls already in place.
Along with all that vulnerability scanning comes a “user rights review.” This is a check for user access that is authenticated at the database level (as opposed to the application level). This is a great way to root out “developer” or “test” accounts that are no longer needed but haven’t been disabled, leaving a hole for attackers to burrow into your data stores. It also exposes “least privilege” vulnerabilities that otherwise get lost in the details. This review identifies what database accounts have access to sensitive data, and how they received that access. Was access granted directly to that username, and by whom? Or is it conferred to a role assigned to that user?
Since applications commonly authenticate users at the application level instead of the database level, it is important to perform similar user access rights reviews within the applications as well. This kind of review varies greatly depending on the way authentication is handled and how the access privilege information is stored in the database. We can work with you and your application vendor to develop a user rights review for your application.
In-house DBAs often don’t have the objectivity (or the time) necessary to perform a database security assessment. Plus it takes skill and experience to run the tools and whittle down the vulnerabilities to specify what must be fixed, what it would be nice to fix, and what can be addressed indirectly through mitigating controls. Otherwise you just have a bewildering list of vulnerabilities that, in and of itself, is of little value in improving your security posture.
Download Buda Consulting Database Security Assessment for a full description of our Security Assessment using Trustwave AppDetective Pro.
