This is a series of articles that cover some basic InfoSec (information security) and OpSec (operational security) tips for private home/mobile or small business use.
I'm an IT security guy that came around quite a bit from small business settings to big corporations in FinTech and other industries.
I'm trying to cover much in - hopefully - simple words with some simple approaches, methods, processes and hands on recommendations for you to assess and maybe up your InfoSec (information security) game if you want. Please understand that I will have to be pretty generic in some parts of these articles...
...but if you got questions go ahead and drop them in the comments and I'll try to help out!
IMPORTANT! If you're insecure with some of the recommendations please hire an professional before getting into trouble with your systems and possibly blaming me for that!
A general advice! Please only "touch" (change) things/configurations that you are familiar with and that you can undo if needed!
Lastly, why do I do this? To raise awareness and to hopefully help you to raise your personal information security & data protection bar!
I will cover the following topics in this series of articles
- 190513 Assessment & general thoughts
- 190514 Passwords
- This article here! Prerequisites for secure patching of systems
- Data protection
- "Right sized" processes for Risk management/InfoSec/OpSec
A quick recap of points we touched in previous articles...
In this article I’ve suggested that you make an assessment of your internet connected devices or better of all devices in your own network including mobile devices! This includes collecting information on serviceability of these devices.
This is the groundwork for the next steps.
The Password article touched on some general aspects of password handling like defining an password policy and the use of some help by using password managers.
Prerequisites for secure patching of systems...
Please keep in mind to update your system list that we handled in Assessment with all the additional information that we gather with the next steps!
So, we’re still collecting all information that will help us to set up our own risk management and information security management in our own environment while trying to right size this to your specific needs.
Our little assessment list gets a little more valuable with every information we add in here. We're still pretty far away from something called a CMDB (configuration management data base; like the name says a database holding all configuration information for managing an IT environment) but it's a start and our list could evolve to this if we chose so.
I'll place some of the relevant concepts and frameworks in here because all of what we are touching here is of course part of such frameworks. This makes sense IMO for those who want to learn some background and more in depth methods, processes that are "battle proven" for IT operations. They might seem a little overkill for what we are doing here, and this might be true for a little hands on upping your information security game, but non the less they might be of interest for those of you who want to expand their IT service management approach a little.
ITIL is a set of detailed practices for ITSM (IT service management).
At this stage in this little article series you should
- have an rough idea what you’re environment looks like and
- you know how and when to change your passwords and
- that your probably better off thinking about using a password managing solution.
- You should also have begun collecting the relevant information on how to service (patch) your devices.
If you can check off theses points you’re almost set to start security patching.
But only almost...
The most important thing that is overlooked pretty often - this goes for small to medium businesses as well as home settings and even big operations screw this up at times - is investing some time and thought into what to do if things go wrong.
It's really essential to know your general handling methods and processes and more specifically have data and system backup & recovery handy!
With that I mean not only have some kind of data/system backup in place but to know what to do if you want to recover data or even a complete system.
One general rule for you should be...
Before we execute any kind of change to/on a system we make sure that we can rollback the changes or replace the system or service, if the change we introduce is faulty or in any way impacting the system.
Why? If things get ugly, for instance issues with a faulty patch or disrupted update, you want to still be able to access your data and that was stored on a system that was "downed" and a complete system recovery should be possible as well if this system was of any merit to you.
The not being prepared scenario is one of the most common I was confronted with in my over 35 years in IT. I had countless firefighting assignments were the good intentions of some end user, IT person or complete IT department for that matter went south to the level of disaster.
So, a little security patching can become absolutely disastrous very quickly!
Knowing what to do if misfortune strikes is key!
In some cases this will not be possible in a simple manner for all systems. Sometimes a rollback by replacing new patch/version with an older version is very complex and has to be carefully weighed and executed. It might even happen that you even need to reinstall the complete system with all apps to get to where you were before things went bad or the recovery path excludes configuration specifics of the system in trouble and so on.
A thorough understanding of back & recovery possibilities for each system is important and should be tested before you run into issues with a productive system or app.
"I don't believe in pressure. The pressure is not being prepared for what you want to do."
Either way, patches sometimes are faulty or your update gets disrupted by a power outage that renders the system unusable or you mess up in some other way and your left with an inoperative system.
So thinking about, selecting and testing a working backup and recovery method beforehand is essential if you don't want to take chances.
Frankly, doing backup and recovery right is no simple task and if done wrong you possibly spent time and maybe money to make things worse even.
You also should work with prioritizing your systems to weigh risk vs. time and money for a "fool proof" recovery method.
You might not need backup & recovery for certain systems if their priority is low and you can dispense with a longer outage/downtime of these systems and apps.
So what do you do?
In a business setting - given that you haven't already got all your IT operations including ITSM (IT service management) ducks in a row - you would perform BCM (Business Continuity Planning) of which a BIA (Business Impact Analysis) is part of!
In a BIA you define the following:
- RPO = Recovery Point Objective = the acceptable data loss. For example, is it acceptable to lose 7 days of data (if you only have a weekly backup for instance and for example the worst case scenario... an issue occures after 6 days, 23 hours, 59 minutes and 59 seconds? The recovery point objective defines what the maximum tolerable data loss for each system/service is.
- RTO = Recovery Time Objective = the acceptable amount of time to restore the function.
Looks like getting this done would give us the specific need for our purpose!
1 Mobile Phone 1: RPO: 15 days, RTO: 5 days 2 Printer 1: RPO: n/a, RTO: 2 days 3 Desktop computer 1: RPO: 7 days, RTO: 1 day 4 Server computer 1:RTO: 0 hours, RTO: 1 hour.
Now our preventive measures must reflect these BIA results.
Server computer 1
System needs continuous backup solution or might even need a mirroring or a least a so called near line replication or a standby system that can be put into service ad hoc if the time frame of the RTO 1 hour can be held with doing this. A simple backup/recovery method won't fit the need!
Desktop computer 1
Should be covered by a standard weekly backup if the time needed to recovery does not exceed 1 day.
Mobile phone 1:
Has a relatively low priority and the data on it, for instance only address book, can be as old as 15 days and with a RTO of 5 days you probably would even be able to cover this even if you had to go to the next mobile shop and buy a new one.
No data recovery needed but must run again after 2 days
I guess you get the picture, right?
Of course you can tone it down a bit if you need too but to have some idea what priority a system has to you should exist in your mind and if so put it into the list!
To complete the picture we can pitch in risk management!
Some IT risk management will help to make choices in regard to selecting the right sized preventive measures.
We'll pick up on this in the next post in this series!
At last here our updated list...
As I wrote before your questions and suggestions are very welcome!
Please drop a comment if you like!
Gif from my friend @smilinglllama!