Negotiating Oracle year-end deals

Difference between Oracle’s Exadata and Exalogic

Oracle Exadata (Oracle Exadata Database Machine) is strictly a data processing solution offered by Oracle. Initially conceived and promoted as a solution for mainly large data warehouse data load processing, Oracle now boldly proclaims that Exadata is suitable for high concurrency OLTP applications as well. It’s important to understand that Exadata isn’t something you use in addition to your current Oracle databases – rather, it comes with its own prepackaged Linux based Oracle database. Exadata is a prepackaged box that consists of the Oracle Exadata Storage Server software , Oracle Database 11g software, in addition to Sun branded hardware (RAM and CPUs) and Infiniband network technology software. Oracle’s claims of ultra fast data processing with Exadata are well supported by actual field experience of several companies, making this a really big success for Oracle Corporation. In addition to enabling fast processing of heavy amounts of data, Exadata also helps you consolidate multiple Oracle databases into a single easily manageable system. It’s important to note that the Exadata package (servers, software, network and storage) is completely preoptimized and preconfigured by Oracle.

If you’re running high volume, mission critical OLTP applications, or if you are having problems making sure that your current Oracle databases can crunch through heavy loads of warehouse data, it’s time to take a close look at Exadata – it’s more than likely that you’ll be surprised at the ease with which you can transition to Exadata from your current Oracle database based applications. Oracle claims that you’ll need fewer CPUs to run Exadata as compared to a non-Exadata solution. Exadata is configured in a balanced format, in units of “Racks” that are similar to standard data center rack configurations – you can purchase a quarter, half or a full rack and you can easily upgrade to more processing power by ordering additional Exadata racks.

Oracle Exalogic (Oracle Exadata Elastic Cloud) is also an “engineered system” and is similar to Exadata in the sense that it’s also a prepackaged hardware plus software solution, designed to be managed and monitored as a single stack. However, the main purpose of Exalogic isn’t data crunching – it’s an engineered system designed to provide high performance for Oracle middleware using custom Java EE applications, Oracle Applications and similar enterprise level applications.

Both Exadata and Exalogic are part of Oracle’s new paradigm of “purpose built systems” that provide pretested and preconfigured standardized sets of hardware, smart storage, and network and software components. The key goals are easy implementation, high speed processing and easy scalability on demand. The fundamental idea behind Oracle’s engineered systems – that standardizing and optimizing al the components will provide a higher performance through the exploitation of the synergies among the various components seems to be borne by the experience of users..

Does Oracle audit specific products and different operating systems?

Does Oracle audit specific products and different operating systems?

Security Alert for CVE-2012-1675 Released

Hi, this is Eric Maurice.

Oracle just released Security Alert CVE-2012-1675 to address the “TNS Listener Poison Attack” in the Oracle Database.  With a CVSS Base Score of 7.5, this vulnerability is remotely exploitable without authentication, and if successfully exploited, can result in a full compromise of the targeted Database.

In the April 2012 Critical Patch Update, Oracle provided Security-in-Depth recognition to Joxean Koret.  As stated in the Critical Patch Update advisories, “People are recognized for Security-In-Depth contributions if they provide information, observations or suggestions pertaining to security vulnerability issues that result in significant modification of Oracle code or documentation in future releases, but are not of such a critical nature that they are distributed in Critical Patch Updates.”

As stated in previous blog entries, Oracle fixes vulnerability first in the main code line, and then tries to backport fixes through the Critical Patch Update program for exploitable vulnerabilities that were externally reported.  In certain instances, such backporting is very difficult or impossible because of the amount of code change required, or because the fix would create significant regressions, or because there is no reasonable way to automate the application of the fix (for example when user interaction is required to change configuration parameters). 

Shortly after the release of the Critical Patch Update, mistakenly assuming that the issue had been backported through the CPU, Joxean Koret, the initial reporter of this vulnerability, fully disclosed its details, initially stating that it had been fixed by Oracle, then after realizing that it had not been fixed in current releases, reported the vulnerability as a “0-day.”  

