OraNA :: Oracle News Aggregator

You can read the 18+ blog postings covering all of the recent discussions about how dead or not-dead meta-directories really are.

Or, you can read Ian's post that summarizes this whole discussion and save those three hours to line-wait for your iPhone 3G.

As for his conclusions:

1. Use the right tool for the job - Sure. Hard to argue with that.

2. There's room for provisioning, meta-directory, virtual directories, and directories - Sure, all the tools are available, but if you look at most meta-directories, the trend is still to try to make them more like provisioning tools. Not sure why you wouldn't just pick a tool that's already where you want to be.

3. Go with a service oriented approach - Our strategy here is certainly to be more application centric vs. more system management vendors and I think that's shown well when it comes to tie-ins with SOA and serices in general.

4. Meta-directories aren't dead, they're evolving - I agree, but see them evolving more into provisioning tools than virtual directories. This is already happening. I like to think that meta-directories aren't dead in the same way Monty Python's black knight isn't dead, but the reality is that they're trying to get where we already are. :-)

Dan Norris just gave me a heads up on Twitter that Peter O'Brien from Oracle in Ireland posted a short "how-to" for running the OID Directory Manager client on a machine that doesn't have a full copy of OID (e.g. your laptop).

Get it here.

Some of the points that Matt Flynn raises in this post were addressed in Nishant's reply. However, I wanted to spend a little time on this part of his post:

... There has been a ground swell of apps that directly support Active Directory as the user store. So, maybe the next versions of the HR and LOB apps in the above scenario would attach directly to AD eliminating the need for any solution here. As prevalent as AD has become, that seems more likely than mass-consumption of virtual directory technologies. ...

What's more likely: 1. everyone standardizing on Active Directory, or 2. everyone not standardizing on Active Directory.

Requiring Active Directory means everyone needs to be using Active Directory for everything. Using a virtual directory places no such requirements on the customer or application. It actually REDUCES the need to have a single, unlikely, unified standard.

This is the case because virtual directories emulate what applications expect from many existing directories. This means it's less about writing to a "virtual directory" than writing to your favorite directory standard and having the virtual directory emulate that in a view.

Not going to argue that the LAN guys have a lot of Active Directory sitting out there. Some of it is very strategic, other times it's used only for workstation authentication (and often outsourced to the people managing desktop user populations).

But there's also a lot of portals using Sun. Lots of databases and applications (e.g. eBiz Suite) using OID. Many people are even using Novell. Plus, even the topologies being used for Active Directory in a company often aren't predicted well by people writing off-the-shelf enterprise applications.

Simply "move everything to Active Directory" rarely works except in the smallest of organizations that will rely entirely on a Microsoft stack (no Java, no other directories, no non-Microsoft compliant infrastructure). Basically Microsoft lock-in.

This isn't to say that Microsoft can't be your strategic enterprise directory, or even extranet directory. But expecting every application from every vendor (including your legacy applications written before Microsoft even had a directory) to suddenly not just support Active Directory, but YOUR DEPLOYMENT of Active Directory is pretty unlikely. And it's exceptionally unlikely that everyone in the world will do so at that precise time as well. :-)

Customer Example

A simple example from a customer a few years back:

- 100% Microsoft Active Directory
- 100% ADSI-enabled application

Unfortunately:
- Global replication with a nasty replication delay (30 minutes)

This meant that if a user (traders in this case) changed their password, it might not get to all of the domain controllers until 30 minutes later, meaning that the traders would be unable to login to their application.

Clearly this wasn't foreseen by the application developer as a possible issue. The real solution may have been to completely re-architect their Active Directory environment in a different way, but you rarely have that luxury in the middle of a fire-drill.

What did the customer do? They spent a few hours installing Oracle Virtual Directory, configuring it to know about their domain controllers, and basically said that when a password failed, try it on the master. The master only sees these requests in "exceptional" circumstances and the replication delay has no material impact on the user's experience.

This provided time to come up with a more strategic solution to the problem. Having ultimately solved the underlying problem, the customer went on to deploy the product for other purposes (better loadbalancing and failover, etc...).

Still picking my jaw up off the floor from this comment from Alex @ the ApacheDS project on Jeff Bohren's blog.

Seems Dave Kearns noticed it as well. :-)

So for those of you worried that Jeff and I might never agree on anything, you can put your worries to rest. Jeff's response is right on target...

Being that I'm responsible for both our OID and OVD product lines here at Oracle, I see first-hand that our customers are seeking very different things from directories vs. virtual directories.

With directories, it's all about data management. How can I scale and manage a repository that can store all of my identity information with the same kind of security that I get from my transactional data.

With virtual directories, it's much different. It's about lightweight integration, minimizing infrastructure changes, minimizing code changes, reducing project risks, and providing the flexibility that helps make both application deployments and identity management deployments successful.

It's not either-or, it's 100% complimentary.

Oh, and I'm wondering if Alex's comment means that I should be saying I'm sorry to my customers for solving their problems without ApacheDS's forthcoming "real" virtual directory. :-)

Hi, this is Eric Maurice again.

The greatest external factor influencing Oracle Software Security Assurance is the feedback we receive from customers. While members of Oracle’s Global Product Security team have daily interactions with customers, security researchers, or industry analysts, the most exhaustive channel for customer feedback is the Security Customer Advisory Council that is being managed by the Program Management Office of the Global Product Security organization.

The Security Customer Advisory Council (SCAC for short) is comprised of customers from around the world and representing various industries. Moreover, SCAC members are collectively using most if not all Oracle products. The SCAC meets at least once a year to discuss emerging security topics, Oracle’s security strategy, and Oracle Software Security Assurance programs, including the Critical Patch Update and related activities. For example, the recommendations of the SCAC have previously led Oracle to adopt the Common Vulnerability Scoring System (CVSS) as a standard way to rate the severity of the vulnerabilities fixed in the CPU and to issue pre-release CPU announcements (these are issued on the Critical Patch Updates and Security Alerts page the Thursday before the CPU due date).

