Oracle SQL Firewall: A New Feature That Blocks Top Database Attacks in Real-Time

Oracle SQL Firewall: A New Feature That Blocks Top Database Attacks in Real-Time

Oracle 23c introduces a very powerful and easy-to-use database security feature that many users will want to try, especially for web application workloads. Called Oracle SQL Firewall, it offers real-time protection from within the database kernel against both external and insider SQL injection attacks, credential attacks, and other top threats. 

Oracle SQL Firewall should be a huge help in reducing the risk of successful cyber-attacks on sensitive databases. For example, vulnerability to SQL injection due to improperly sanitized inputs is currently ranked as the #3 most common web application security weakness overall in the latest OWASP Top 10. This tool effectively eliminates SQL injection as a threat wherever it is deployed.

SQL Firewall is intended for use in any Oracle Database deployment, including on-premises, cloud-based, multitenant, clustered, etc. It is compatible with other Oracle security features like Transparent Data Encryption (TDE), Oracle Database Vault, and database auditing.

How Oracle SQL Firewall works

SQL Firewall provides rock-solid, real-time protection against some of the most common database attacks by restricting database access to only authorized SQL statements or connections. Because SQL Firewall is embedded in the Oracle database, hackers cannot bypass it. It inspects all SQL statements, whether local or network-based, and whether encrypted or unencrypted. It analyzes the SQL, any stored procedures, and related database objects. 

The new tool works by monitoring and blocking unauthorized SQL statements before they can execute. To use it, you first capture, review, and build a list of permitted or approved SQL statements that a typical application user would run. These form the basis of an allow-list of permitted actions, akin to a whitelist. 

You can also specify session context data like client IP address, operating system user, or program type on the allow-list to preemptively block database connections associated with credential-based attacks. This includes mitigating the risk of stolen or misused credentials for application service accounts.

Once enabled, Oracle SQL Firewall inspects all incoming SQL statements. Any unexpected SQL can be logged to a violations list and/or blocked from executing. Though the names are similar, Oracle SQL Firewall is much simpler architecturally than the longstanding Oracle Database Firewall (Audit Vault and Database Firewall or AVDF) system. You can configure the new SQL firewall at the root level or the pluggable database (PDB) level.

Is there a downside to using Oracle SQL Firewall?

In part because it is still so new, Oracle SQL Firewall performance data is not widely reported online. Transaction throughput is vitally important for many applications, so it’s possible that SQL Firewall would create unacceptable overhead even if it were minimal. The good news is that “before and after” performance testing in your environment should be straightforward using best-practice testing techniques.

Oracle SQL Firewall administrative security is robust and logically integrated with other Oracle Database admin security, so it does not introduce new security risks. For example, only the SQL_FIREWALL_ADMIN role can administer the tool or query the views associated with it. SQL Firewall metadata is stored in dictionary tables in the SYS schema, which rely on dictionary protection like other such tables in SYS.

Who should use Oracle SQL Firewall?

For any business that needs to improve application security, such as for compliance with US government supply chain regulations or as part of a Zero Trust initiative, Oracle SQL Firewall could be a good choice. It could prove especially useful in DevOps environments due to its minimal impact on application development and testing timelines

What’s next?

A goal for this blog post is to encourage organizations using Oracle 23c to implement SQL Firewall. It is a low-effort way to improve application and database security and significantly reduce information security risk associated with the sensitive data it protects.

To speak with an expert on how Oracle Database Firewall could improve your database security, and how it might fit with your overall security goals and challenges, contact Buda Consulting

 

 

 

5 Tips for a Successful Oracle Database Migration

5 Tips for a Successful Oracle Database Migration

Companies need to migrate Oracle data for a long list of reasons, such as moving workloads from on-premises to a cloud or managed hosting environment, implementing a new system, or launching a big data initiative. But whatever their aim, Oracle database migration projects are widely known to pose a major risk of failure and budget overruns. 

