If you’re in the IT or financial business, chances are that you hear the acronym GRC being bandied about all the time. GRC (Governance, Risk and Compliance) is still a somewhat amorphous concept and there’s no unanimity among folks as to what exactly GRC is.

You can, however, go past the jargon filled world of GRC to the essence of the concept. Governance simply refers to management control of the entire process, including the effective carrying out of risk related management strategies by the organization. The risk in GRC refers to several types of risk, including financial risk, technological risk and security risk, legal risk as well as the risk of running afoul of compliance regulations. As you can surmise, all the various types of risk are interlinked – database security risks will eventually lead to financial exposure and vulnerability, of course. However, most folks consider compliance related risks as the main focus in GRC implementation efforts. The compliance angle in GRC, of course, refers to conforming to applicable regulations such as Sarbanes-Oxley and PCI DSS. Compliance covers the whole gamut from the identification of the requirements that apply to you, estimating your current compliance status and the adoption of strategies to ensure quick (and cost effective) compliance with the regulations to avoid fines and legal exposure.

Regardless of one’s conception of what exactly GRC is, we can all agree on the following simple goal based definition of GRC: a set of policies and tools that ensure that you minimize risk by safeguarding customer and enterprise data, preventing fraudulent and unauthorized use of your systems, reducing your reporting time, creating solid audit trails – in other words, a proactive and prudent management of data and systems.

Most Oracle (as well as DB2, MySQL and MS SQL Server) DBA’s are aware of the existence of Oracle database and application security benchmarks, but tend to treat the benchmarks, which are a type of best practice lists, with somewhat of a benignly neglectful attitude. This attitude is attributable to the lack of time on behalf of the harried DBAs, who are tasked with numerous critical functions, including the ensuring of high performance and continuous availability of their systems.

Despite the demands on their time, all database administrators will be doing themselves and their organizations an immense service by checking out the recommended benchmarks by a recognized authority such as the Center of Internet Security (CIS). CIS is a nonprofit organization that provides 52 entirely free benchmarks for databases, operating systems, web servers and applications. For its members, CIS also offers its Benchmark Audit Tool, designed to test your compliance with the various benchmarks.

While there are several database security best practice lists out there, the following are what makes the CIS benchmarks remarkable: the best practices are not handed down in an authoritarian fashion– they’re the result of a consensus among numerous database security professionals. The benchmarks are downloaded in large numbers and many organizations use them as informal standards for database configuration. CIS benchmarks are also widely accepted in government, business, industry and academic circles. Most commercial database security and vulnerability scanners use the CIS benchmarks to assess the vulnerability of databases. You can acquire the various benchmarks by from the CIS website at www.cis.org.

The PCI-DSS (Payment Card Industry Data Security Standard) standards, the set of requirements for the enhancement of payment data security that all credit card processors must follow, is scheduled for a revision in October 2010 (the current version is 1.2 and the new one will most likely be named the 2.0 version). Although there won’t be any official announcement until October on the proposed changes to be made to PCI DSS requirements, presentations in various trade shows indicate that the changes will be evolutionary, not drastic.

PCI officials have indicated that while there won’t be any new major requirements, several existing requirements will be clarified. The main areas where the revised PCI-DSS standards may be modified include a better definition of the network segmentation requirement, which is the demarcation of credit card holder data from the rest of your system. While you’re of course, required to protect cardholder data now, there’s no requirement currently for you to search for data on all your systems, not just those where your process the credit card numbers. Apparently that’ll change come October – you’ll need to institute a formal data discovery mechanism as one of the key steps in complying with PCI-DSS. While data discovery was often paid lip service, most companies don’t have a formal data discovery system in place. For larger enterprises especially, automated security and vulnerability assessment tools become an almost necessary requirement, in order to perform a viable and valid data discovery exercise.

Merchants will have until the beginning of October 2011, a full year after the announcement of the changes, to fall in line with the additional/modified requirements, meaning that auditors must apply the current PCI-DSS 1.2 version requirements in their assessments until October 1011.

Oracle has just announced a brand new database security product, named Oracle Database Firewall. Oracle Database Firewall is the name for the database activity monitoring capability previously offered by Secerno, the British firm, which was recently acquired by Oracle. Oracle seems to be on solid ground when it claims that the new product provides zero day protection from security threats, because the tool works in real time by working not within the database itself, but by monitoring database activity at the network level. With Secerno’s acquisition and the consequent unveiling of the Database Firewall product, Oracle has put itself on equal or even better footing with IBM, which gained significant database activity monitoring (DAM) capabilities from its acquisition of Guardium in 2009.

The announcement of the Oracle Database Firewall feature enhances Oracle’s already substantial investments in strengthening security through its Fusion Middleware (Identity and Access Management) products. An interesting point to note is that the Oracle Database Firewall isn’t limited to securing data in just Oracle databases – it offers heterogeneous database support. So, if you have critical data in a Microsoft SQL Server database, the data firewall protects that data as well, all without any changes to your database or application configuration.

