Free Newsletter
Register for our Free Newsletters
Newsletter
Zones
Access Control
LeftNav
Alarms
LeftNav
Biometrics
LeftNav
Detection
LeftNav
Deutsche Zone (German Zone)
LeftNav
Education, Training and Professional Services
LeftNav
Government Programmes
LeftNav
Guarding, Equipment and Enforcement
LeftNav
Industrial Computing Security
LeftNav
IT Security
LeftNav
Physical Security
LeftNav
Surveillance
LeftNav
View All
Other Carouselweb publications
Carousel Web
Defense File
New Materials
Pro Health Zone
Pro Manufacturing Zone
Pro Security Zone
Web Lec
 
ProSecurityZone Sponsor
 
ProSecurityZone Sponsor
 
ProSecurityZone Sponsor
 
ProSecurityZone Sponsor
 
ProSecurityZone Sponsor
 
ProSecurityZone Sponsor
 
 
News

Patching Alone Insufficient To Close All Vulnerabilities

Imperva : 12 January, 2011  (Technical Article)
Microsoft’s first patch release for 2011 doesn’t include fix for known vulnerability demonstrating that patching in isolation doesn’t close out all system problems
Microsoft has released its first patch for 2011 which Noa Bar-Yosef, Senior Security Strategist at Imperva has commented on.

 

“It is interesting to note that this release does not contain a patch for a known vulnerability. There are already reports of exploits targeting this vulnerability, and Microsoft has issued advisories on ways to block the threat. However, this release exemplifies the problems with vendor patching. Patching is a complicated process. Take for example, Oracle. Oracle issues a quarterly Critical Patch Update (CPU). According to the Independent Oracle User Group (IOUG) – patching takes from 3-6 months. Although Oracle patches are server side which in short means updating a large number of enterprise databases, and in this specific Microsoft release most of the vulnerable products are client-specific, we see the same issues arising for both:



1.       Assessing the exploits as mentioned in the patch. This includes understanding the details of the exploit and whether it is even applicable to the specific user. It is important also to understand how an attack would affect the system.

2.       Assessing the process of patching. Sometimes a patch may be contradictory to an already existing code, or even a work-around.

3.       Patching the system itself. The patching process should be continuously reviewed. For instance, it already happened that Microsoft released a patch which broke another fix!

 

Yet – as this case shows, even having a patch does not necessarily mean fixing all system vulnerabilities, which leaves the user to hope for some other solution to mitigate those threats.”
Bookmark and Share
 
Home I Editor's Blog I News by Zone I News by Date I News by Category I Special Reports I Directory I Events I Advertise I Submit Your News I About Us I Guides
 
   Â© 2012 ProSecurityZone.com
Netgains Logo