As a result of this disclosure, Oracle has issued Security Alert CVE-2012-1675 to provide customers with a number of technical measures to provide effective defense against this vulnerability in all deployment scenarios.

Customers on single-node configurations (i.e., non Real Application Cluster (RAC) customers) should refer to the My Oracle Support Note titled “Using Class of Secure Transport (COST) to Restrict Instance Registration” (Doc ID 1453883.1) to limit registration to the local node and the IPC protocol through the COST (Class Of Secure Transport) feature in the listener.

RAC and Exadata customers should refer to the My Oracle Support Note “Using Class of Secure Transport (COST) to Restrict Instance Registration in Oracle RAC” (Doc ID 1340831.1) to implement similar COST restrictions. 

Note that implementing COST restrictions in RAC environments require the use of SSL/TLS encryption.  Such network encryption features were previously only available to customers who were licensed for Oracle Advanced Security.  However, RAC customers who were previously not licensed for Oracle Advanced Security need not be concerned about a licensing restriction as Oracle has updated its licensing to allow these customers the use of these features (namely SSL and TLS) to protect themselves against vulnerability CVE-2012-1675.  In other words, Oracle has added Oracle Advanced Security SSL/TLS to the Enterprise Edition Real Application Clusters (Oracle RAC) and RAC One Node options, and added Oracle Advanced Security SSL/TLS to the Oracle Database Standard Edition license when used with the Real Application Clusters.

Considering that the technical details of vulnerability CVE-2012-1675 have now widely been distributed, Oracle highly recommends that customers make the configuration changes documented in the above mentioned My Oracle Support Notes as soon as possible.  Customers should also feel free to contact Oracle Support if they have questions or concerns.

For More Information:

• The Advisory for Security Alert CVE-2012-1675 is located at http://www.oracle.com/technetwork/topics/security/alert-cve-2012-1675-1608180.html
• The My Oracle Support Note titled “Using Class of Secure Transport (COST) to Restrict Instance Registration” (Doc ID 1453883.1) is located at http://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1453883.1
• The My Oracle Support Note titled “Using Class of Secure Transport (COST) to Restrict Instance Registration with SCAN listeners” (Doc ID 1340831.1) is located at  http://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1340831.1 
• Oracle’s security fixing policies are published on the Oracle Software Security Assurance web site located at http://www.oracle.com/us/support/assurance/index.html  

April 2012 Critical Patch Update Released

Hi, this is Eric Maurice.

Oracle has just released the April 2012 Critical Patch Update. This Critical Patch Update provides 88 new security fixes across the following product families: Oracle Database Server, Oracle Fusion Middleware, Oracle Enterprise Manager Grid Control, Oracle E-Business Suite, Oracle Supply Chain Products Suite, Oracle PeopleSoft Enterprise, Oracle FLEXCUBE, Oracle Siebel Clinical Trial Management System, Oracle Primavera, Oracle Sun products suite, and Oracle MySQL.

Of the 88 new vulnerabilities, 6 directly affect Oracle Database Server. The highest CVSS Base Score for these Database Server vulnerabilities is 9.0. This Base Score affects the Oracle Spatial component on Windows platforms (on non-Windows platforms, i.e., Linux, Unix, the CVSS Base Score is 6.5). In addition, 6 Enterprise Manager Grid Control fixes may be relevant to Database Server deployments. The highest CVSS Base Score for the Enterprise Manager Grid Control vulnerabilities is 5.8; but 4 of the 6 vulnerabilities can be remotely exploitable without authentication. Therefore, Oracle highly recommends that these fixes be applied as soon as possible.

This Critical patch Update also includes 11 new security fixes for Oracle Fusion Middleware. The highest CVSS Base Score for these Fusion Middleware vulnerabilities is 10.0 (for vulnerability CVE-2012-1695). This score affects a series of vulnerabilities in the Java Runtime Environment that are applicable to JRockit. Starting again with this Critical Patch Update, JRockit fixes will no longer be provided with the Critical Patch Update for Java SE, but be provided in “the normal” Critical Patch Update along with other Oracle Fusion Middleware fixes.

