Computer Security — 2
There is almost no way a single person can keep pace with security exploits and patching. Fortunately there is no need for that.
A significant number of exploits require some kind of physical access to systems. That means remembering to breath when security patch notices arrive in the email box. The click-bait headline mentality of upgrade now! is nonsense.
Only occasionally do exploits apply across the board. When that happens there will be ample news coverage from worthy news sources that do not include the “Upgrade now!” click-bait dweebs. These types of patches should be investigated and installed in a timely manner. Do not get excited like rabbits copulating.
An example is a couple of summers ago the GRUB boothole exploit was patched. Many package maintainers jumped on the publicity bandwagon to push patches. The problem is the patches were not well tested. After patching many people discovered they could not boot their systems. The sad part is the exploit required physical access to gain advantage. There was no need to rush and play the publicity game.
While budgets play a role, most admins should strive to create some test systems. This is the preferable first place to test patches.
Another strategy is to roll out patches in a methodical manner. Never update all systems all at once. Roll out patches a little at a time, monitor system logs, and listen for user comments.
Live patching of kernels is a nice idea but pushes against existing pragmatic strategies and practices. If a patch causes problems then a reboot often reveals problems immediately. Not rebooting tends to hide and mask root causes. When a system is rebooted months down the road and problems arise immediately, which patch is the culprit?
Like other security patches, many kernel patches are security theater. The exploits are real but most are impossible without physical access to systems.
Much of what a basic admin reads about patching practices are written by big enterprise folks where systems often are treated like “cattle” rather than “pets.” For many admins in small and medium size businesses, many to most systems are pets. These systems cannot be rebuilt easily like “cattle” systems. Prudence and testing is required before patching systems.
Backups are important but more important is testing the backups. Many admins have discovered to their dismay that backups were worthless when disaster hit. Testing restorations should be a regular task and test systems help much in that approach.
Basic sane and well tested security practices avoid much of the click-bait frenzy with patches. Physically control access, minimize open ports, do not install or activate unnecessary services, use the principle of least privilege to control access, use SSH key pairs rather than passwords, etc. Observing such practices reduces urgency with patching systems.
How to keep systems patched is mostly a discussion about scale. For many admins in small to medium size business there is no meaningful scale. This is especially true for home users. That does not mean avoid learning helpful tools, only that at small scale managing patches should not cause loss of sleep.
Security and patching is much like ogres and onions — they come in layers.
Posted: Category: Tutorial Tagged: General
Next: Common Commands for Beginners
Previous: Computer Security — 1