Page 331 - StudyBook.pdf

Communication Security: Web Based Services • Chapter 5 315

program. In some cases, developers of the program may know the bugs exist, but
the software was shipped anyway to meet a certain release date or other reasons.
After all, it is better for the company (although not necessarily the consumer) to
have the software on shelves, bugs and all, and then release patches later to fix the
problems.
Depending on the number of changes necessary to fix problems or provide
new features, the software to repair vulnerabilities and make other modifications to
code may be released in one of two forms:

■ Patch, which is also known as a hotfix, bugfix, or update.These are
released as problems are identified, and as soon as developers can write
code to eliminate or work around recognized issues. Generally, patches will
only address a single security issue or bug, and are released because the
problem should be fixed immediately (as opposed to waiting for the next
upgrade).
■ Upgrade, which is also known as a service release, version upgrade, or
service pack. Upgrades contain significant changes to the code, and may
also provide new tools, graphics, and other features. Generally, they contain
all of the previous patches that still apply to the code written in the new
version, and may contain new fixes to bugs that weren’t problematic
enough to require a patch to be released.

Product vendors usually address significant threats promptly by releasing a patch
for their products, while releasing upgrades intermittently.To maintain a secure
system, administrators must remain informed about their software and apply
patches for vulnerabilities when they become available.
However, they must consider a few caveats when working with software
patches:

■ Patches are often released quickly, in response to an immediate problem, so
they may not have been thoroughly tested.Although rare, this can result in
failed installations, crashed systems, inoperable programs, or additional
security vulnerabilities.

■ It is extremely important to test new patches on non-production systems
before deploying them throughout a network.
■ If a patch cannot be deemed safe for deployment, the administrator should
weigh the consequences of not deploying it and remaining vulnerable to
the threat against the possibility that the patch might itself cause system

www.syngress.com