A big contributing factor is the misconception that these are simple data-moving operations. In fact, Oracle database migrations are often complex and require careful planning. Data migration services and technology alone are not a guarantee of success.

This post shares five tips for a successful Oracle database migration.

One: Recognize that Oracle database migrations are a business problem.

Any Oracle database migration is a data problem—and therefore a business problem—first, and an IT problem second. Not the other way around as conventionally assumed.

Without engagement from business and technical leaders, the chances of failure are very high. It’s important to get input from management stakeholders and to know upfront that adequate project resources will be allocated.

Too often, a lack of business involvement and commitment results in an Oracle database migration project that is fraught with unknowns and incorrect assumptions. These later manifest as data loading problems, functional testing failures, and other stumbling blocks leading to time and cost overruns. Eleventh-hour emergencies may also lead to engaging third-party Oracle data migration services without adequate due diligence.

Two: Don’t underestimate the scope of your Oracle database migration.

A big reason Oracle database migration projects falter is that they weren’t correctly scoped in the first place. Many organizations underestimate the effort required to migrate an Oracle database successfully. 

Some of the reasons include:

  • Lack of understanding of the current data landscape
  • Lack of awareness of current data quality issues
  • Viewing the migration as a simple data-moving exercise
  • Failure to get input from business stakeholders on their needs during the project
  • Inadequate data migration services, tools, and/or expertise to support the migration


Plus, like many IT-related projects, Oracle database migrations are subject to scope creep and specification changes. The better you can analyze your current data, including its volume, data types, etc., the better you can scope the migration. 

Three: Focus on data quality from the outset.

“Garbage in, garbage out” is an inescapable reality when it comes to data. Why spend money moving data to a new environment or a new application if it isn’t usable? Yet it’s often when an existing database is migrated that errors, gaps, corruption, redundancies, and formatting issues rear their heads. 

Even if the data was acceptable for its prior uses, it might not meet your new objectives, such as access by new applications. A successful Oracle database migration requires an upfront emphasis on delivering accurate data that meets business needs. Finding out at the last minute that data requires cleansing is sure to lead to project delays, budget crunches, and specification changes. 

Four: Leverage appropriate Oracle technology.

From data cleansing to data movement to data governance, purpose-built Oracle technology can help automate your Oracle database migration to save effort and improve consistency and repeatability. Choosing Oracle tools also adds to the value of your Oracle investment.

For example, if you’re moving an on-premises Oracle database to the Oracle Cloud, Oracle offers a wide range of data migration services and tools to help you migrate data into your target cloud service (e.g., Oracle Autonomous Database, Hadoop, or Object Storage). These include:

  • OCI Data Transfer Service, a low-cost data migration service that accelerates moving even large-scale datasets to or from Oracle Cloud.
  • Zero Downtime Migration (ZDM) for more efficient migration of on-premises databases to the Oracle Cloud leveraging high availability technologies like Oracle Data Guard and Oracle GoldenGate. 
  • Oracle Data Pump to move data between Oracle databases via a choice of methods, including in the cloud and between on-premises and cloud.

Five: Leverage appropriate data migration services.

“We don’t know what we don’t know.” Thus, businesses may be unaware of their Oracle database migration challenges until they are blindsided in midstream. 

While data migration services can help reduce time and cost impacts in these situations, they can also be of value upfront by helping you avoid or prepare for them. Data migration services can help you sort out your best options for moving Oracle workloads from your data center to a public cloud platform or managed database hosting provider, for instance. This starts you off on the right foot and helps eliminate risks to project success.

Data migration services can also give you on-demand access to specialized Oracle expertise that many businesses don’t have in-house. Unbiased, third-party experts can save time with valuable insights, as well as champion the best course of action from a range of options.

What’s next?

If you’re thinking of moving Oracle databases to a cloud or managed hosting environment, Buda Consulting can help you choose the best option for your workloads. We can also handle the complete migration process for you, from installing and configuring your new Oracle environment to migrating your data. All while minimizing downtime and business risk.