This Critical Patch Update provides the following application security fixes: 4 for Oracle E-Business Suite, 5 for Oracle Supply Chain Products Suite, 15 for Oracle PeopleSoft Enterprise, 2 for Siebel Clinical Trial Management System, 17 for Oracle FLEXCUBE, and 1 for Oracle Primavera Enterprise Project Management.

Finally, this Critical Patch Update provides 15 new security fixes for the Oracle Sun Products Suite (including Oracle Grid Engine, Oracle Glassfish Enterprise Server, Oracle Solaris, etc.) and 6 new security fixes for Oracle MySQL.

While a great amount of caution is required when analyzing the content of the Critical Patch Updates in an attempt to identify potential trends; I believe the content of this Critical Patch Update is consistent with the views expressed in previous blog entries: Oracle Software Security Assurance activities tend to result in lowering the number of exploitable security bugs in most mature product lines (that is the product lines who have implemented Oracle secure development practices for the longest time), and as a result we see a downward trend in the number of fixes for these product lines. On the other hand, newly acquired product lines often experience relatively large number of security fixes in the Critical Patch Updates. This is due in part to the increased visibility these products may get as a result of their acquisition by Oracle, as well as development’s access to an extended toolset (e.g., security scanning tools) and increased executive attention around security matters as a result of joining Oracle.

For More Information:

The April 2012 Critical Patch Update Advisory is located at http://www.oracle.com/technetwork/topics/security/cpuapr2012-366314.html

More information about Oracle Software Security Assurance is located at http://www.oracle.com/us/support/assurance/index.html

New DVD Training – Learning Oracle 11g

From An Expert’s Guide to Oracle Technology

What a nice birthday present. My new video training, Learn Oracle 11g, was released yesterday. 

This training is an introduction, kind of like a concepts guide. I take a viewer on a walk-through

What’s up with Oracle and Sun?

I don't know why this made me laugh. I think it might be the yoda-like way the warning is written (Oracle or Oracle Not, There is no Sun). Or maybe it's the incredulty of the message. Or the seriousness of the buttons (Proceed anyway, return to safety!). Or even the plea to Help me understand!

This is the first time I've seen this kind of error though. Is this a Chrome thing? A phishing preventative? I mean from a protocol perspective, wouldn't this just be an http redi

Security Alert for CVE-2011-5035 Updated

Hi, this is Eric Maurice again. 

Oracle has just updated the Security Alert for CVE-2011-5035 to announce the availability of additional fixes for products that were affected by this vulnerability through their use of the WebLogic Server and Oracle Container for J2EE components.  As explained in a previous blog entry, a number of programming language implementations and web servers were found vulnerable to hash table collision attacks.  This vulnerability is typically remotely exploitable without authentication, i.e., it may be exploited over a network without the need for a username and password.  If successfully exploited, malicious attackers can use this vulnerability to create denial of service conditions against the targeted system.

A complete list of affected products and their versions, as well as instructions on how to obtain the fixes, are listed on the Security Alert Advisory.  Oracle highly recommends that customers apply these fixes as soon as possible.

Getting Groovy!

From An Expert’s Guide to Oracle Technology

I've been teaching myself Groovy for the last few weeks. I was learning Lua but ran into some issues with creating interfaces and stand-alone apps, so I decided to look for another language that is as productive as Lua but that can also create GUI apps. I considered going back to Ruby (I did that a few years ago), but I had hit limitations there

Pain Comes Instantly

When I look back at recent blog entries – many of which are not all that current (more on where my available writing time is going later) – I am struck by how many of them focus on public policy or legislative issues instead of, say, the latest nefarious cyberattack or exploit (or everyone’s favorite new pastime: coining terms for the Coming Cyberpocalypse: “digital Pearl Harbor” is so 1941). Speaking of which, I personally hope evil hackers from Malefactoria will someday hack into my bathroom scale – which in a future time will be connected to the Internet because, gosh, wouldn’t it be great to have absolutely everything in your life Internet-enabled? – and recalibrate it so I’m 10 pounds thinner. The horror.

