Oracle Security, Where Art Thou?

The Register is reporting (here) that Argeniss Information Security is planning a week of Oracle Bugs (here) – “An Oracle Database 0day will be released every day for a week on December.”

As I have mentioned in the past (here), and (here) Oracle is beginning to experience similar security issues as Microsoft did in the late 90’s and early part of the millennium. The perfect storm may be brewing; a large, massively deployed vendor who has significantly misunderstood their requirements to deliver secure applications, build security functions into their product lines, and support their users in dealing with external threats. Couple this with a changing threat environment targeting theft of data and a lack of security awareness, process and technologies in most enterprises to deal with database security and it is highly likely that we are on the verge of an era marked by serious database security issues affecting IT in the same way Microsoft has in the past but with a much higher damage potential.

Most enterprises lack visibility and control over their DBs and large applications and believe that other operational controls, such as firewalls, protect their DB’s from attack. The reality is that most networks are increasingly complex with many vectors that can be used to gain access. Moving to improve DB security capabilities will increase the ability for organizations to limit the probability of a successful attack and if one does occur limit its impact on their environment, which is about all they can do (here)

Recommendations to Enterprises (in no particular order):
– Encrypt the data.
– Database activity monitoring is critical as is identify and access management and user provisioning programs, implement these now
– Integrate Database systems into your vulnerability management program; assess your database systems against known vulnerabilities, define a corporate policy for secure DB configurations and audit your environment against this policy. Look for vendors that can provide deep vulnerability and configuration assessments of DB’s.
– Implement a patch management program for databases; define a policy for dealing with quarterly CPU’s, implement a test environment for quick turn-around, look for technologies that can automate steps of the process, assess the logistical limitations of patching critical DB’s – which will be many.
– Leverage other security and networking technologies to shield DB’s in the event of exploit code in the wild, such as firewalls, IPS, patch proxies, server side HIPS/PFW’s, put a plan in place in case the decision is made to pull the plug.
– Implement technologies and processes to support identification of suspicious or anomalous behavior involving DB’s; SIEM and NBA (here) can assist in providing this level of visibility
– Pressure Oracle; to improve their security processes and to provide information on vulnerability mitigation, including measures that can be taken to reconfigure databases, server, or network systems to shield the systems prior to deploying a patch.

Recommendations to Oracle:
– Make the SDLC more transparent, implement more security functionality with product line and increase internal security resources and focus
– Provide information on mitigation options that organizations can implement when patching is logistically impossible.
– Provide configuration auditing and security assessment tools
– Improve patching capabilities, including mechanisms to support patching sub-components (currently you have to deploy the entire CPU)
– Work with 3rd party vendors to improve their DB security offerings
– Implement a program to work with security researchers, and stop all the antagonistic behavior.

Recommendations to Security Researchers:
– Continue to make attempts to work with Oracle; the market will eventually pressure them to improve their vulnerability response programs
– Do not release 0-day vulnerability information the week of Christmas, because that would just really suck! Releasing information on vulnerable conditions without providing guidance that enterprises can use to protect their environments isn’t helpful and organizations should avoid working with any entity that puts their organization at risk.

Bottom line: Enterprises need to classify database security as critical and move to implement processes and technologies that will provide greater visibility and control over their database systems or face potentially devastating losses.