<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Oracle CPUs &#8211; Do We Care?</title>
	<atom:link href="http://www.slaviks-blog.com/2007/08/22/oracle-cpus-do-we-care/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.slaviks-blog.com/2007/08/22/oracle-cpus-do-we-care/</link>
	<description>Slavik&#039;s Blog</description>
	<lastBuildDate>Wed, 14 Dec 2011 10:35:06 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Kevin</title>
		<link>http://www.slaviks-blog.com/2007/08/22/oracle-cpus-do-we-care/comment-page-1/#comment-887</link>
		<dc:creator>Kevin</dc:creator>
		<pubDate>Tue, 04 Dec 2007 17:26:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.slaviks-blog.com/2007/08/22/oracle-cpus-do-we-care/#comment-887</guid>
		<description>I tend to work in more secure environments where the CPUs are not optional. Our approach is to do an analysis of the CPU based on the CVSS score and security controls in place in the particular environment that may mitigate the vulnerabilities. This gives us a priority for which components to patch first but all are eventually patched. In generally, we consider ourselves successful if we can complete the CPU before the next one comes out. Not exactly a high bar for success but about the best we can do when confronted with HA requirements and, oh yeah, doing the real work of the company.

We struggle with the E-Business Suite patches not being cumulative. You cannot fall behind and catch-up on the next CPU.

