5 enterprise patch management best practices for small companies

We all know that we should patch every computer, server, iPhone, operating system, and switch which connects to our enterprise network. With over 30 million small businesses in the U.S., more of us work in small IT shops versus larger ones. If it is only you and a colleague or two who are responsible for keeping everything patched for your organization, you definitely need an efficient plan. Patching everything within 30 days of a patch release is just not possible. It is also not the most exciting part of our work. Unless measured and explained carefully, it is difficult to demonstrate the return on investment to executives who would prefer your time be invested in revenue supporting projects. Here are five (5) tips to ensure your patch management program runs smoothly with the right return on investment for your small organization.

1 - Know your inventory

Document and maintain your inventory of physical devices, virtual systems and applications which need to be maintained. You might have a system like ServiceNow or Cherwell. You might have a Microsoft Excel spreadsheet. The key is to have a single source of truth and to maintain it as a team. As soon as it is out of date, you will miss patching something. Reconcile it regularly. The inventory should include:

• Physical computers

• Virtual computers (static and base system images)

• Mobile devices such as iPhones and iPads

• Physical and virtual servers

• Network and telecom - switches, firewalls, etc

• Applications - on prem and cloud

You get the idea. You need to know about everything.

2 - Document vendor patch and upgrade release schedules

I sometimes see teams set their schedules without consideration of the vendor release schedules. This is backwards. If you push hard enough, you can get from your Avaya support contact, for example, that the next firmware release for the on prem telephone system is due out in Q3 of a certain year. As a small team, unless there are security concerns, I recommend waiting at least six months after a release to allow issues to emerge and be resolved. Small teams do not have the resources to troubleshoot with vendors. For a Q3 release, I would recommend a Q1 or Q2 upgrade the following year.

Some vendors, such as Microsoft, have regular release schedules. These can be planned on a recurring basis. Other vendors such as Apple require you to join a special program to see the coming releases. If you have enough users, it is worth your time to join these programs and get access to these early releases.

3 - Create your standard patching schedule (standard change)

I am going to say something that goes against what many security people follow and if I had a large team, I would not recommend this. Small teams do not have the time or resources to patch as software is released; we cannot patch everything within 30 days. Create a realistic patching schedule based on your availability and your test users ability to work with you. Again, this is for patching and upgrades, not configuration changes. In general:

• Operating systems - monthly - We all know this is where so many bad actors take advantage of vulnerabilities. There are plenty of systems to automate the distribution of this software. If we stay on top of it, the burden is not heavy.

• Applications - annual - Unless there is a security concern or a project including the upgrade of the software, place all applications on an annual patch and upgrade cycle. One or two critical applications may have monthly, agile improvements because they are business critical but normal applications in small companies can usually wait.

• Network and telecom equipment - annual - Again, unless there is a security concern, especially at the edge, annually should be good enough.

You will need to discuss with your customers and partners. Only you all know your business. The idea though is in a small company, we cannot spend half our time patching and maintaining applications and systems. The leaders need us investing time in projects which support the business.

4 - Create the emergency patch threshold and process (emergency change)

Emergency patches will need to be applied. Security patches are released regularly to address serious issues. Have the discussion now as a team about the threshold of what constitutes the need to apply an emergency patch. Many teams use external resources to watch the threat level and only respond to those which have reached orange and red levels. Regardless of your team’s decision, have the discussion now and document the decisions. The next security related release will come out tomorrow, you know it. Someone needs to review it against the decision the team made and determine what to do. You all need to be comfortable with the decisions made.

Side note - Be sure to document in your ticketing system the review of the security patch release and the decision to apply or not apply the patch. If something happens and the decision was made based on the written decision matrix to not apply the patch, most cyber insurance will still cover your organization if you can show that you did your due diligence. Documentation is always the key.

5 - Develop and maintain relationships with test users and change champions

Technology people have been pretty comfortable until now with these steps. It gets a little challenging for my introverted, nerdy friends right about here. The step where we seem to hesitate is testing the patch. As technical people, we want to put the patch or upgrade into the test environment, randomly test things ourselves or with a friend and call it done. We inevitably miss testing something, do not communicate the changes well; something just goes wrong. We need testers and change champions who use the systems every day and who are not technical people. Here is how to make the entire patch and update successful:

• Develop a relationship - Have virtual coffee, get to know the name of their dog, all that stuff we do not always do naturally as technical people but need to do so we can easily communicate.

• Agree on the plan for the year - Take the one or more line items from step three and make sure it is going to work for the test and change champion, for the group they represent. What if you scheduled the financial software annual upgrade right when the auditors are usually on site? Not good.

• Write out a simple test plan - This is a checklist they will follow to “test” the patch. Do not make this some huge multi-page document. This is about 7 things that are really important that is critical to the tester’s business that might break based on the change. They should be able to test the patch in 30 min. If it is a major upgrade, it should be a project and this does not apply. This is just a patch or minor update. This should not be huge. Maybe the tester wants to make it 10 things and 45 min but everyone is busy. Do not make this a 4 hour thing.

• Communicate frequently - If they only hear from you once a year, this is not a relationship. Let this person hear from you regularly throughout the year. I bet they send in a ticket every now and then. In the virtual world, it is not hard to send a chat with a funny GIF. You could email a link to an article that made you think of them. Remember to communicate at least once a quarter so you do not have to remind them who you are when it is time for the annual update.

You will only have 20-30 testers and change champions even in a medium sized organization. Treat them well. They can really help you test, communicate and ensure your updates actually work.

Steps one through four seem pretty obvious. In order to patch and update systems you need to know what you have and create a schedule to complete the work. Step five is the secret sauce. Having testers and change champions really makes all the differences. Just a few key people to help ensure things are working before you put them into production and to help ensure our communications are clear and targeted makes all the difference.

Carve out some time in the coming weeks to review your patch management plan. You might be surprised by the systems that are missing from your master schedule and pleasantly surprised that you may already have testing and change champions in place. Happy patching!