In part, my focus on public policy is due to an admitted limitation of my skill set. I enjoy reading technical articles about exploits and cybersecurity trends, but writing a blog entry on those topics would take more research than I have time for and, quite honestly, doesn’t play to my strengths. The first rule of writing is “write what you know.”

The bigger contributing factor to my recent paucity of blog entries is that more and more of my waking hours are spent engaging in “thrust and parry” activity involving emerging regulations of some sort or other. I’ve opined in earlier blogs about what constitutes good and reasonable public policy so nobody can accuse me of being reflexively anti-regulation. That said, you have so many cycles in the day, and most of us would rather spend it slaying actual dragons than participating in focus groups on whether dragons are really a problem, whether lassoing them (with organic, sustainable and recyclable lassos) is preferable to slaying them – after all, dragons are people, too - and whether we need lasso compliance auditors to make sure lassos are being used correctly and humanely. (A point that seems to evade many rule makers: slaying dragons actually accomplishes something, whereas talking about “approved dragon slaying procedures and requirements” wastes the time of those who are competent to dispatch actual dragons and who were doing so very well without the input of “dragon-slaying theorists.”)

Unfortunately for so many of us who would just get on with doing our day jobs, cybersecurity is rapidly devolving into the “focus groups on dragon dispatching” realm, which actual dragons slayers have little choice but to participate in.

The general trend in cybersecurity is that powers-that-be – which encompasses groups other than just legislators – are often increasingly concerned and therefore feel they need to Do Something About Cybersecurity. Many seem to believe that if only we had the right amount of regulation and oversight, there would be no data breaches: a breach simply must mean Someone Is At Fault and Needs Supervision. (Leaving aside the fact that we have lots of home invasions despite a) guard dogs b) liberal carry permits c) alarm systems d) etc.) Also note that many well-managed and security-aware organizations, like the US Department of Defense, still get hacked.

More specifically, many powers-that-be feel they must direct industry in a multiplicity of ways, up to and including how we actually build and deploy information technology systems. The more prescriptive the requirement, the more regulators or overseers a) can be seen to be doing something b) feel as if they are doing something regardless of whether they are actually doing something useful or cost effective. Note: an unfortunate concomitant of Doing Something is that often the cure is worse than the ailment. That is, doing what overseers want creates unfortunate byproducts that they either didn’t foresee or worse, don’t care about. After all, the logic goes, we Did Something.

Prescriptive practice in the IT industry is problematic for a number of reasons. For a start, prescriptive guidance is really only appropriate if:

• It is cost effective
• It is “current” (meaning, the guidance doesn’t require the use of the technical equivalent of buggy whips long after horse-drawn transportation has become passé)*
• It is practical (that is, pragmatic, proven and effective in the real world, not theoretical and unproven)
• It solves the right problem

With the above in mind, heading up the list of “you must be joking” regulations are recent disturbing developments in the Payment Card Industry (PCI) world. I’d like to give PCI kahunas the benefit of the doubt about their intentions, except that efforts by Oracle among others to make them aware of “unfortunate side effects of your requirements” – which is as tactful I can be for reasons that I believe will become obvious below - have gone, to-date, unanswered and more importantly, unchanged.

A little background on PCI before I get too wound up. In 2008, the Payment Card Industry (PCI) Security Standards Council (SSC) introduced the Payment Application Data Security Standard (PA-DSS). That standard requires vendors of payment applications to ensure that their products implement specific requirements and undergo security assessment procedures. In order to have an application listed as a Validated Payment Application (VPA) and available for use by merchants, software vendors are required to execute the PCI Payment Application Vendor Release Agreement (VRA). (Are you still with me through all the acronyms?)

Beginning in August 2010, the VRA imposed new obligations on vendors that are extraordinary and extraordinarily bad, short-sighted and unworkable. Specifically, PCI requires vendors to disclose (dare we say “tell all?”) to PCI any known security vulnerabilities and associated security breaches involving VPAs. ASAP. Think about the impact of that. PCI is asking a vendor to disclose to them:

• Specific details of security vulnerabilities

• Whether or not there is any mitigation available (as in a patch)

