Executive Summary
This is part 3 of my weekend series on IT cyber security program basics. In my last blog post, we discussed establishing and information security program (ISM), patch management, change control and Firewalls. Today, I am going to focus on securing wireless networks and systems backups/disaster recovery.
I am also behind in my weekend cyber security program basics. I thought I would be able to post weekly, but my schedule did not allow for it. I finally have additional time and I will be completing this series shortly.
Securing Wireless Networks
Wireless Technology has greatly improved from when it was first released in the nineties. Not only has the speed improved, security has also improved. Wireless, when misconfigured allows for someone to easily compromise your network.
If you have sensitive information on your network, your wireless should be at least WPA2 enterprise with certificates. WPA2 enterprise will require some sort of authentication server to validate that you are authorized to access the wireless network. You can also base that authentication on a PKI certificate. This makes it much more difficult to compromise the wireless network. If you leverage a pre-share key (which I don't recommend), make sure it is over 16 character's and is changed often. If possible, don't give it out. Pre-shared keys have been easy to compromise over the years with various attacks and hacks against them. While I feel they work great for some purposes, they should be avoided if possbile in an enterprise.
If your wireless access points have roque access point detection, enable it. This will allow the access points to prevent roque access points from broadcasting.
You should also place access points on a separate network segment or VLAN from all other network devices. This will allow for the ability to easily identify wireless devices. It will also allow for the ability to filter and restrict traffic on that segment if necessary.
Finally, offer a guest SSID that is on separate isolated network segment that only allows access to the Internet and nothing else. Do not create a separate SSID, call it guest only to place it on the same network as your production SSID. All you have done by doing this is creating the illusion that you have a separate guest network, when you don't. I have seen two instances of this recently, don't make this rookie mistake.
Backups and Disaster Recovery
One of the early lessons I learned was to make sure that you have a good backup copy of your data. Backups and disaster recovery (DR) is key to recovery from a cybersecurity event such as ransomware or a compromised machine.
Your backup system should isolate your backup data from the production network. Most modern backup systems are disk based. If you are just attaching a disk to Windows or Linux machine and you are not restricting rights, a good chance exists that it will be vulnerable to a ransomware attack. Make sure your disk-based backups are isolated from the production network and are immutable and encrypted. Most modern backup appliances have safety features built-in that prevent backups from being deleted before a retention timeout or require two administrators to delete the backups. You should enable this feature if possible.
You should replicate your backups offsite, and you should have some sort of retention policy on how many recovery points you are keeping offsite. This will allow for the ability to recover data if your primary location is destroyed by some sort of disaster. It will also protect against the ransomware attacker who discovers your backup password and decides to delete your backups on your primary backup copy.
Your backup appliances should be configured to leverage a directory service for administrative access. The built-in in Administrator should be disabled or setup with a long-complicated password that is stored in a vault. You will only use this account for emergency purposes. You should also secure your administrative accounts with multi-factor authentication.
Most backup systems have some sort of firmware/software updates. Make sure you are staying on the recommend software/firmware release for your system.
You should also test your backup systems at least quarterly to ensure you can recover data. Most backup systems can recover virtual machines these days, I highly recommend that your test recovering virtual machines. This will make sure the backup system is functional and give your experience recovering data. You should also test recovering just general backup data. Finally, it will help better prepare you if a disaster exists.
A disaster recovery (DR) plan is something that everyone should have. The DR plan will define recovery time objective (RTO), and recovery point objective (RPO). RTO will define how quickly it will take to recover. If you want a system up and running with-in an hour of declaring a disaster, you might need to look at having data or a system replicated. RPO defines the point in time you want to recover from. Defining these objectives will help you develop your plan and identify gaps you might have with your current solution or plan. It will also help prioritize which systems should be recovered first. Once you have a DR plan, makes sure you are testing that plan. Much more goes into a DR plan and I plan on discussing that in blog post later this year.
Final Thoughts
Wireless networks are never 100% secure, but you can take simple steps to make them very secure. Just don't be the fool who thinks having a guest network in name only makes you more secure.
Make sure you have hardened your backup system against ransomware. Don't be the fool who has the backup system encrypted along with your production systems. If possible, enable MFA on your backup appliances. This will prevent the attacker with compromised credentials from deleting your backups. Make sure you have some sort of plan to get your backups offsite.
Develop a DR plan and test that plan.
I hope you find the blog post useful. As Ben Franklin said, “An ounce of prevention is worth a pound of cure".