Most recently, the Independent Oracle User Group (IOUG) joined the Security Customer Advisory Council. This initiative was launched by the Enterprise Best Practices SIG under the leadership of Michelle Malcher, the SIG president. As a component to this initiative, Oracle and IOUG also produced a number of security training webcasts. These webcasts are available online on the Enterprise Best Practices SIG Download Page. The two most recent webcasts were particularly popular! In March, Daniel Wong (Director of Engineering the Database Security group) presented the security enhancements in Oracle Database Server 11g. Last month, Jenny Tsai-Smith (Senior Director in Curriculum Development) and Mark Fallon (Director of Software Development) recorded a webcast on how to best prevent SQL Injection attacks.

In preparation for the next Security Customer Advisory Council (to be held in October), the Enterprise Best Practices SIG of IOUG posted a security survey to try to gather information about the current security practices of its members, particularly around the application of the Critical Patch Updates and Patch Sets and to gather recommendations from members about possible process improvements that Oracle could bring to further enhance Oracle Software Security Assurance activities. Michelle and I recorded a webcast that discuss the objectives of the survey. We went through two iterations of the survey, further fine-tuning it, to come up with a shorter, simpler survey, that drill down to areas that are most likely to yield feedback from Oracle users (the current survey is titled “OSSA Security Survey II” on the IOUG web site).

We would like to encourage all Oracle users to take this survey!!! (Remember to select “OSSA Security Survey II”). A Free Associate Membership to IOUG may be required to take the survey, but completing this form should take no more than five minutes. Completing the survey itself should take no more that ten minutes (unless you decide to take advantage of the free form question at the end of the survey by writing an extensive set of recommendations for Oracle).

Information about the Security Survey:
The survey is located at http://survey.ioug.org . (Please select “OSSA Survey II”.)
The webcast explaining the objectives of the survey is located at: http://www.ioug.org/networking/SIGs/SurveyPodcastrev.mp3

Information about Oracle Software Security Assurance:
For more information about the Security Customer Advisory Council, you can e-mail: securityCAC@ORACLE.COM

Information about IOUG:
IOUG web site is located at http://www.ioug.org.
For information about IOUG membership, see the IOUG membership page.
Recorded IOUG webcasts can be found at http://www.ioug.org/networking/SIGs/Archived_SIG_Webcasts.cfm

Back from vacation and finding a whole army of people writing about virtual directory while I'm gone.

Working backwards, I saw the following quote from Jeff Bohren in his entry about vendor independence in response to a few posts from our own Nishant Kaushik:

BTW, having written code that supports multiple LDAP vendors at four different companies and three different programming languages, it’s really not all that difficult. The real power in virtual-directories is the ability to consolidate data from disparate sources, not abstracting the vendor for a single directory.

Having written similar code, I'll agree that some of the basic differences are pretty easy to navigate (differences between attribute names, for example). However, others are much, much more difficult.

Some examples:

• Active Directory returns groups larger than 1000 members in ranges. Other directories don't. This requires significantly different logic.
  
• Authenticating to Active Directory without Kerberos doesn't (or didn't) trigger actual logins, meaning that doing simple binds wouldn't respect bad password counts, etc...
  
• Account lock, account controls, password policies, etc... are completely different between directories
  
• Setting passwords is very different between AD and other directories
  

Now add in issues with using basic LDAP to navigate multi-forest AD environments, mixed-vendor LDAP environments, access to databases and web services, etc... and the requirement that applications would need to hit each of these...