Contact us for a free “database discussion” to explore your Oracle database migration goals and concerns.

Oracle Database Assessment: Here’s What to Focus On

Oracle Database Assessment: Here’s What to Focus On

Organizations need to keep a close watch on Oracle operations to ensure agreed service levels are always being met. Database downtime can quickly lead to financial and reputational impacts, making periodic Oracle database assessments integral to the smooth operation of your most critical business systems—and thus your company itself.   Also called Oracle database health checks, Oracle database assessments are part of creating what we like to call a boring database environment: No surprises and no downtime. This peaceful state doesn’t happen by accident, but requires planning and commitment to best practices.  This post explains what an Oracle database assessment should mainly focus on.

What to Check

Oracle database assessments can potentially include a wide range of tasks and probes, some of which might come under the heading of performance tuning, security vulnerability testing, or everyday DBA tasks (e.g., patching).    But to be effective, an Oracle database assessment needs to cover all the key installation, configuration, and policy factors that help improve uptime and/or prevent downtime. Even currently minor issues can cascade towards failure if left unchecked.   Some of the most important parameters and elements in your database environment to review and optimize include: 

  • Alert logs and trace files, to see if any events show up that point to potential database problems 
  • Database maintenance procedures, to validate best practices are being consistently followed
  • Parameter settings, to look for values that can negatively impact performance, security, stability, etc.
  • Data block validation, to identify corrupt blocks and missing files, which are prime causes of database outages
  • Finding invalid objects, which can proliferate and hurt performance and stability
  • Identifying index and tablespace fragmentation, both top causes of degrading database performance 
  • Validating important file configurations like datafiles, Redo log files and Archive log files to ensure database file and backup file integrity and prevent data loss and crashes
  •  Memory, CPU, and disk usage review to proactively address low resource conditions that can impact performance and stability

In-house or Outsource?

Oracle database assessments require significant expertise and attention to detail, especially if your environment is complex with many interrelationships. While in-house DBAs can perform Oracle database assessments, a fresh set of unbiased eyes from outside your organization can add a valuable perspective, while also offering expert guidance and sharing best practices.

Expect a Detailed Report

Whether you perform your Oracle database assessment in-house or outsource it, stakeholders should expect a comprehensive report that documents and prioritizes areas of concern and recommends best-practice next steps in line with business goals. 

What About Database Security?

In our experience, database security is often overshadowed by other security priorities.  Yet database security protects the lifeblood of your business—its sensitive data—and must be a core part of your overall cybersecurity program and strategy.  Because of database security’s importance and complexity, it makes sense to conduct Oracle database security assessments as an adjunct to your Oracle database assessments. A holistic approach that secures the data, the database configuration, identities and access, the network, the database server, and the physical environment is key to eliminating vulnerabilities and mitigating business risk.   Some database security “quick wins” we often recommend to clients include making the best use of Oracle’s built-in security features, which you’re already paying for as part of your database package. This includes downloading the Oracle Database Security Assessment Tool (DBSAT). This free tool scans your database and gives you a security profile including your overall database security configuration, users & entitlements, and sensitive data identification.

What’s Next?

Based on decades of experience helping our clients keep their databases stable and running optimally, Buda Consulting offers a 35-point Oracle database assessment that is reliable, thorough, unbiased, and keeps your in-house DBAs focused on other essential tasks.  Contact us to schedule time with an Oracle expert to talk over your situation, goals, and concerns.  

3 Reasons Why You Need an Oracle Database Expert on Speed Dial

3 Reasons Why You Need an Oracle Database Expert on Speed Dial

There’s never a convenient time for a database emergency. When bad things happen to critical database systems—like alarming error messages, poor performance, potential data loss, or a possible security breach —you need to troubleshoot and mitigate the problem fast.

Keep a Trusted Oracle Database Expert on Your Team.

One: Time is money

