Oracle Security Alert for CVE-2012-3132

Published: 2012-08-12
Last Updated: 2012-08-12 15:56:01 UTC
by Tony Carothers (Version: 1)
0 comment(s)

One of our ISC readers, Dave, sent us a note that Oracle released a security note for CVE-2012-3132, the Privilege Escalation vulnerability in the Oracle Database Server initially discussed during Black Hat 2012.   I recommend carefully reading the wording of this notification because there are Oracle products that contain the Oracle Database Server as a component of the overall suite, such as Oracle Enterprise Manager.  One comment that Dave and both had is that Oracle found it necessary to highlight what didn't need to be patched, in bold comments near the top of the article.  Our thought was that this could be misleading or misunderstood, and confusion is never a good thing.

tony d0t carothers --gmail

0 comment(s)

Layers of the Defense-in-Depth Onion

Published: 2012-08-12
Last Updated: 2012-08-12 00:08:33 UTC
by Tony Carothers (Version: 1)
0 comment(s)

Defense-in-Depth (DiD)  is a term that is often used within the CyberSecurity world, but what does it really mean?  It basically means that we have the ability to monitor and control operations at different points within the enterprise infrastructure to give us a perspective from which we can defend our assets and resources.  An onion has layers (I know, cheap movie reference there) but unlike an onion, the layers in a defense in depth approach have different functions.

The two most common layers in a DiD onion is the network firewall and host-based antivirus.  These are proven technologies that address a number of threats, and I would call these a ‘must-have’ for any SOHO environment.  In spite of their maturity, these technologies have flaws old and new that have been exploited for years.  Compound this with the operational exceptions that are often put in place to support operational requirements, and the technologies become fairly limited.  An analogy a colleague gave me this week is, essentially, that “a firewall is like a prison with a single fence, and the AV are the guards in the middle that watch the fence.  When exceptions are put in place that tell these systems ‘don’t look here’ you are blinding the guards and crippling a small piece of that defense component”. 

So let’s talk about the firewall.  The firewall is an outstanding piece of network equipment, a critical piece of security infrastructure, that is good at stopping packets it has been told to stop, and reporting to us that it has stopped the traffic we asked it to stop.  It is also very good at passing traffic it has been told to ignore.  And here is where the fun begins.  One class of traffic that is mostly ignored, and for good cause, is outbound user traffic.   Human nature being what it is, accidents and mistakes happen, which leads to an inadvertent incident and possible compromise.  For example, when a user visits a compromised web page, that user then becomes a compromised user.

Now where is the antivirus?  The antivirus application is running right along, analyzing the files, folders, and transactions as configured.  The problem comes in this: Most instances of antivirus suites I have observed in deployment have many of the default settings still in place.  I know what these defaults are, and so do the hackers writing the exploits that are being slid through the firewall.  Additionally, there are files and folders that are often recommended by the software manufacturer to be excluded from antivirus analysis because it impacts their performance.  Hackers usually know this too :)  

So there are a number of threats that exist that these technologies do not address, even when tuned to be as secure as they can possibly be made.  Add to it an environment where you have mobile users, it gets even more tricky.  In the FW/AV DiD approach, as soon as the device leaves the corporate network it has lost half of the defense that was put in place to protect it. 

Some questions to ask:

What are we monitoring?
What are we not monitoring?

tony d0t carothers --gmail

0 comment(s)

Comments


Diary Archives