PCI, in turn, has the right to blab about any and all of the above – specifically, to distribute all the gory details of what is disclosed - to the PCI SSC, qualified security assessors (QSAs), and any affiliate or agent or adviser of those entities, who are in turn permitted to share it with their respective affiliates, agents, employees, contractors, merchants, processors, service providers and other business partners. This assorted crew can’t be more than, oh, hundreds of thousands of entities. Does anybody believe that several hundred thousand people can keep a secret? Or that several hundred thousand people are all equally trustworthy? Or that not one of the people getting all that information would blab vulnerability details to a bad guy, even by accident? Or be a bad guy who uses the information to break into systems? (Wait, was that the Easter Bunny that just hopped by? Bringing world peace, no doubt.) Sarcasm aside, common sense tells us that telling lots of people a secret is guaranteed to “unsecret” the secret.

Notably, being provided details of a vulnerability (without a patch) is of little or no use to companies running the affected application. Few users have the technological sophistication to create a workaround, and even if they do, most workarounds break some other functionality in the application or surrounding environment. Also, given the differences among corporate implementations of any application, it is highly unlikely that a single workaround is going to work for all corporate users. So until a patch is developed by the vendor, users remain at risk of exploit: even more so if the details of vulnerability have been widely shared. Sharing that information widely before a patch is available therefore does not help users, and instead helps only those wanting to exploit known security bugs. There’s a shocker for you.

Furthermore, we already know that insider information about security vulnerabilities inevitably leaks, which is why most vendors closely hold such information and limit dissemination until a patch is available (and frequently limit dissemination of technical details even with the release of a patch). That’s the industry norm, not that PCI seems to realize or acknowledge that. Why would anybody release a bunch of highly technical exploit information to a cast of thousands, whose only “vetting” is that they are members of a PCI consortium?

Oracle has had personal experience with this problem, which is one reason why information on security vulnerabilities at Oracle is “need to know” (we use our own row level access control to limit access to security bugs in our bug database, and thus less than 1% of development has access to this information), and we don’t provide some customers with more information than others or with vulnerability information and/or patches earlier than others. Failure to remember “insider information always leaks” creates problems in the general case, and has created problems for us specifically.

A number of years ago, one of the UK intelligence agencies had information about a non-public security vulnerability in an Oracle product that they circulated among other UK and Commonwealth defense and intelligence entities. Nobody, it should be pointed out, bothered to report the problem to Oracle, even though only Oracle could produce a patch. The vulnerability was finally reported to Oracle by (drum roll) a US-based commercial company, to whom the information had leaked. (Note: every time I tell this story, the MI-whatever agency that created the problem gets a bit shirty with us. I know they meant well and have improved their vulnerability handling/sharing processes but, dudes, next time you find an Oracle vulnerability, try reporting it to us first before blabbing to lots of people who can’t actually fix the problem. Thank you!)

Getting back to PCI: clearly, these new disclosure obligations increase the risk of exploitation of a vulnerability in a VPA and thus, of misappropriation of payment card data and customer information that a VPA processes, stores or transmits. It stands to reason that VRA’s current requirement for the widespread distribution of security vulnerability exploit details -- at any time, but particularly before a vendor can issue a patch or a workaround -- is very poor public policy. It effectively publicizes information of great value to potential attackers while not providing compensating benefits - actually, any benefits - to payment card merchants or consumers. In fact, it magnifies the risk to payment card merchants and consumers. The risk is most prominent in the time before a patch has been released, since customers often have little option but to continue using an application or system despite the risks. However, the risk is not limited to the time before a patch is issued: customers often need days, or weeks, to apply patches to systems, based upon the complexity of the issue and dependence on surrounding programs. Rather than decreasing the available window of exploit, this requirement increases the available window of exploit, both as to time available to exploit a vulnerability and the ease with which it can be exploited. Also, why would hackers focus on finding new vulnerabilities to exploit if they can get “EZHack” handed to them in such a manner: a) a vulnerability b) in a payment application c) with exploit code: the “Hacking Trifecta!“ It’s fair to say that this is probably the exact opposite of what PCI – or any of us – would want.

