To patch or not to patch - that is the question for many software customers. And it's particularly tricky one to answer when the software company won't say what the patch is for, as one reader discovered with a recent Critical Patch Update released by Oracle for PeopleSoft. "On October 18, I received an e-mail notification from Oracle/PeopleSoft that they released new path levels for their products that contain To patch or not to patch – that is the question for many software customers. And it’s particularly tricky one to answer when the software company won’t say what the patch is for, as one reader discovered with a recent Critical Patch Update released by Oracle for PeopleSoft.“On October 18, I received an e-mail notification from Oracle/PeopleSoft that they released new path levels for their products that contain critical fixes, urging that we install them,” the reader wrote. “For the company I work for, this meant upgrading our PeopleTools release from 8.46.10 to 8.46.16. Over the years we’ve been running PeopleSoft, we’ve learned that we can’t just take them at their word because we have always experienced some transitional instability and performance hits in the past with PeopleTool upgrades, without exception. We simply do not update the software unless there is a pressing need that addresses known, specific issues that affect our implementations.”“I opened a support case to learn the details behind the critical issues Oracle was concerned about with the patch,” the reader wrote. “Details were not — and are not — available on their website. I received an e-mail directing me to information on their website that gave no specific information about the nature of the critical fixes. I then called and wound up speaking with a support manager.” The Oracle support manager told the reader it was against Oracle policy to provide the information he needed for his risk assessment. “As a matter of policy, Oracle does not disclose detailed information about an exploit condition or results that can be used to conduct a successful exploit,” the Oracle manager told him in one e-mail. “Oracle will not provide additional information about the specifics of vulnerabilities beyond what is provided in the CPU or Security Alert notification, the Patch Availability Matrix, the readme files, and FAQs.”The reader pleaded that without more information he could not possibly do the risk assessment his company naturally wanted to do before making its decision. As he wrote the Oracle support manager: “Please understand that some managers at some companies expect their IT people to provide justifications for why and when critical patches are or are not implemented. I work for just such a company and yes, I do have management seeking explanations in regards to this PeopleTools patch … We cannot plan on diverting IT resources to implementing these patches without this information so that we can perform our own risk analysis. I hope that merely mentioning the name Microsoft conjures specters of failed patches and thousands of hours spent by thousands of IT professionals around the world futilely attempting to keep their systems properly patched.”When that yielded no useful details about the patch, the reader tried one more time to explain to Oracle why he needed to know more. “Oracle sends out this alert and expects us to jump with no information on which to base a business decision,” he wrote Oracle. “Do we have the staff to do it? What other projects will suffer due to diverting resources to applying the update? That’s just the beginning. You do not account for the time it takes to follow Oracle’s own recommended procedures for applying patches: apply to demo environment, compare to test environment, apply to test environment, test, compare to production environment, apply to production environment, pray nothing breaks. That doesn’t even take into account that all development on all PeopleSoft-related projects is halted or delayed because we can’t develop at one patch level and apply it to an application running at a different patch level during the time it takes to evaluate a patch/update and apply it to a production environment. It can take up to three months to do this properly. The timeframe can be shortened, of course, but again, we have no information on which to base any decisions. ALL of these considerations are part of the decision making process, regardless of consideration to critical issues.” Ultimately, though, his requests fell on deaf ears. “The bottom line is simply that, despite the fact we’re paying thousands of dollars per year for ‘support’ from them, Oracle will not disclose the information we require. I know from my phone conversations with the support manager that mine is not the only company pressing for specific information about the patch. I can only imagine the IT staff of those organizations are pulling their collective hair out. Our decision, given that we cannot justify the interruption to MIS activities and a certain amount of inevitable system downtime in the face of no information from which to base a decision, is to not install the latest patch. Risks be damned, Oracle be damned, but if no one will disclose the information we require, how can we justify any other decision?”After all, there’s no security in a security update that may cause a customer more problems than it fixes. What’s your take on Oracle’s patch policy? Call the Gripe Line at 1 888 875-7916 or write me at Foster@gripe2ed.com.Read and post comments about this story here. Technology Industry