Time is certainly money when critical systems are offline. User productivity is zero, customers can’t connect, your reputation is sinking, and so on. Research puts the true cost of IT downtime at somewhere between $2,500 and $9,000 per minute for SMEs ($150,000/hour and up) on average, depending on your industry, business size and other factors.

Even if you guesstimate your actual downtime costs would fall below that range, how many minutes of downtime would it take before whatever DBA service agreement costs you saved are consumed?

Further, you can expect an emergency Oracle Database expert service to charge a premium to save the day. And no matter how good they are, they will be starting with no knowledge of your business or your systems. You’ll be paying a high cost for their ramp-up time.

A trusted remote DBA partner will already know your database environment, so they can potentially solve your problem in less time while also charging less for their time.

Two: Who are these people?

When your critical data is inaccessible you don’t have time to run background checks. If you’re cold-calling an emergency Oracle Database expert, how do you know you can trust them (and whoever is working for them) to keep your sensitive data private? Will their monitoring and support techniques comply with regulations you’re subject to? Do you even know for sure what country the people who will be remotely accessing your systems are located in?

You don’t want to compound a data access crisis with a compliance blunder and/or security breach.

When you have a service agreement with a trusted DBA partner, you’ll know from experience that they are trustworthy, what measures they keep in place to preserve your security, how they address your compliance requirements, and so on.

Three: Proactive trumps reactive

Many third-party DBAs offer proactive service packages that will detect and correct many impending issues before they crash your database or otherwise impact users. This “extra insurance” of a wise eye on your database environment is another big advantage to having a working relationship with an Oracle Database expert. Versus a “break-fix” approach on an expensive emergency basis.

If an emergency does happen on your DBA partner’s watch, they probably offer 24×7 on-call assistance. So, they can start addressing mission-critical production database problems within minutes. Which is most likely faster than starting from scratch looking for a service provider.

Next steps to Finding an Oracle Database Expert

If your critical production databases are not currently protected by an on-call Oracle Database expert, contact Buda Consulting to explore how our DBA support options can enhance your business performance and IT continuity.

Ask us why we never charge for emergency response when you have a service agreement with us. And ask us why you will always have at least two U.S. Based Database Experts that know your environment.

A Focus on Oracle Container Databases

A Focus on Oracle Container Databases

Oracle 12c introduced a major architectural change called Oracle container databases, also known as Oracle multitenant architecture. With this change, an Oracle database can act as a multitenant container database (CDB).

A CDB, in turn, can house zero or more pluggable databases (PDBs), each consisting of schemas and objects that function just like familiar “normal” (pre-Oracle 12c) databases from the viewpoint of applications or SQL IDEs.

Contents of CDBs and PDBs

In the Oracle container database model, the CDB contains most of the working components every Oracle DBA knows, e.g., controlfiles, datafiles, tempfiles, undo, redo logs, etc. The CDB also contains the data dictionary for objects owned by the root container and those visible to all PDBs in the CDB.

Since the CDB contains most of the key parts of the database, each PDB need only contain information that is specific to itself and its schemas and schema objects, like datafiles and tempfiles. A PDB also has its own data dictionary, which includes information about objects specific to that PDB. A PDB can also have its own local undo tablespace. Each PDB has a unique ID and name. To an Oracle Net client, a PDB looks like a separate database.

Besides PDBs, a CDB can also contain zero or more application containers. These are user-created CDB components that store data and metadata for one or more application backends.

Finally, by default every CDB has one root container (named CDB$ROOT) and one seed PDB container (named PDB$SEED). The former stores Oracle metadata and common users. The latter is a template used to create new PDBs.

Deprecation and desupport of non-CDB databases

Beginning with Oracle Database 12c, Oracle deprecated the non Oracle container database architecture, and desupported it in Oracle Database 21c. This means that the Oracle Universal Installer and DBCA can no longer be used to create non-CDB instances of Oracle databases.

Desupport also means that an upgrade to Oracle Database 21c includes a migration to the multitenant architecture. This can be a significant consideration as it can change your approach to database administration.