Established industry practice concerning vulnerability handling avoids the risks created by the VRA’s vulnerability disclosure requirements. Specifically, the norm is not to release information about a security bug until the associated patch (or a pretty darn good workaround) has been issued. Once a patch is available, the notice to the user community is a high-level communication discussing the product at issue, the level of risk associated with the vulnerability, and how to apply the patch. The notices do not include either the specific customers affected by the vulnerability or forensic reports with maps of the exploit (both of which are required by the current VRA). In this way, customers have the tools they need to prioritize patching and to help prevent an attack, and the information released does not increase the risk of exploit.

Furthermore, many vendors already use industry standards for vulnerability description: Common Vulnerability Enumeration (CVE) and Common Vulnerability Scoring System (CVSS). CVE helps ensure that customers know which particular issues a patch addresses and CVSS helps customers determine how severe a vulnerability is on a relative scale. Industry already provides the tools customers need to know what the patch contains and how bad the problem is that the patch remediates.

So, what’s a poor vendor to do? Oracle is reaching out to other vendors subject to PCI and attempting to enlist then in a broad effort to engage PCI in rethinking (that is, eradicating) these requirements. I would therefore urge all who care about this issue, but especially those in the vendor community whose applications are subject to PCI and who may not have know they were being asked to tell-all to PCI and put their customers at risk, to do one of the following:

• Contact PCI with your concerns
• Contact Oracle (we are looking for vendors to sign our statement of concern)
• And make sure you tell your customers that you have to rat them out to PCI if there is a breach involving the payment application

I like to be charitable and say “PCI meant well” but in as important a public policy issue as what you disclose about vulnerabilities, to whom and when, meaning well isn’t enough. We need to do well. PCI, as regards this particular issue, has not done well, and has compounded the error by thus far being nonresponsive to those of us who have labored mightily to try to explain why they might want to rethink telling the entire planet about security problems with no solutions.

By Way of Explanation…

Non-related to PCI whatsoever, and the explanation for why I have not been blogging a lot recently, I have been working on Other Writing Venues with my sister Diane (who has also worked in the tech sector, inflicting upgrades on unsuspecting and largely ungrateful end users). I am pleased to note that we have recently (self-)published the first in the Miss Information Technology Murder Mystery series, Outsourcing Murder. The genre might best be described as “chick lit meets geek scene.”

Our sisterly nom de plume is Maddi Davidson and (shameless plug follows): you can order the paper version of the book on Amazon, or the Kindle or Nook versions on www.amazon.com or www.bn.com, respectively. From our book jacket:

Emma Jones, a 20-something IT consultant, is working on an outsourcing project at Tahiti Tacos, a restaurant chain offering Polynexican cuisine: refried poi, anyone? Emma despises her boss Padmanabh, a brilliant but arrogant partner in GD Consulting. When Emma discovers His-Royal-Padness’s body (verdict: death by cricket bat), she becomes a suspect.With her overprotective family and her best friend Stacey providing endless support and advice, Emma stumbles her way through an investigation of Padmanabh’s murder, bolstered by fusion food feeding frenzies, endless cups of frou-frou coffee and serious surfing sessions. While Stacey knows a PI who owes her a favor, landlady Magda urges Emma to tart up her underwear drawer before the next cute cop with a search warrant arrives. Emma’s mother offers to fix her up with a PhD student at Berkeley and showers her with self-defense gizmos while her old lover Keoni beckons from Hawai’i. And everyone, even Shaun the barista, knows a good lawyer.

Book 2, Denial of Service, is coming out this summer.

* Given the rate of change in technology, today’s “thou shalts” are easily next year’s “buggy whip guidance.”

Happy Anniversary To Me

From An Expert’s Guide to Oracle Technology

What? An anniversary? Yep, I have been blogging at it toolbox for 7 years now. Wow! Seriously - 7 years. It snuck up on me.

I remember when I would get up at 4 in the morning (5 days a week) to write my blog entries. It would take me a couple of hours each morning to write a single entry. Some entries took a week or more to write. I ha

Hit the Oracle Packtpot!

From An Expert’s Guide to Oracle Technology

I've reviewed quite a few books from Packt over the years. They are having a special in the leadup to IOUG. It's called