I can see both sides of this debate. First on the patch side, it is a well
known fact that security should be layered. Ensuring all the appropriate
security patches are in place ensures that layer of security is in place
and working. If you are in an environment that requires high level of
security for whatever reason, this level of security and patching is
perfectly reasonable.
If you are in an environment that doesnt require such high security, or is
confident of the existing layers, the cost to return value simply may not
be present for installing these patches. In other words, as with most
things Oracle, it really depends on your environment and requirements.
On Tue, Nov 17, 2015 at 8:12 AM, Chris Taylor <
christopherdtaylor1994@xxxxxxxxx> wrote:
Tim,
With very deep respect to you, I want to analyze this a bit.
I think your argument stems from the idea that the Java vulnerability is a
*reasonable
risk *and measures can be taken to fence off the server *at risk. *I
would agree with except *there is a provided reasonable patching strategy
**to fix *the Java Vulnerabilities delivered in EM 12c.
In context, your argument is placed against the counter-argument:
Argument 1.) We can not patch the product (for whatever reasons) and
instead fence off the server that has the known vulnerabilities and leave
the security risk in place
versus
Argument 2:) We can patch (and Oracle provides the ways and means) the
Java vulnerability to fix the problem instead of protecting the problem.
The conclusion *reasonably *must be to fix the problem and perhaps also
fence the black box. There is no reasonable argument (that I can see) that
supports leaving the vulnerability unpatched unless ultimately Oracle's
provided patching solutions do not work. I'm working through the CPU 2015
Patch instructions for EM 12c now and getting ready to update the JDK (I'm
at like step 30 in my documentation I'm throwing together - where
individual patching instructions are all rolled into step numbers 25 & 26.
So lets say there's 9 patches, I'm really at like step 39 or something).
I'm going to clean up my steps once I'm sure everything "works" as expected.
Chris
On Tue, Nov 17, 2015 at 2:46 AM, Tim Hall <tim@xxxxxxxxxxxxxxx> wrote:
Hi.
I recognize the problem, but this is where I typically "educate" the
people involved. Security is not about, "always apply all patches to all
systems all the time". It is about identifying risk in context. All audit
and security processes allow for "exceptions to the rule". It is up to you
to identify where an exception is required and document why it is required
and any relevant risks, or why they are not risks in this context. Provided
that is all done correctly, there is no harm done.
Of course, if your client refuses to accept this, they are stupid and you
have to decide how to deal with this. Personally, I walk away. I've got
better things to do with my life than deal with idiot customers. :) I
understand not everyone has that option... :)
Cheers
Tim...