Benefits of Oracle container database architecture

Is a move to Oracle container database architecture worth the learning curve? Why not just continue to create distinct individual databases or virtual machines (VMs)?

The benefits of moving to the CDB architecture often outweigh the “pain of change” because it can streamline your use of database resources and save you considerable operational and administrative time and costs. Pluggable databases are also easy to move between CDBs, which can increase the agility of your DBA services.

Some specific benefits of the Oracle container database model include:

  • The ability to consolidate code and data without changing existing schemas or applications.
  • Consolidating databases means you can also consolidate IT infrastructure and utilize computing resources more efficiently.
  • Consolidated IT infrastructure, in turn, can simplify monitoring and management of the database environment—including faster backups and patching. Performance tuning can also be easier with the Oracle container database model.
  • Because PDBs look like non-multitenant databases to Oracle Net clients, changes for developers working with Oracle databases are often not dramatic. Developers may notice little difference connecting to a multitenant scenario except that the connection strings have a different format.

Pluggability in the Oracle container database model

One of the top advantages of the Oracle container database model or multitenant option is the ability to unplug a pluggable database (PDB) from one CDB and plug it into a different CDB. This makes it easy to move databases, and can also be used to patch and upgrade database versions. Basically, you just unplug the PDB, move it to the CDB you plan to upgrade, and it will be patched/upgraded automatically along with the CDB.

The Oracle multitenant model also allows you to relocate a PDB to a new CDB or application container even more easily than going the unplugging/plug-in route, with near-zero downtime. During relocation, the source PDB can be open in read/write mode and fully usable.

More about application containers

Along with the Oracle container database model comes the concept of application containers. Similar to a root CDB container, you can use an application container to centralize or “containerize” one or more applications, each consisting of shared configuration, metadata and objects. These are then used by the application PDBs within the application container.

Next steps

The Oracle container database architecture can seem confusing even to experienced DBAs. But it’s more intuitive than it sounds once you’ve had a chance to work with it. The advantages of multitenancy generally far offset the learning curve for many DBAs and their companies.

To speak with an Oracle expert about leveraging the Oracle container database model in your environment, contact Buda Consulting.

Database Encryption: What You Need to Know

Database Encryption: What You Need to Know

These days organizations are storing, accessing, and analyzing more data than ever, both on-premises and on the cloud. As this trend accelerates, the need for effective database security grows right along with it.

Basic security controls like login/password credentials aren’t adequate to safeguard sensitive data from today’s increasingly sophisticated external and internal attacks. To reduce cyber risk, comply with regulations and give customers and other stakeholders peace of mind, many organizations need a holistic security approach that includes database encryption.

The view that database encryption comes with burdensome costs, added IT complexity and degraded performance is outdated. With today’s solutions, database encryption can be among the easiest, most affordable, and most effective security steps you can take. Multiple database encryption approaches are available, so choosing the right one for your needs is essential.

How does database encryption work?

When you encrypt all or part of a database, an encryption algorithm (there are many) converts the data from human-readable characters to ciphertext, which completely obscures the content and renders it useless to attackers. To decrypt the data and use it, you need the correct key, which the encryption solution generates.

Unlike many other security controls, like firewalls or anti-malware tools, most database encryption operates directly on the data where it is stored, often termed “data at rest.” At-rest encryption keeps your data secure if your network or database server is compromised, or if a malicious insider or cybercriminal with privileged access attempts to exfiltrate your data. Only users who have the right key can make use of the encrypted data.

What types of encryption are available?

