On October 17th Oracle released the mother of all patches. It addressed 101 vulnerabilities in 12 Oracle components. Although Mogull and the gang back at the ranch have this event pretty much covered I wanted to post some thoughts.
The changes Oracle has made to their CPU process is a good thing, and I have commented on them recently (here). Personally I think there is going to be an issue with bundling hundreds of vulnerabilities though, what happens if this CPU breaks one component(s)? How will this affect QA testing? What mechanisms do organizations have in place to support the deployment of such a large CPU? Will this increae or decrease the liklihood organizations will attempt to address the CPU in a timely fashion?
I know that DBA’s are ultra-conservative and prefer bundled patching that allows for less frequent QA cycles and patch updates. It has only been recently that organizations have even realized the need to patch Oracle in response to potential security threats, most believe that their perimeter shields them from attack. Also there are no broad automated attacks targeting Oracle, but that will not last. However, this bundled approach does not allow for rapid-patching of targeted components if a critical event were to occur, although Oracle does state they can provide a critical patch if needed. They also do not provide enough inormation on potential work-arounds that organizations can take in place of patching (which is a logistical nightmare for most). The real issue with a bundle of 101 vulnerabilities that address 12 different components is that some within an organization might make the case that QA testing will take 4-6 months, or longer. If every CPU includes a high number of vulnerabilities that are being addressed, well, very quickly organizations will be 2-3 CPU’s behind Oracle, which releases these quarterly, increasing the likelihood of exposed and vulnerable conditions that attackers can pick off.
Couple of other points to remember
1. Targeted, financially motivated malware attacks are increasing – attackers are after data, where is data stored? Databases! Couple this with organizations externalizing more services over the web and moving beyond brochure ware to compliacted services delivered over the web, which in most cases, has a DB backend component.
2. Most organizations have very little visibility and control over their DB’s. At a recent conference I presented on Vulnerability management (which is not just scanning and patching) I asked the audience of several hundred how many were concerned with their database security initiatives or felt that databases were a vulnerbility management weak spot – only 2 people replied that they were. After the presentation I asked the question again and the number was around 90%
We are headed towards very significant database security issues and organizations need to take these seriously before their reputation, their bottom line, their shareholder value, and their entire business is severally impacted. Step one is to acknowledge that data security is important and that database systems need to be included as part of an organizations vulnerability and threat management, network security, identity and access management, and risk management programs. Step two is taking action…
btw – for those who do not get the “all your base are belong to us” reference (here)