|
Patch management: Filling security holes |
|
|
|
Source: ZDNet.co.uk - Posted by Benjamin D. Thomas
|
Nobody knows when the first patch was issued, but it was almost certainly shortly after the first release of the first software package. No matter how much testing is done in-house, the real world and real users always exercise applications in . . .
Nobody knows when the first patch was issued, but it was almost certainly shortly after the first release of the first software package. No matter how much testing is done in-house, the real world and real users always exercise applications in ways the writers never foresaw or tested: even the largest software company can't afford the time or resources to exhaustively check complex products -- which is not to say they can't do better. Patches will be with us always. At its simplest, where a software company sends out a small piece of code that must be transplanted into the body of the ailing software, patching takes a few moments. This doesn't scale well. Ask anyone responsible of late for collections of Windows machines, as soon as there are multiple machines with multiple configurations, even deploying and checking a single patch can take a long time. When there are multiple patches, patch management threatens to become a full-time job. And multiple patches are becoming the norm: the CERT security advisory team reported over 4,000 vulnerabilities in 2002, fuelling a veritable industry of patching that is variously estimated to cost businesses and governments up to $1.5bn worldwide.
Read this full article at ZDNet.co.uk
Only registered users can write comments.
Please login or register. Powered by AkoComment! |