To balance your users’ needs for access and performance with the value of your data and the risks it faces, you can choose from a range of database encryption options. These include:

  • Full database encryption, where all the data in the database is encrypted.
  • Column-/field-/table-level database encryption, where the most sensitive data elements are encrypted but others are not. This option can improve application performance and reduce system overhead by impacting only queries against encrypted data.
  • Client-side encryption encrypts the data on a user’s system before it is stored in the database. This approach puts the computational overhead of encryption on the client system, which often has cycles to spare. A further advantage is that data encrypted in this way is safe even from malicious code running on the server or within the RDBMS environment.
  • Homomorphic encryption uses complex mathematical computations to analyze encrypted data in various ways without decrypting it. This approach preserves privacy for sensitive data like health or educational records. It allows cloud service providers (CSPs), remote database administrators (DBAs), and other third parties to process data while maintaining regulatory compliance and full security. 
  • Hardware encryption, where the encryption mechanism is built into the hardware (e.g., a disk drive) where the database resides. The primary benefit of hardware encryption is that if the database environment or server is compromised, the data will remain inaccessible to attackers. 

How does Oracle handle encryption?

Oracle has long supported a feature called Transparent Database Encryption (TDE), which is both effective and straightforward to implement. TDE lets you encrypt the whole database, or only specific tables or columns. 

Oracle stores the database encryption keys in a separate Oracle Key Vault, which helps you govern your keys so that they’re secure from unauthorized access and available automatically (“transparently”) for authorized users and systems. This makes TDE a great option where you need to protect data from attacks that compromise your database servers and/or Oracle RDBMS, or where hackers gain access to the physical storage media.

How does Microsoft SQL Server handle encryption?

Like Oracle, Microsoft SQL Server also has the capability to encrypt data at rest, which it calls Transparent Data Encryption (TDE). SQL Server’s TDE offers many of the same data encryption capabilities as Oracle’s TDE. But its default key storage is different. Instead of a separate vault, SQL Server stores the database encryption key (DEK) in the database boot record for availability during recovery.

SQL Server also offers the Always Encrypted feature, which lets you encrypt highly sensitive data inside client applications and never reveal the encryption keys to the database engine. Because it segregates those who own the data from those who can view it or need to manage it Always Encrypted is ideal for maintaining security and compliance for high-value data in cloud environments, for instance.

How do open-source databases handle database encryption?

MySQL, PostgreSQL and most other popular open-source databases support third-party encryption libraries, such as pgcrypto or MyDiamo. There are also open-source toolkits for specialized types of database encryption like homomorphic encryption.

Database operations can also call on encryption functions available at the file system level in Windows, Linux, MacOS, etc. With this type of encryption, the server encrypts entire files as they are stored, potentially adding to system overhead but saving the cost of a separate solution.

Important considerations with managing encryption keys

Your encrypted data is only as secure as your encryption keys. Since they control access to encrypted data, you should store your keys separately from the database when possible. For example, both Microsoft Azure and IBM Cloud offer a “key vault” service that stores encryption keys in a hardware module for an extra level of encryption.

Your key management also needs to factor in backups, because backing up encrypted data without protecting the associated keys could be futile. One option is to consolidate your database encryption keys into a centralized key manager solution, and back them up from there.

Another consideration with encryption keys is their length. Different encryption methods rely on different key types. Longer keys, like longer passwords, are generally more secure. For example, 128-bit encryption schemes use a 128-bit key, which are deemed virtually impossible to break using today’s (non Quantum) computer systems.

The downside of longer keys—and potentially encryption overall—is higher overhead and reduced data throughput, as well as increased storage needs for the database. However, applying best practices in your implementation can reduce or eliminate many undesirable impacts.

Next steps

In response to customer demands and/or emerging security and privacy compliance requirements, more businesses are encrypting more databases in more ways than ever before. But the more data you encrypt, the more encryption keys you need to manage and the more you need to be concerned with performance impacts.

For optimal benefit to your organization, your database encryption strategy should reflect a holistic view of present and projected business needs, including cybersecurity and compliance risks, plus expert knowledge of best practices and technology options. A security risk assessment to identify weak spots is a great place to start.

If you are considering database encryption or want to optimize your current encryption approach, Buda Consulting can help you secure your business-critical data, comply with regulations and address database performance and cost issues.

Contact us to connect with an expert about a security risk assessment and related services.