Now you have a picture of why virtual directories are so widely deployed (and they are, though I can't share our numbers here at Oracle).

It's one thing to navigate this complexity in one application with a person like Jeff that has strong LDAP knowledge, but a completely different thing to expect that all of your off-the-shelf and in-house applications will have all of this knowledge and execute every step properly across all of these different kinds of systems.

Virtual directories remove that complexity by putting it at a service level. Change directories? Change a setting. Change applications? Change a setting. Add a web service with real-time data from an external source (perhaps a social network or real-time HR)? Change a setting.

Contrast that with the extra code, application rewrites, infrastructure changes, etc... that need to happen without a virtual directory and you see why Virtual Directory is the right way to go in almost every case.

And we wouldn't be pushing standards, such as the Identity Governance Framework and CARML, which will improve Virtual Directory interoperability, if we weren't fully committed to our customers' desire for standards and minimal vendor lock-in.

During the upgrade to the new blogging system I got this question via the comment system:

"How should relationships be modeled in LDAP? How would you model roles and resources in order to form an entitlement in LDAP? How should OpenID, Live, CardSpace, etc be modeled in LDAP?"

I will answer each question separately:

Q1 - How should relationships be modeled in LDAP?

A1 - Most of the time relationships are modeled using Groups. You can do this either using static groups (e.g. groupOfUniqueNames) that requires members to be stored in the uniquemember attribute OR you can use dynamic groups. Dynamic groups use an LDAP query (specified as an LDAP URL) to determine membership. OVD provides a plug-in that can make dynamic groups look like static groups which makes dynamic groups easier to use by client applications

---

Q2 - How would you model roles and resources in order to form an entitlement in LDAP?

A2 - Currently roles are most often mapped as LDAP groups. That being said we are working to make it easier to allow customers to specify roles based on objects besides groups as part of our Identity Governance Framework implementation. Resources can be exposed as either groups or a custom object. Entitlement is a very broad area. Coarse grain entitlement can be done via groups (most common case). Oracle Entitlement Server (our XACML based fine grained authorization product) allows to do finer-grained entitlements.

---

Q3  - How should OpenID, Live, CardSpace, etc be modeled in LDAP?

A3 - There is no special requirements here because they are just different mechanisms of representing identity attributes. Your OpenID or CardSpace service needs to read data from either existing source or perhaps write into an enterprise source. LDAP is a natural system because it is widely deployed and understood. Benefit of OVD is that it can simplify the mapping of the attributes. And in the longer-term the IGF Attribute Services API will make it even simpler by providing mapping at the object level. For example  as a developer, you could write a ShopperCardSpace object that represents the attributes provided by a shopper via CardSpace. Then OVD (which will be our IGF Attribute Service provider) will support taking that object and letting the administrator map it to the proper sources. If the data has no current home and/or should not be permanently  stored - it's possible to put it into a transient storage system like Oracle TimesTen. That way the data is available to be used by applications within the enterprise without requiring the data to be constantly retrieved from CardSpace in particular if the application cannot interact with CardSpace (e.g. a legacy application that can only do LDAP, a back-end BPEL process reading via SOAP, SIP servlet starting a click-to-call application).

Hello, this is Eric Maurice again.  The purpose of this blog entry is to announce today?s availability of the April 2007 Critical Patch Update on all Windows 32 bit platforms.

Each Critical Patch Update (CPU) includes a number of fixes for security vulnerabilities that affect different versions of Oracle products across a number of platforms.  Technically, each Critical Patch Update consists of a number of sets of patches for each platform/version combination.  For example, the April 2007 Critical Patch Update provides sets of patches to fix 36 vulnerabilities affecting 7 main Oracle products (Oracle Database Server and Client, Oracle Application Server, Oracle Collaboration Suite, Oracle E-Business Suite, Oracle Enterprise Manager, and Oracle PeopleSoft Enterprise and JD Edwards EnterpriseOne Applications) across 20 different types of operating systems.

Patch quality is Oracle?s foremost priority, and as a result we thoroughly test each set of patches for all supported versions and platforms. And while we try to release all the sets of patches on the scheduled day of the Critical Patch Update, sometimes we have to delay publishing a small number of sets of patches affecting specific version/platform combinations until all testing issues have been resolved.

For example, MetaLink Note 42006.1.1 (Critical Patch Update Availability Information for Oracle Server and Middleware Products) documentation for the April 2007 Critical Patch Update states that the CPU includes a total of 93 planned sets of patches for Oracle Database Server.  While the vast majority of these sets of patches are already available, others will not be available for a few weeks. 

The original version of that MetaLink note stated that Windows 32-bit was not yet available for Database version 9.2.0.8.   At this time, however, the Critical Patch Update for the Windows 32-bit version of the 9.2.0.8 database has become available and the MetaLink note has been updated.

Oracle highly recommends that customers apply the most recent Critical Patch Update as soon as possible.  Furthermore, we also recommend that customers download and consult the most recent security documentations available from Oracle Technology Network or the Resource Library on the Oracle Software Security Assurance web site. 

Hi, this is Eric Maurice!

Important aspects of securing an environment include secure deployment and ongoing maintenance and monitoring of security events for the environment.   Security is a process, an ongoing effort that does not end after successfully deploying a new system or application.  Securing an environment requires a holistic approach where all layers of the IT environment have to be considered.  In the most simple scenario, for example, when an organization needs to secure a dedicated single server-based application, the organization needs - at the very minimum - to understand how to deploy the application, then secure it at the OS, database (if a database is being used) and network levels, while also providing for physically controlling access to the server.  Furthermore, securing an environment is not limited to the one-time effort of proper initial configuration because it is critical that the environment be monitored for anomalous security events on an ongoing basis.  Finally, the environment must be periodically assessed for deviation from its security baseline, as configuration changes can often alter the security state of a system.

In previous blog entries, I have often mentioned the Resource Library on the Oracle Software Security Assurance web site.   This is because we are aiming to promote relevant and up-to-date security content on this page, including tips, techniques, and technical white papers.  Among the resources available on the Resource Library are recommendations for locking down and maintaining the security posture of Oracle products in production environments.   These recommendations often extend to the non-Oracle components of a client?s IT infrastructure (for example, they include recommendations for securing file systems, OS authentication, etc.)  Much of this security content can also be accessed directly on the Security Technology Center on Oracle Technology Network and on MetaLink (subscription required). 

A few months back, we recorded a technical webcast titled ?Best Practices for Oracle Database Security?.   This webcast was quite successful, and we continue to see an audience for the webcast on a daily basis.  Its popularity has prompted us to record additional technical ?how to? webcasts.  Those webcasts are designed to provide quick introductions to the most important security recommendations for deploying and maintaining specific Oracle products.

Today, we are making available a technical webcast on how to secure Oracle E-Business Suite R11.  This webcast goes over the recommendations specifically stated in MetaLink Note 189367.1, including:
- Tips to harden the applications environment
- Specific configuration baselines for internal and external deployments
- Recommendations for monitoring certain events, including how to use the Oracle Applications Manager to log and monitor for relevant security events
- Recommendations for developing the proper process for the application of the Critical Patch Updates.
Implementing those recommendations will bring organizations a long way in term of preventing common attacks.

Note that in February, Oracle also produced a technical white paper, which follows the same structure as the previous technical E-Business security white papers, but introduces specific security recommendations for Oracle E-Business Suite R12.  This white paper is available as Metalink Note 403537.1. 

Hi, this is Eric Maurice again!

Today, Oracle released the July 2007 Critical Patch Update (CPUJul2007).  This Critical Patch Update (CPU) addresses a total of 45 vulnerabilities affecting Oracle Database Server, Oracle Application Server, Oracle Collaboration Suite, Oracle E-Business Suite, and Oracle PeopleSoft Enterprise.  Out of these 45 vulnerabilities, thirteen are ?remotely exploitable without authentication?.  This means that an attacker could exploit these vulnerabilities remotely without having to authenticate directly to the targeted system.  Seventeen out of these 45 vulnerabilities affect Oracle Database Server, and two of them are ?remotely exploitable without authentication.?  Finally, the highest CVSS ?base score? in this Critical Patch Update is 4.8, and it affects two vulnerabilities in Oracle PeopleSoft Enterprise.  The CVSS (Common Vulnerability Scoring System) score can provide users with an idea of the relative importance of the criticality of a given vulnerability in their environment.  For more information on Oracle?s application of CVSS, see MetaLink note 394487.1 (subscription to MetaLink required). As usual, we encourage our customers to apply Critical Patch Updates in a timely fashion in order to continue to maintain a proper security posture.

In a previous blog entry (April 2007 Critical Patch Update Released), I discussed Oracle?s three main guiding principles for the Critical Patch Update.  These principles are (1) maximum security, (2) predictability and (3) simplicity to provide a manageable cost of security ownership to our customers.  As a result of Oracle?s ongoing commitment to these principles, the company has introduced many enhancements to the Critical Patch Update process.  With this Critical Patch Update, Oracle introduces yet another such enhancement: the napply CPU (pronounced ?N Apply?).

The napply CPU is an enhanced CPU format for Oracle Database Server for Unix and Linux platforms version 10.2.0.3 and onward (including 10.2.0.4 and 11g).  In a napply CPU, the security fixes are now grouped in what are called molecules.  Each molecule in the CPU is independent, and does not conflict with other molecules in the CPU.  Conflicts between molecules occur when fixes included respectively in each molecule affect the same file or group of files. 

The napply CPU is for the benefit of customers who encounter merge conflicts when installing CPU patches.  While the majority of customers never encounter such conflicts, we expect the following benefits from the introduction of the napply CPU:

The new CPU format will greatly simplify the patch conflict resolution procedures, thus providing for a quicker resolution of security vulnerabilities than was previously the case.  At the time of the CPU application, customers faced with patch conflicts with the napply CPU will have the option to install the non-conflicting fixes (embedded in the non-conflicting molecules) and skip the fixes affected by conflicts.  This option is known as partial napply.  The benefit of this approach is that the affected environment gets immediate protection for those vulnerabilities that can be resolved with the non-conflicting fixes.  Note that Oracle will provide a mapping of security vulnerabilities for each CPU molecule, so that customers will be able to assess the criticality of the vulnerabilities left unresolved by the partial napply.  Oracle will also allow customers to open Service Requests to initiate the creation of napply Merge Patches that are specific to their environment immediately after the installation of a partial napply CPU, thus allowing for security patch conflicts to be resolved more quickly and efficiently.

By using the OPatch parameter ?-skip_duplicate?, customers will have the ability to skip the application of those molecules that have been previously installed (for example by a previous CPU) thus reducing the changes introduced to the patched system.  In other words, while the CPU remains cumulative, the CPU will install incrementally those new groups of fixes.  Note however, that in order for this enhancement to be effective, the classic CPUs that were previously installed will have to be rolled back and replaced by the new format; this is a one time event achieved by installing the July 2007 CPU.

MetaLink Note 438314.1 includes detailed information about napply.  The Critical Patch Updates and Security Alerts page on Oracle Technology Network provides detailed information about this CPU, as well as previous CPUs and Security Alerts.  The Resource Library on the Oracle Software Security Assurance web site also provides a number of links to useful security resources.

Hello, this is Eric Maurice again!

Oracle today released the October 2007 Critical Patch Update (CPUOct2007).  This Critical Patch Update (CPU) addresses a total of 51 vulnerabilities affecting Oracle Database Server, Oracle Application Server, Oracle Enterprise Manager, Oracle E-Business Suite, and Oracle PeopleSoft Enterprise.  Twenty-seven of these vulnerabilities affect various components of Oracle Database Server, including optional components such as Oracle Database Vault and Oracle Internet Directory.  None of the Oracle Database Server fixes require patching the database client-only installations.  This Critical Patch Update also includes fixes for eleven Oracle Application Server vulnerabilities, and none of these fixes are for client-only installations. 

This Critical Patch Update also marks the adoption of version 2.0 of the Common Vulnerability Scoring System (CVSS).  FIRST (Forum of Incident Response and Security Teams) published CVSS 2.0 on June 20, 2007, too late for its adoption by Oracle for the July 2007 CPU.  However, today?s transition to CVSS 2.0, and the early adoption of CVSS by Oracle a year ago, is an evidence of the dedication of Oracle to adopting customer-centric practices for vulnerability remediation and disclosure.  It is worthwhile to reiterate again that CVSS provides a standard-based approach for assessing the criticality of vulnerabilities.  In other words, CVSS assists customers to understand the significance of a given vulnerability in their environment, and assess the priority that should be given to patching that specific vulnerability against production requirements. 

The new version of the CVSS standard is designed to address the criticism that CVSS scores tended to be clustered around few score values.  With CVSS 2.0, a number of new distinctions are introduced that result in further spreading the typical range of the CVSS ?base score? and making the standard more representative of real world vulnerabilities.  For example, the ?access vector? in CVSS 1.0 had the distinction between ?local? and ?remote?.  With CVSS 2.0, ?access vector? can either be network (typically reported as ?remotely exploitable?, instances where ?the vulnerable software is bound to the network stack and the attacker does not require local network access or local access?), adjacent network (typically the attacker needs access to the same subnet as the targeted system, instances ?where the attacker needs to have access to either the broadcast or collision domain of the vulnerable software?), or local (the attacker has ?either physical access to the system or a local shell account?).  For more information, the Guide to the Common Vulnerability Scoring System version 2.0 is available online, and it includes the scoring formulas set forth by the standard.  In addition, the National Institute of Standards and Technology (NIST) maintains a CVSS version 2.0 scoring calculator online.

The enhancements to the CVSS standard make it nearly impossible to provide rules of thumb for deriving CVSS 1.0 from CVSS 2.0 scores.  So, in order to help customers transition to the new version of the standard, and to allow them to become more familiar with the new scoring scheme, Oracle has also published MetaLink note 458015.1 (subscription to MetaLink required) that lists the vulnerability Risk Matrices as if they were computed using the CVSS 1.0 scheme.  Note however that as a result of using CVSS 2.0 in the October CPU nearly all of the base score values are greater than under CVSS 1.0 (49 of 51 vulnerabilities).  Also, the average base score has increased from 2.5 using the CVSS 1.0 standard to 4.8 using the CVSS 2.0 Standard.

The Critical Patch Updates and Security Alerts page on Oracle Technology Network provides detailed information about this CPU, as well as previous CPUs and Security Alerts.  Oracle MetaLink Note 394487.1 (subscription to MetaLink required) explains Oracle's implementation of the CVSS standard.  The Resource Library on the Oracle Software Security Assurance web site also provides a number of links to useful security resources, including the technical white paper: Oracle OnDemand Best Practices for the Critical Patch Update.

Hi, this is Eric Maurice again!

Following the release of the October CPU (CPUOCT2007), it became clear that there was still a certain level of confusion and misunderstanding about CVSS and how it was implemented by Oracle.  Given this situation, I thought it might be helpful to further talk about CVSS, and specifically, the vulnerability scoring metholodgy implemented in the standard. 

The Common Vulnerability Scoring System (CVSS), initially announced in February 2005 on the U.S. Department of Homeland Security?s web site, is designed to ?provide open and universally standard severity ratings of software vulnerabilities?.  Oracle was one of the first software vendors to adopt CVSS to provide a standard-based indication of the severity of the vulnerabilities fixed in its products.  Oracle has provided CVSS Base Scores in the risk matrices of the CPU documentation since the October 2006 Critical Patch Update (CPUOct2006).  In June 2007, FIRST (Forum of Incident Response and Security Teams) published the second version of the standards: CVSS 2.0, which was implemented by Oracle with the October 2007 Critical Patch Update (CPUOct2007).  Note that in this discussion, we will address the new CVSS 2.0 Scoring System if not otherwise noted

Since Oracle implemented CVSS, we periodically receive questions about how the CVSS base metrics scores are calculated.  Specifically, some people find it surprising that vulnerabilities deemed to be particularly critical receive a CVSS base score between 6.5 and 7.5 out of an absolute scale of 10.0.  Understanding the CVSS scoring system requires going back to the objectives of CVSS, and understanding the formulas behind the scores themselves.  In the first part of this blog series, we will be discussing the objectives of CVSS and how it affected the scoring of vulnerabilities

The CVSS web site states that the objective of CVSS is to provide a severity rating for all software vulnerabilities. 

This means that CVSS is designed to provide a numeric value (the score) indicative of the relative criticality of a given vulnerability regardless of the type of software it affects, whether it is an Operating System, antivirus, database, mail server, desktop or business application, etc.  As a result of this wide scope of applicability, the standard is intentionally designed to require a complete compromise at the Operating System layer for a given vulnerability to be given a base score of 10.0.  In other words, a vulnerability with a CVSS Base Score of 10.0 typically signifies a complete compromise of the system, that typically results in allowing the attacker full control, including administrative or ?root? privileges at the OS layer.  An example of the impact of such a vulnerability in a third party product is reported on the National Vulnerability Database as ?The attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.? 

Due to the nature of the Oracle bugs, vulnerabilities that could result in a complete compromise of the underlying server are rather rare.  In fact, since the CVSS scoring was implemented by Oracle, the highest-ever CVSS Base Score assigned by Oracle to a vulnerability addressed in the CPU would have been 7.5 if it had been scored under the CVSS 1.0 scoring system.  Note however that CVSS deals with single vulnerabilities, and does not completely account for ?blended threats?, that is the combination of attack methods/vectors that could ultimately result in such a very extensive compromise.  It is therefore very important for organizations to patch all vulnerabilities as soon as possible, as leveraging various vulnerabilities across IT layers may result in a more complete compromise of the targeted system.

The CVSS system includes three types of score ? Base, Temporal and Environmental.  Each is designed to measure different attributes of the vulnerability.  Oracle provides the ?Base Score? in the CPU documentation.  It is characterized by the following aspects:

-         The Base Score is specific to a given vulnerability.

-         It does not change over time.  This is where the ?Temporal Metrics? come into play to measure, for example, additional exposure resulting from the availability of exploit code. 

-         It is not specific to a customer?s technical IT environment.  This is where the ?Environmental Metrics? come into play, to measure, for example, the likelihood of collateral damages to other systems and applications.

The CVSS documentation states that computing the Temporal and Environmental Metrics scores is optional.  While computing all three scores can provide a granular risk rating (specific to a given vulnerability in a specific environment at one point in time), most customers find this process to be too cumbersome, and they rely exclusively on the Base Score to assess the criticality of vulnerabilities and the priority given to patching them. 

Next week, we will be looking into more details on how the Base Score is computed using the ?Base Equation? of CVSS.

For more information, see:

-         Oracle MetaLink Note 394487.1 (subscription to MetaLink required) explains Oracle's implementation of the CVSS standard

-         Oracle MetaLink Note 394486.1 (subscription to MetaLink required) provides a detailed explanation of Oracle?s risk matrices

-         The Critical Patch Updates and Security Alerts page on Oracle Technology Network provides detailed information about previously released CPUs and Security Alerts

-         The Guide to the Common Vulnerability Scoring System version 2.0 is available online, and it includes the scoring formulas set forth by the standard.

Hi, this is Eric Maurice again! Last week, we discussed the objectives of CVSS and how it impacted the scoring philosophy of the standard.  Today, we are going to take a closer look at the formula vendors use to compute CVSS Base Scores.

The CVSS Base Score is computed from six criteria, known collectively as the ?Base Metrics?, representing ?the most fundamental, immutable qualities of a vulnerability?.  These criteria are:

1.      Access Vector.  This measures ?how remote an attacker can be to attack a target?.  The possible Access Vector values are Local, Adjacent Network, and Network;

2.      Access Complexity.  This measures ?the complexity of attack required to exploit the vulnerability once an attacker has gained access to the target system?.  The possible Access Complexity values are High, Medium and Low;

3.      Authentication.  This measures ?the number of times an attacker must authenticate to the target system in order to exploit the vulnerability?.  The possible Authentication values are Multiple, Single, and None;

4.      Confidentiality Impact.  This measures ?the impact on confidentiality of a successful exploit of the vulnerability on the target system?, that is to say, improper information disclosure.  The possible Confidentiality Impact values are None, Partial, and Complete;

5.      Integrity Impact. This measures ?the impact on integrity of a successful exploit of the vulnerability on the target system?, that is to say, data corruption.  The possible Integrity Impact values are None, Partial, and Complete;

6.      Availability Impact.  This measures ?the impact on availability of a successful exploit of the vulnerability on the target system?, that is to say, denial of service.  The possible Availability Impact values are None, Partial, and Complete.

A numerical value is assigned to each of the three possible answers for each of the six criteria.  Then a formula, known as the ?Base Equation?, is used to assign weight to each of the criteria, combine the weighted values, and derive the Base Score.  The application of the Base Equation formula yields in a maximum score of 7.5 for vulnerabilities typically found in Oracle products (it would be extraordinary if an Oracle security bug would result in a complete compromise of the underlying operating system).  Note that the National Vulnerability Database considers CVSS scores between 7.0 and 10.0 to be ?high?. 

The National Institute of Standards and Technology (NIST) hosts a CVSS 2.0 calculator online.  This neat utility provides the ability to compute the score without necessarily manually dealing with the Base, Temporal, or Environmental equations.  Let?s take one of the vulnerabilities addressed in the October 2007 CPU (CPUOct2007); the vulnerability DB01 had the following particularities:

-         Exploitability Metrics:

o       Related exploit range (AccessVector): Network

o       Attack complexity (AccessComplexity): Low

o       Level of authentication needed (Authentication): Single Instance

-         Impact Metrics:

o       Confidentiality impact (ConfImpact): Partial

o       Integrity impact (IntegImpact): Partial

o       Availability impact (AvailImpact): Partial

When entering these values, the calculator provides the score of 6.5 as reported in the CPU documentation.

Oracle quickly realized some limitations of the CVSS base scoring system.  One is that CVSS does not distinguish between, for example, the disclosure of only a single database record and the disclosure of all data in a database.  Oracle therefore introduced the ?Partial+? rating to denote such rare situations where the impact of the vulnerability can result in widespread impacts while partial means only limited impact.  Note that Oracle uses the Partial numeric value assigned by CVSS for both Partial and Partial+, so that Oracle does not deviate from the standard.

For more information, see:

-         Oracle MetaLink Note 394487.1 (subscription to MetaLink required) explains Oracle's implementation of the CVSS standard.

-         Oracle MetaLink Note 394486.1 (subscription to MetaLink required) provides a detailed explanation of Oracle?s risk matrices.

-         The Critical Patch Updates and Security Alerts page on Oracle Technology Network provides detailed information about previously released CPUs and Security Alerts.

-         The Guide to the Common Vulnerability Scoring System version 2.0 is available online, and it includes the scoring formulas set forth by the standard. 

Hi, this is Chad Hughes again.  In order to maintain a proper security posture, an organization must commit to developing and maintaining secure configurations on all layers of its environment.  Such commitment may require the organization to reconsider commonly accepted assumptions, dispel security myths, or just ?get back to the basics? of security.

For example, the ?Chronology of Data Breaches? compiled by the Privacy Rights Clearinghouse includes a number of instances where the improper disclosure of sensitive information could have been prevented by common sense, or basic security policies and procedures.  It is therefore not surprising that a recent Ponemon Institute survey sponsored by Oracle found that ?42 % of IT practitioners believe their organizations can do more to prevent loss or theft of confidential information? and ?Only 55 % of IT respondents believe they would be able to notify users and customers impacted by a data breach.  Of course, these issues are not limited to businesses, but also impact government organizations as well.  For example, a recent article on CSO Online related how the U.S. Department of Agriculture managed to expose thousands of social security numbers.

Incorrect technical assumptions can also be very damaging.  For example, while many IT professionals may think that databases are usually sheltered within corporate firewalls, in his 2005 and most recent 2007 ?Database Exposure Survey ? research, David Litchfield found that many databases are directly exposed to the Internet.  Unfortunately, generally innocuous search sites such as Google can be used to search for specific systems and services exposed to the Internet, and known vulnerabilities on those systems.  See for example ?Google Code Search peers into programs' flaws? on SecurityFocus or ?Google Your Site For Security Vulnerabilities? on Security Devcenter.  Michael Sutton's blog entry, ?How Prevalent Are SQL Injection Vulnerabilities,? includes an example of a simple Google query intended to find databases exposed directly or indirectly to the Internet.

A myopic concern with external threats and hackers may also lead organizations on the wrong path by focusing the security effort exclusively towards securing the perimeter of the organization.  For example, a quick glance at the web site of the Computer Crime & Intellectual Property Section of the United States Department of Justice shows that employees (both current and former) and contractors represent a significant portion of perpetrators.  When hardening exercises are performed in production environments, far too often only the Internet-facing edge of production environments get the hardening treatment, creating a hard, crunchy shell, but leaving a soft, gooey center.  The problem is that the hard crunchy shell often allows outside access to sensitive resources at the center to provide legitimate access to a set of services or applications.  When hardening the center is neglected, leaving it soft and gooey, it may be vulnerable to attack through these holes intentionally left open in the hard, crunchy shell.  As a result, it is not uncommon to witness situations where a compromised web applications server has resulted in the compromise of internal servers, sometimes even granting the attacker with privileged access on these machines.  An unprotected center also may unnecessarily expose valuable resources to internal threats such as human error, disgruntled employees, and malware propagation.

Even when an organization understands the need to work on all layers of its production environment, often enough, the secure configuration effort is hampered by the belief that such effort will require a tremendous amount of resources.  However, this is not necessarily true!

The effort of limiting the attack surface of the environment can yield significant security benefits.  This is because, in complex applications, no one-size-fits-all configuration can possibly accommodate the needs of every customer.  In most instances, customizing the installation to leave the proper balance of functionality is desirable to meet production and security objectives.  Production systems that are left in their default state are likely to contain unused functionality that varies from customer to customer.  Unused functionality in production environments needlessly increases the exposure surface, or total number of possible attack vectors.  To reduce the exposure risk, customers can limit production system functionality to that which is required.

The greatest advantage of reducing surface area of production environments is that it contributes to significantly increasing the security posture of the organization at a relatively small cost. This is particularly true when hardening can be automated so the incremental cost to harden is low. Hardening production environments by reducing the attack surface is relatively inexpensive compared to many other defense in depth safeguards: it typically doesn?t require expenses for acquiring additional licenses or hardware; hardening effort can be incremental so as to not dramatically impact production environment, etc.  Most importantly, the security return of a surface reduction effort is obvious -- if a defect is found in functionality you're not using, you're likely to be protected.  And you're likely to be protected before patching, before upgrading, before employing a work-around...nothing additional is required.  If a 0-day exploit happens to reside in unused functionality that was already disabled by a previous hardening exercise, you're protected.

For more information on Oracle?s Secure Configuration initiative, see my previous blog entry ?Oracle?s Approach to Configuration Hardening.?    Finally, the Oracle Software Security Assurance Resource Library includes valuable links to technical white papers and security checklists providing guidelines for reducing surface areas, or engaging in a more comprehensive hardening effort.

NOTE: Opinions expressed by the authors of the white papers and articles cited in this blog entry do not reflect the position of Oracle. Any advice, conclusion, or recommendations discussed on these sites (or sites they link to) are not validated by Oracle.

Hello, this is Eric Maurice again! 

Oracle today released the January 2008 Critical Patch Update (CPUJan2008).  This Critical Patch Update (CPU) addresses a total of 26 vulnerabilities affecting Oracle Database Server, Oracle Application Server, Oracle Collaboration Suite, Oracle E-Business Suite, and Oracle PeopleSoft Enterprise.  Eight of these vulnerabilities are specific to Oracle Database Server, including one vulnerability affecting Oracle Database Server 11g on Linux. 

While none of the Oracle Database Server fixes requires patching the database client-only installations, this Critical Patch Update includes fixes for six Oracle Application Server vulnerabilities, and two of these fixes are for client installations.  The two Application Server client fixes address severe vulnerabilities affecting JInitiator, a web browser extension that enables end users to run Oracle Forms Services applications within their browser.  These two vulnerabilities have received a CVSS score of 9.3 because they could allow an attacker to gain full control of the targeted client (e.g. a laptop or workstation) at the Operating System level.  Note however that these two vulnerabilities cannot be used to exploit a server. 

Hello, this is Eric Maurice!

A security vendor recently issued a press release that revealed the results of an informal survey it conducted of Database Administrators conducted at Oracle Users Group meetings throughout the United States.  The vendor allegedly found that two-thirds of the 305 respondents had never installed a Critical Patch Update.  A number of outlets including blogs and media publications commented on these findings.

It is difficult to draw firm conclusions from this survey because of the relatively small size of the sample, absence of information about representativity of the sample, and the formulation of the questions themselves.  However this survey is interesting to security professionals insofar as it reinforces the importance of patching and brings to light a new element: the psychology of patching. 

Commenting in a blog entry, Pete Finnigan made an interesting comment: ?I am starting to get the impression from talking to a lot of people that the issue has become psychological, a lot of companies believe it?s difficult, that it will fail and that everything in the organization needs to be regression tested.?  Security professionals are periodically faced with the decision ?to patch or not to patch.?  For some, this decision is very difficult because it comes down to weighing the known and immediate consequences of the patching procedure (significant effort for testing and deploying the patches, and the impact of temporarily affecting production environments) versus the unknown and hard-to-predict consequences of keeping known vulnerabilities unpatched (damages resulting from an incident that was enabled by the presence of the unpatched vulnerability).  It is generally in human nature to find known and immediate difficulties more daunting than those that are uncertain and more remote, though the uncertain ones might have much more critical and threatening impact.  Can the decision not to patch be likened to the decision by careless drivers to run yellow or red lights to avoid being delayed for three or four minutes, while consciously ignoring the potential price of such action (possible death or injury) if collisions were to occur? 

The only solutions for removing the psychological objections to patching are mandating the application of security patches as a part of the normal maintenance of production systems or providing objective measures to determine whether patching is required on certain systems at a certain point in time. 

Patching decisions can only become objective business decisions if they are made after computing the expected cost or benefit resulting from the application of the security patches on a given system.  The costs of the patching effort and its impact on production environments need to be measured against the probability that the unplugged vulnerability will result in a successful exploit, multiplied by the financial liability that this successful exploitation would create for the organization.  Unfortunately, there is no such thing as an actuarial table that would provide accurate statistical measures of the chance of occurrence of a specific incident or exploit; and furthermore, measuring the full financial impact (direct and indirect costs) of a potential incident is extremely difficult, therefore a lot of guesswork has to take place.  This is why most security-conscious organizations require mandatory patching, instead of attempting to develop a comprehensive quantitative risk model for all their systems in their environment.

Oracle recommends that customers apply the Critical Patch Updates when they become available to maintain a proper security posture.  However, immediate and systematic application of every security patch on an ongoing basis for all production systems may be difficult or impossible for some organizations because of the complexity of their environment or due to their production requirements.  This is why Oracle has intentionally designed the Oracle Database Server, Oracle Application Server, Oracle Enterprise Manager, and Oracle E-Business Suite R12 patches to be cumulative.  As a result, each Critical Patch Update for these products contains the security fixes from ALL previous Critical Patch Updates.  The benefit for customers is clear: applying the most recent Critical Patch Update will install all the fixes that were previously released for these products.

Note that customers, who are applying the most recent patch sets also get the benefit of previously released security fixes.  That is because security fixes are also included in patch sets and in new product releases (Oracle?s policy is to first fix security vulnerabilities in the current code, i.e., the code used for the next release of the product).  The inclusion of security fixes in patch sets and product releases provides customers more patching flexibility, effectively allowing those who are planning to deploy the most recent patch set to ?skip? the application of a Critical Patch Update. 

When looking at the previously discussed survey, one is left to wonder if the inclusion of security fixes in patch sets had the undesirable consequence of causing some Oracle DBAs to mostly ignore Critical Patch Updates, opting instead to focus resources on applying patch sets.  However, Oracle recommends that the Critical Patch Updates remain the primary means of applying security fixes because Critical Patch Updates are released more frequently than patch sets and new product releases. 

You can find more information about Oracle?s security lifecycle policies on the Security Vulnerability Fixing Policy and Process page on Oracle Technology Network.  The Critical Patch Updates and Security Alerts page also on Oracle Technology Network provides detailed information about previously released Critical Patch Updates and Security Alerts.  Additionally, the Resource Library on the Oracle Software Security Assurance web site provides a number of links to useful security resources, including a white paper discussing how to develop a repeatable Critical Patch Update process

Hello, this is Shirley Ann Stern!  Recent security research indicates that SQL injection attacks constitute one of the most prevalent types of threats to IT environments.  For example, in its ?Top 20?, SANS identifies SQL Injection as a major threat to Web applications.  

SQL injection is one of the most common forms of attacks carried out at the application layer.  In layman?s terms, SQL Injection attacks are designed to leverage improper coding of web applications that, in the absence of proper input validation, allow a malicious attacker insert string input to an application, and as a result, send potentially harmful SQL commands to the application?s back-end database.  Although any program or application (that is powered by a database) may be vulnerable to SQL injections, web applications are at a higher risk because they often allow an attacker to perpetrate SQL injection attacks without being authenticated to the targeted database or application.  The potential consequences of these attacks are serious.  A successful SQL Injection attack can allow the attacker to gather sensitive data, manipulate database information, and in some instances, to change the structure of the database, deny legitimate access to it, or grant unauthorized privileges to himself or others.

An important objective of Oracle Software Security Assurance is that we provide information to customers that helps enable them to use our products securely.  To this end, we have developed training materials titled  ?Defending Against SQL Injection Attacks.?  Available now, this training content is available online and can also be downloaded so that offline studying (while in the train for your morning commute) is possible.  ?Defending Against SQL Injection Attacks? highlights some of the coding practices required to eliminate SQL injection vulnerabilities when developing in an Oracle environment.  Oracle recommends that anyone who develops Internet applications that access an Oracle database review these materials.  Note that this tutorial will also be available through Oracle University as a lesson in the instructor-led course ?Oracle Database 11g: Advanced PL/SQL?, which is scheduled to be available in April 2008.

More information on Oracle Software Security Assurance is available on Oracle.com.  Various trainings, including ?Defending Against SQL Injection Attacks? are available on the Server Technologies Curriculum Web Site.  The Security Technology Center and Oracle Software Security Assurance Resource Library also include a number of useful links to security trainings and white papers. 

Hello, I'm Petra Manche!  I work in the Security Evaluations team in Oracle's Security Assurance Group.  Security Evaluations are a critical part of Oracle Software Security Assurance, and my team is responsible for managing the independent security evaluations of all Oracle products

Oracle recently completed the evaluations of Oracle Database 10g Release 2 (10.2.0.3) and Oracle Label Security 10g Release 2 (10.2.0.3) against Common Criteria assurance level EAL4+ and against the U.S. Government Protection Profile for Database Management Systems in Basic Robustness Environments (Version 2.1).   As usual Oracle evaluated the Enterprise Edition of the Database, but for the first time we also evaluated Standard Edition and Standard Edition 1.  Real Application Clusters (RAC), Enterprise Users, and Partitioning were also included with these evaluations for the first time.

For those who don't know what Security Evaluations are: independent bodies (laboratories) examine Information Technology products and systems, and if the examination is passed, a certificate is awarded (usually by a government body).  This process provides confidence in the security of the Evaluated products to end users, including government and military institutions.

Oracle has a long history among IT vendors of having security evaluations performed on its products.  Since committing to the security evaluation process in 1990, Oracle has successfully completed 29 security evaluations.  Many of the early evaluations were on Oracle Database Server, but more recently we have extended our scope and evaluated other products including Oracle Enterprise Linux, Oracle Application Server and Oracle Internet Directory. 

Oracle is currently committed to evaluating its products under two industry standards:

-         FIPS 140 for cryptographic modules, and

-         Common Criteria for Information Technology Security Evaluation. 

FIPS stands for Federal Information Processing Standard.  The full title of FIPS 140 is ?FIPS 140-2: Security Requirement for Cryptographic Modules.?  It is published by the U.S. National Institute of Standards and Technology (NIST).  Hardware, firmware or software cryptographic modules are all tested and validated against the standard.  The cryptographic algorithms are NIST approved.  FIPS 140-3 is currently being drafted and representatives from Oracle will attend the upcoming FIPS 140-3 Software Security Workshop.

Common Criteria (CC) is also known as ISO standard 15048.  The full title of the standard is ?Common Criteria for Information Technology Security Evaluation".  The Common Criteria is a single framework of evaluation criteria for products or systems.  It is designed to look at the whole development lifecycle: from design, implementation, testing to delivery and installation of the product or system by a third party, in order to provide assurance that development practices have been documented, followed and enforced correctly.

A common misconception about the Common Criteria is that the entire product is always evaluated in this process.  In fact, it is the security-related functions and the parts of the product that interact with those security functions that are evaluated.  These make up the scope of the evaluation, a.k.a. ?Target of Evaluation?.  The product is installed in an evaluated configuration, whereby some of the product functionality may be disabled but the product must be able to function normally.  Information on what exactly has been evaluated is found in a document called the ?Security Target?.  This document is publicly available once a product has been certified.  Security Targets for Oracle software are available on the Security Evaluation page on Oracle Technology Network.

To date Oracle has completed four FIPS 140 validations and 15 Common Criteria evaluations.  A listing of the evaluations that have been obtained or are currently underway can be found on Oracle?s Security Evaluation status page. 

Note that Oracle not only performs evaluations, but it is also actively participating in the development of the Common Criteria.  Oracle is a member of the Common Criteria Vendors Forum (CCVF) that works with the Common Criteria International organisations to enhance the Common Criteria and address common issues within the criteria.  In a previous blog entry, Duncan Harris discussed some of the limitations with the current version of the Common Criteria. 

More information on Oracle Software Security Assurance is available on Oracle.com.  The Security Evaluation page on Oracle Technology Network provides detailed information about Oracle's involvement with Security Evaluations.

Hi, this is Eric Maurice!  This very short blog to let you know about recently recorded podcasts and webcasts on Oracle Software Security Assurance topics.

We recently recorded a podcast interview with Oracle CSO, Mary Ann Davidson.  In this podcast, Mary Ann discusses the importance of Oracle Software Security Assurance, the role of Oracle?s Global Product Security Group, and some of the changes that were introduced with the Critical Patch Update. 

Oracle and the Enterprise Best Practices Special Interest Group (SIG) of the Independent Oracle User Group recently delivered a one hour webcast introducing Oracle?s secure configuration initiative and discussing the security enhancements in Oracle Database 11g.  In this webcast, Daniel Wong, Director of Engineering for Database Security at Oracle, discusses in technical detail the security changes introduced in the default configuration of Oracle Database Server with 11g.  Such changes affect the default audit settings, authentication and password management, and access control changes to certain UTL packages, etc.  Daniel then provides security recommendations for customers who are looking at upgrading (or have upgraded to) Oracle Database 11g.  A previously recorded webcast providing technical recommendations for securely configuring Oracle databases is also available on the IOUG website under the archived SIG webcasts section. 

Note that a registration to IOUG?s web site may be required to access some of this content (FREE membership to the Enterprise Best Practices SIG is also available here).

For more information:

Mary Ann Davidson?s interview is available here.

IOUG?s webcast on Oracle Database 11g security is available here.

IOUG?s webcast on securely configuring Oracle databases is available here.

Oracle Software Security Assurance Resource Library is available here.

The download page for IOUG?s Enterprise Best Practices SIG is available here.