Oracle Database Firewall is an exciting new addition to Oracle’s already formidable suite of security related products and is one more example of how you could enhance data security by adopting Oracle’s “defense in depth” strategy. In this case, the data firewall surrounds your databases with a protective parameter. Oracle Database Firewall works by using signatures or patterns in the hundreds of thousands of SQL statements that constantly traverse the network on their way to the database. It uses sets of both positive (acceptable) and negative (unacceptable) security models to identify suspicious looking SQL statements. The data firewall accurately detects anomalies and prevents the database from executing any unauthorized SQL statements. The feature promises to successfully deny well known database attack strategies such as SQL Injection and privilege escalation. You can sleep better at night, knowing that the bad guys are going to stopped before they can even get to the database!

This is an age both of an unprecedented amount of data breaches as well as an age of audits and auditors that have taken a much more serious stand about financial data integrity, following debacles such as Enron.  Through internal development efforts and key acquisitions (such as Logical Apps), Oracle has put forth a comprehensive set of GRC tools, especially for companies that have deployed financial apps such as the Oracle E-Business Suite.

It’s a well known fact that the GRC market is still in an evolutionary phase, with several smaller companies (Paisley, for example) and industry behemoths such as Oracle actively seeking to establish a toehold in the as the yet  incompletely understood market.  As with most GRC solutions, implementing Oracle GRC solutions is going to be a major endeavor – however, you’ll have the satisfaction of knowing that you’re implementing what probably is the best solution out there today, especially if you’re an Oracle E-Business Suite user.

While there are a number of E-Business implementers, there seems to be a shortage of outfits that can provide a comprehensive Oracle GRC implementation service, apart from Oracle itself. The reason is simple:  implementing a comprehensive Oracle GRC solution requires vendors to be skilled on several fronts at once: they need to understand the Oracle E-Business architecture, the Oracle Database itself, the GRC technical side that’s based on the new Oracle 11g Fusion Middleware, and finally, the Oracle GRC products such as the Oracle Enterprise GRC Manager and the Oracle Enterprise GRC Controls.

When Oracle teamed with HP to introduce the first version of Exadata, the new product was positioned more as data warehouse appliance. In its second incarnation, Exadata (or rather, the Sun Oracle Database Machine – Exadata is really the storage component of the machine), Oracle has dramatically upped the ante – it’s now promoting  as a solution for OLTP (online transaction processing) as well.

For customers who are wondering if Exadata is for them, the way to decide is simple: if you have a large production database with tens of Terabytes of data, do consider Exadata – it probably will make a lot of sense, when you compare its cost with the improvement in performance, due to the Flash Cache feature and a brand new SQL processing strategy wherein most of the unnecessary data for a query is weeded out at the storage level.  If you have an OLTP database, you may want to consider Exadata  even if your database isn’t very large - Exadata supports extreme levels of transactions per second (TPS), even if you buy but a quarter rack, the smallest size in which Oracle sells Exadata.

Field reports have just started trickling in about production implementations and they indicate that the actual performance does match the promises.  The much wider data I/O  “pipes” made possible by Infiniband and the fact that you can continue to use all of Oracle’s industry leading database capabilities (partitioning, parallel processing etc) with Exadata mean only one thing: contenders such as Teradata and Netezza better watch out!

Miro had a great day at the Alzheimer’s Association’s Polo Classic 2010 event.

One of the most common risk gaps during the lifecycle of Oracle at the enterprise is a lack of alignment. Legacy systems or architectural systems may cost extra in support year after year, but a simple change to the architecture may reduce your support costs. To give you an example, if you have older servers with single core processors and you move to a multi-core environment, you can usually save significant money in your licensing and your annual support costs. Let’s assume a server that had four single-core processors on it licensed singularly, roughly $47,500 for a single CPU license that would be $190,000 ($47,500 X 4 processors). Add 3-years of annual support for another $125,400. So, roughly, your cost of ownership would be $315,400. If on the other hand, you had employed a multi-core environment and used Intel CPUs, there is a factor that is applied in the Oracle licensing which is one-half, so you only need to buy half the licenses for the total number of cores that you have. For the same number of cores, you would be paying exactly half as much. In a three year period, you would save roughly $157,700 which may very well justify going to a different architecture. 

Auto renewal on your maintenance and support agreements need to be closely monitored. It is better that you leave the auto-renewal alone, so that you are in a better position to renegotiate each year. It’s at this point that the lack of a central repository or tracking mechanism may become really obvious because without knowing throughout the year when the renewals are coming in, it becomes difficult to budget and it can get you into trouble. It’s important to note that within agreements of Oracle, support renewals may contain their own Terms and Conditions which may alter some of the Terms and Conditions that you fought so hard to negotiate within the original ordering document. It’s really important that you factor in these support renewals and the support costs during the procurement process and scrutinize those during the support renewals. You could end up thinking that this is just a purchasing exercise of support renewal year to year when you actually may be devaluing that big investment you made.