A place we seen a little improvement is the quality of the patches for &quot;stand-alone&quot; components. Obviously from a security perspective you should only install what&#039;s needed. So if you only need Web Cache or Apache (OHS) just install the stand-alone components rather than the full app server. The CPU&#039;s failed on a regular basis for these environments but have been better of late. It looks like Oracle is now doing a better job of testing the CPUs for the stand-alone components.</description>
		<content:encoded><![CDATA[<p>I tend to work in more secure environments where the CPUs are not optional. Our approach is to do an analysis of the CPU based on the CVSS score and security controls in place in the particular environment that may mitigate the vulnerabilities. This gives us a priority for which components to patch first but all are eventually patched. In generally, we consider ourselves successful if we can complete the CPU before the next one comes out. Not exactly a high bar for success but about the best we can do when confronted with HA requirements and, oh yeah, doing the real work of the company.</p>
<p>We struggle with the E-Business Suite patches not being cumulative. You cannot fall behind and catch-up on the next CPU.</p>
<p>A place we seen a little improvement is the quality of the patches for &#8220;stand-alone&#8221; components. Obviously from a security perspective you should only install what&#8217;s needed. So if you only need Web Cache or Apache (OHS) just install the stand-alone components rather than the full app server. The CPU&#8217;s failed on a regular basis for these environments but have been better of late. It looks like Oracle is now doing a better job of testing the CPUs for the stand-alone components.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Doug's Oracle Blog</title>
		<link>http://www.slaviks-blog.com/2007/08/22/oracle-cpus-do-we-care/comment-page-1/#comment-182</link>
		<dc:creator>Doug's Oracle Blog</dc:creator>
		<pubDate>Sat, 27 Oct 2007 21:22:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.slaviks-blog.com/2007/08/22/oracle-cpus-do-we-care/#comment-182</guid>
		<description>&lt;strong&gt;The Reality Gap (1) - Software Maintenance...&lt;/strong&gt;


It&#039;s so long now since the OUG Scotland Conference and I ended up leaving early because I wasn&#039;t feeling too good so I&#039;m not going to attempt a review of the day. I asked a few others what they thought afterwards and the general view was that the ...</description>
		<content:encoded><![CDATA[<p><strong>The Reality Gap (1) &#8211; Software Maintenance&#8230;</strong></p>
<p>It&#8217;s so long now since the OUG Scotland Conference and I ended up leaving early because I wasn&#8217;t feeling too good so I&#8217;m not going to attempt a review of the day. I asked a few others what they thought afterwards and the general view was that the &#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Slavik</title>
		<link>http://www.slaviks-blog.com/2007/08/22/oracle-cpus-do-we-care/comment-page-1/#comment-142</link>
		<dc:creator>Slavik</dc:creator>
		<pubDate>Thu, 23 Aug 2007 20:39:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.slaviks-blog.com/2007/08/22/oracle-cpus-do-we-care/#comment-142</guid>
		<description>Hi Matt, thanks for your insightful comment. It&#039;s certainly not an all-or-none decision whether to apply or not apply CPUs and when. Given the genuine difficulty in performing any kind of upgrade to a production database, I think that your approach can certainly result in better security with minimal business disruption. It may require some education, however, since people tend to ignore threats they don&#039;t understand (until the threats have materialized...)</description>
		<content:encoded><![CDATA[<p>Hi Matt, thanks for your insightful comment. It&#8217;s certainly not an all-or-none decision whether to apply or not apply CPUs and when. Given the genuine difficulty in performing any kind of upgrade to a production database, I think that your approach can certainly result in better security with minimal business disruption. It may require some education, however, since people tend to ignore threats they don&#8217;t understand (until the threats have materialized&#8230;)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Oracle CPUs - Do We Care? auf maol symbolisch</title>
		<link>http://www.slaviks-blog.com/2007/08/22/oracle-cpus-do-we-care/comment-page-1/#comment-141</link>
		<dc:creator>Oracle CPUs - Do We Care? auf maol symbolisch</dc:creator>
		<pubDate>Thu, 23 Aug 2007 16:30:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.slaviks-blog.com/2007/08/22/oracle-cpus-do-we-care/#comment-141</guid>
		<description>[...] fragt sich: Oracle CPUs - Do We Care? [&#8230;] do we care about Oracle CPUs at all? Oracle was getting a lot of heat from security [...]</description>
		<content:encoded><![CDATA[<p>[...] fragt sich: Oracle CPUs &#8211; Do We Care? [&#8230;] do we care about Oracle CPUs at all? Oracle was getting a lot of heat from security [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mattypenny</title>
		<link>http://www.slaviks-blog.com/2007/08/22/oracle-cpus-do-we-care/comment-page-1/#comment-140</link>
		<dc:creator>mattypenny</dc:creator>
		<pubDate>Thu, 23 Aug 2007 15:47:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.slaviks-blog.com/2007/08/22/oracle-cpus-do-we-care/#comment-140</guid>
		<description>Hi, 

I did a user group presentation about applying CPUs earlier in the year. I think its fair to say that the numbers would have been similar at that group as they were for yours. 

My recommendation, for what its worth, was, and is, that the DBA agrees a CPU patching strategy with one or more of the following: 
- their boss, 
- the individual business owners
- the security team
...and gets this agreed to in writing.

These people, depending on the organization, should all have a say in weighing up the risks of patching (or not patching), versus the work involved. This is  a lot easier to achieve, I think, since the CVSS has been adopted.

The strategy could be to:
- apply all relevant CPUs
- apply no CPUs
- apply relevant CPUs with a certain CVSS score

If you have an agreed strategy and something goes wrong - i.e. either the CPU mucks up your database, or you get hacked - then its not just the DBA who carries the can.

Cheers

Matt</description>
		<content:encoded><![CDATA[<p>Hi, </p>
<p>I did a user group presentation about applying CPUs earlier in the year. I think its fair to say that the numbers would have been similar at that group as they were for yours. </p>
<p>My recommendation, for what its worth, was, and is, that the DBA agrees a CPU patching strategy with one or more of the following:<br />
- their boss,<br />
- the individual business owners<br />
- the security team<br />
&#8230;and gets this agreed to in writing.</p>
<p>These people, depending on the organization, should all have a say in weighing up the risks of patching (or not patching), versus the work involved. This is  a lot easier to achieve, I think, since the CVSS has been adopted.</p>
<p>The strategy could be to:<br />
- apply all relevant CPUs<br />
- apply no CPUs<br />
- apply relevant CPUs with a certain CVSS score</p>
<p>If you have an agreed strategy and something goes wrong &#8211; i.e. either the CPU mucks up your database, or you get hacked &#8211; then its not just the DBA who carries the can.</p>
<p>Cheers</p>
<p>Matt</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.454 seconds -->

