Controlling Access To Security Vulnerability Information At Oracle

Hi, this is Shaomin Wang. I am sometimes asked how Oracle manages employee access to security vulnerability information. Obviously, technical information related to vulnerabilities in Oracle products is very sensitive; not only because this information may be related to unpatched vulnerabilities, but also because the technical nature of this information, if improperly disclosed or shared, could help malicious attackers develop exploit code targeting Oracle systems.

Not surprisingly, Oracle has clear policies governing how this information can be accessed and used internally. Oracle's Security Vulnerability Information Protection Policy defines the classification and handling of information related to product security vulnerabilities. The policy restricts access to security bug information on a strict need-to-know basis: This is to say, Oracle employees without a need to know can't access security bugs information.

To meet the requirements set forth by Oracle's Security Vulnerability Information Protection Policy, Oracle internally implemented a mechanism to enforce specific access controls against security vulnerability data. The main objective of these controls has been to enforce the "need-to know" principle by limiting access to security bugs information to the appropriate personal without necessarily causing undue inconvenience to the Oracle's development and support staffs who may need access to this data in the course of their job (such as when producing security fixes).

As previously stated, access to this information is limited on a "need to know" basis; an employee must have a valid internal account to access the bug descriptions in Oracle products. Employees are granted access to this information based on three access types: Default Access, Global Access and Hierarchical Access.

Default Access: employees can access a security bug if any one of the following criteria is met:

  • The user reported the bug as a security bug, or changed an existing bug from a non-security bug to a security bug OR

  • The user was assigned ownership of the bug OR

  • The user was given explicit access to the bug by another user who already has access to the bug OR

  • The user is the manager of the bug filer or bug assignee.

Global Access: employees in this group can access all security bugs. Since Oracle considers security vulnerability data to be extremely sensitive information; Global Access is restricted to a very small subset of employees, mainly Global Product Security staff. For all other people within Oracle, it is expected that Hierarchical Access will meet their business needs for access to security bugs.

Hierarchical Access: some employees can access any security bugs for particular products or components. For example, some employees can view all security bugs filed against a specific Oracle product. This access type is based on the hierarchical relationship of the individual.

In Oracle's internal bug modeling database, Oracle products are grouped hierarchically:

Product Suites - Product Groups - Products - Product Component

Take the example of the Cloud Backup Module, a component under Oracle Secure Backup. The hierarchical representation in Oracle's bug modeling database is like this:

Database Suite - Server Technology - Oracle Secure Backup - Cloud Backup Module

Individuals with hierarchical access can access all security bugs for a given product suite, product group, product, product component, depending on the Hierarchical Access they were previously granted. Security access, once granted to a hierarchical level, is cascaded automatically within the hierarchy. Take the above example, if a user is granted security access to Oracle Secure Backup, which is a product under Database product suite, the user is then able to access all security bugs filed against Oracle Secure Backup. However, the user cannot access security bugs filed against other Database products, such as Database Vault for example. If a user is granted security access to Database Product Suites, he/she is able to access all security bugs filed against Database Products. Note that only a limited number of people, such as Product Suite security leads and release managers are granted access on Product Suite levels.

Hierarchical Access provides an easy and flexible means to manage access within the internal Oracle product development organizations. The system has worked very well and in fact, we have experienced a reduction in the number of employees with access to this sensitive information down to less than one percent of the entire Oracle's development organization.


Post a Comment:
Comments are closed for this entry.

This blog provides insight about key aspects of Oracle Software Security Assurance programs.


« July 2016