While it may seem like common sense to those of you more seasoned in security, updates for your distribution are released for a reason. In some cases, updates serve only to add new features or update software to the latest version. But in the case of Enterprise distributions such as CentOS and Debian, these are even more important.
This is one of the ways consumer-based distributions and Enterprise distributions differ. Distributions such as Ubuntu's non-LTS releases, Linux Mint, and Fedora receive more bleeding-edge packages than Enterprise distributions such as CentOS, Debian, and Red Hat. This is because the end user typically wants the latest versions of their web browser, e-mail client, word processor, or games. This doesn't matter much when it comes to the Enterprise. In the Enterprise, security updates are critical. While consumer-oriented distributions surely keep up to date with security patches on almost an equal level in most cases, these are intermixed with feature updates that may impair stability more than help it.
In the case of Debian, both styles are actually offered. The main distribution, which is known as Debian stable, receives little more than security patches. Even the default web browser (Iceweasel) isn't updated as often as Firefox would be on other platforms. The idea here is that change represents potential breakage. Quite a bit of work goes into ensuring that the packages you get in stable are tried and true, rather than the latest and greatest. This concept is similar to CentOS as well, though its packages generally tend to be older than those in Debian. To give you an idea of this, at the time of my writing this chapter, the latest Linux kernel is 4.1. Debian Jessie (the latest "Stable") includes kernel 3.16, while CentOS 7 is even older at 3.10. Not that there's nothing wrong with the kernel being old, I just mentioned it to give you an example. Both Red Hat and Debian have more bleeding-edge distributions available. Fedora is sponsored by Red Hat and includes more up to date packages. It's geared toward users who prefer to have the latest software. Debian testing also includes more up to date packages, though it's not nearly as stable as Fedora, facing package breakages from time to time. Debian testing is targeted toward those who would like to test the next release of Debian, as Debian testing eventually becomes the new Debian stable as it matures.
For security purposes, installing the latest security updates is critical. It's true that Linux is more secure and stable than many other platforms, but regardless of how secure the operating system is, at the end of the day, it's only as secure as how it's managed. An installation of a Linux distribution that's behind in updates is a sitting duck in the case of an exploitable vulnerability being discovered.
Given the existence of end-user and Enterprise distributions, managing their security updates can be a challenge. If your organization uses Linux on both servers as well as end-user machines, you may very well employ both types of distributions. This is because while CentOS is secure and stable, you're unlikely to be successful deploying it to end-user machines. Since the CentOS kernel is a bit older, it won't support all the new hardware that's available for end-user workstations today. In addition, there aren't as many customizations in place to make it reasonable for desktop or laptop use. While it can be done (and many people do), installing CentOS on an end-user device is typically an exercise in frustration. For end-user machines, you might opt for Ubuntu, Linux Mint, or Fedora instead. But with those, you would need to spend more time focusing on which updates are for security and which updates are for new features in applications. Depending on the nature of the update, you may choose to roll it out differently.
Ideally, in a perfect server room, all updates for servers would be installed immediately upon their release, there would never be any issues and everything would always go smooth. But in reality, there are challenges in keeping security updates current. Perhaps a regression may be present that stops an important application from running. Alternatively, perhaps an error in packaging actually breaks the RPM database (which is an extremely frustrating experience!), so while updates are important, some exercise in caution is needed as well.
The best policy, or at least one I've found that works well for me, is creating testing servers that can be used to test changes before you roll them out into production. In the case of virtual machine servers, you can even clone production servers and test updates or other changes on them to see how they will react if they were rolled out into production. Then, you can be reasonably confident that new updates won't break production servers. To be fair, these types of situations rarely happen. But given the flexibility of Linux and the fact that Linux servers are easy to clone, there's no reason not to do testing.
In CentOS systems, you can use the yum update command to update all the packages on your server. You can use yum update along with the name of a package to update just that package. In Debian systems, you can use apt-get update to refresh your sources, and then you can use apt-get install with a package name to update a package. To update everything, you would update your sources and then run apt-get dist-upgrade.
In real-world installations, you would probably not update all available packages on your server. Instead, one method is to update packages as needed. This requires a great deal of research on the part of the administrator, in order to pay attention to current security trends and then pick the security updates that impact services that are currently being used in production. For Debian and Red Hat based systems, there are two handy web sites pertaining to Common Vulnerabilities and Exposures (CVE) that you should have bookmarked.
For Red Hat use the following URL:
https://access.redhat.com/security/cve/
For Debian use the following URL:
https://security-tracker.debian.org/tracker
Both sites allow you to view individual CVE reports, which will inform you about vulnerable packages and whether or not they were patched. In some cases, a CVE may not even be exploitable in your particular distribution, in which case you wouldn't need to do anything. But by following these reports, you can make an informed decision regarding what potential vulnerabilities may affect your organization. This will allow you to create a plan to roll out the necessary patches onto your servers.