by Robert Buda | Jun 8, 2020 | Best Practices, Database Security, Oracle
Have you been wanting to encrypt your Oracle database “since forever,” but feel like you just can’t afford the downtime? If a lot of data is involved, taking it all offline and encrypting it could be very time-consuming. So you’ve been putting the process off, while keeping your fingers crossed that your company’s network security will somehow protect you from a data breach and associated legal, compliance and reputational impacts.
But did you know that you can now encrypt existing tablespaces in-place, either online or offline in Oracle? In case you missed it, Oracle Enterprise Edition version 12.2 (released in 2017) added Transparent Data Encryption (TDE), a much-needed feature that enables you to encrypt an existing database while it remains online.
If you’ve been running an earlier Oracle version and haven’t seen a compelling reason to update, TDE could be it. This capability is a game-changer for those who want to “do the right thing” and encrypt their data at rest, but haven’t wanted to incur the downtime.
At a high level, here is how TDE works:
-
- First, encrypt the system tablespaces (these must be done separate from user tablespaces)
- Next, encrypt the user tablespaces, one at a time.
- Finally, drop and recreate any temporary tablespaces (these cannot be converted online)
That’s basically all there is to it! There are some technical issues that your DBA and/or security group will need to work out, such as key management and disk space. (You must have enough available disk space during the conversion to duplicate your largest tablespace.)
Of course, you need to back up your entire database before you start the encryption process. If you decide to tackle encryption gradually, then just back up each tablespace before you convert it.
Taking the important step of encrypting your sensitive data at rest will significantly improve your security posture.
So what are you waiting for? Get encrypting!
To schedule a free consultation on your database security, including encryption requirements, contact Buda Consulting.
by Willie Gray | Mar 20, 2020 | Backup and Recovery, Best Practices, Oracle DBA
I’m sure you have heard—if not experienced—the following scenario. A student is working on a research paper and suddenly her PC crashes. Because she did not follow the golden rule of saving your document every sixty seconds, she lost hours of work.
You would think by the time you are well into your career things like this would no longer happen, but unfortunately this kind of thing still happens all the time. When it comes to data, the one thing most people think about is backups. As long as the backups complete without error you feel safe, as you believe you have all of the files you need to restore your database in the event of a disaster.
But what if I told you that is not a complete disaster recovery strategy?
We saw this issue play out recently when we were contacted by a company that needed our assistance. The client was trying to restore a database after temporarily losing power and encountered a software bug that was requesting an old archive log that was applied to the database, which happened to be a standby database. Because the archive log requested was so old (a search of emailed backup job logs found the archive log was backed up 9 months prior) and their retention policy only saved backups for 14 days, there was no way for them to get the archive log back. This meant they were not able to restore their data. Long story short: the company lost all of the data in the database.
When one side of our disaster recovery strategy is working we often overlook the second side of the strategy, which is making sure we are able to restore our database using the files created. While the backup job may complete without errors, file corruption or erroneously deleting one of the backup files can render your recovery plan and data useless. This is why we here at Buda Consulting always recommend that our clients perform biannual disaster recovery restore tests at a minimum, with quarterly disaster recovery restore tests at a maximum.
As the old saying goes, “It’s better to be safe than sorry,” and testing your disaster recovery data is essential to keeping you and your data safe!
Concerned (as you should be) about your disaster recovery and business continuity capability? Contact Buda Consulting to schedule a free consultation.
by Robert Buda | Mar 3, 2020 | Best Practices, Database Security, Oracle DBA
Managed Health Systems of Indiana patient health information, July-September, 2019; Microsoft customer service and support records, January 22, 2020; Wyze email addresses, December 30, 2019; Georgia Tech student data, March 2019.
What do all of these breaches have in common? The data that was stolen was inside a database.
Yet when most companies think about data security, they still focus on securing the network, and spend very little time and energy making sure the databases—where the data actually lives—are safe.
When was the last time you had a network security assessment done? If yours is like most companies, it was pretty recently… and that’s good.
But when was the last time you had a database security assessment done? If yours is like many companies, the answer is “Never.”
Even if your network security posture is robust, it is only a matter of time before your network is breached. And don’t forget about “insider threats,” both malicious and accidental. It is best to add another layer of protection between the bad actors and your data.
Make sure that when cybercriminals do get past your network protections, your database will keep them out.
Download our Database Security Roadmap get valuable insights into create an in-depth defensive posture to protect your data.
by Robert Buda | Feb 19, 2020 | Best Practices, Database Patch News, database patching, Database Security, Oracle, SQL Server
Welcome to Database Patch News, Buda Consulting’s monthly newsletter of current patch information for Oracle and Microsoft SQL Server. Here you’ll find information on available patches—including security patches—and desupported versions made available during the past month.
Why should you care about patching vulnerabilities and bugs? Two big reasons:
- Unpatched systems are a top cyber attack target. Patch releases literally advertise vulnerabilities to the hacker community. The longer you wait to patch, the greater your security risk.
- Along with running a supported database version, applying the latest patches ensures that you can get support from the vendor in case of an issue. Patching also helps eliminate downtime and lost productivity associated with bugs.
Here are the latest patch updates for Oracle and SQL Server:Oracle Patches:
19c
DATABASE RELEASE UPDATE 18.9.0.0.0.200114
OJVM RELEASE UPDATE 18.9.0.0.0.200114
18c
DATABASE RELEASE UPDATE 19.6.0.0.0.200114
OJVM RELEASE UPDATE 19.6.0.0.0.200114
12cR2
DATABASE RELEASE UPDATE 12.2.0.1.200114
OJVM RELEASE UPDATE 12.2.0.1.200114
Regular support ends Mar 2023 and extended support ends Mar 2026
12cR1
DATABASE PATCH SET UPDATE 12.1.0.2.200114
(Extended Support Contract Required)
OJVM PATCH SET UPDATE 12.1.0.2.200114
(Extended Support Contract Required)
The last freely available patch was July 2019 for 12.1.0.2. The Oct 15 2019 Patch Set Update (PSU) is available but may require an extended support purchase to access it. Patches will be released until July 2021 for this version. PSU 12.1.0.2.191015 is available.
11gR4
DATABASE PATCH SET UPDATE 11.2.0.4.200114
(Extended Support Contract Required)
OJVM PATCH SET UPDATE 11.2.0.4.200114
(Extended Support Contract Required)
The last freely available patch was October 2018 for 11.2.0.4. PSU 11.2.0.4.191015 is available but may require clients to purchase extended support to access it.
Oracle Engineered Systems
Oracle Exadata System Software for 18.1.24, 19.2.10 & 19.3.4
Oracle Exadata QFSDP for Jan 2020
Oracle SuperCluster QFSDP for Jan 2020
SQL Server Patches:
SQL Server 2019 – Cumulative Update 1 released on 01/07/2019
SQL Server 2017 – Cumulative Update 18 released on 12/09/2019
SQL Server 2016 Service Pack 2 – Cumulative Update 11 released on 12/09/2019
SQL Server 2016 Service Pack 1 – Cumulative Update 15 released on 07/09/2019
SQL Server 2014 Service Pack 3 – Cumulative Update 4 released on 07/29/2019
SQL Server 2014 Service Pack 2 – Cumulative Update 18 released on 07/29/2019
by Robert Buda | Jan 31, 2020 | Best Practices, Cloud, Database Security, Uncategorized
In response to the recent Capital One data breach, where a hacker exploited a misconfigured open-source Web Application Firewall hosted within Amazon Web Services (AWS), the Amazon CTO reminded customers that they must secure their own data when housed on AWS infrastructure.
This seems obvious, but it is a very important point.
When you move your data into AWS or any cloud provider, because it is not in our your data centers, and because you often no longer employ full-time people to manage the server hardware and software that house that data, you might get the feeling that someone else is managing our data just as carefully as our own staff once did.
That may be true for some dimensions of data management. For example, the cloud provider is responsible for making sure that the hardware stays up and running. Likewise, when you use software as a service (SaaS) or platform as a service (PaaS), the service provider is responsible for making sure that the application software and/or operating system stays up and running. In the case of infrastructure as a service (IaaS) offerings, the customer is still responsible for the latter two functions.
But in all the above cases, the customer is ultimately responsible for the security of their own data. The AWS security documentation describes it this way:
-
- Security of the cloud – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the AWS Compliance Programs. To learn about the compliance programs that apply to Amazon EC2, see AWS Services in Scope by Compliance Program.
- Security in the cloud – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations.
The key takeaway is that if you have your data in any cloud service, you must be as rigorous in securing that data as if it were in your own data center—and in some cases even more so.
Following are some key things to think about when moving your data into the cloud. These are the same considerations you need to focus on when keeping your data in-house. Some of these concerns only apply to IaaS in the cloud, while others are relevant to all cloud service scenarios.
-
- Is the underlying storage configured properly so that only the database software, application software and authorized users can access it?
- Is the data encrypted both at rest and in transit?
- Is proper authentication in place for the application or database, to ensure that only proper users can gain access to the system?
- Is proper authorization in place for the application or database, such that data is exposed only to the proper users?
- Is the network configured properly to reduce the surface area vulnerable to attack?
These considerations are not new. In fact, our Database Security Roadmap, initially created primarily with on-premises systems in mind, is still completely relevant with cloud technology.
Download the roadmap to make sure you have all the bases covered.
