The security issue discovered last month with Juniper ScreenOS, (CVE-2015-7755) shatters the ageless wisdom of “if it isn’t broke, then don’t fix it.” In the wild age of cybercrime in which we live and do business, technology may still operate, but be vulnerable and this requires us to fix that which may seem to not be broken. In this specific example, the technology continued to operate just fine, albeit with a hidden vulnerability which exposed a back door through which an attacker could gain administrative access to the device and even monitor encrypted traffic.
Several concerns impacting businesses become apparent:
- The reality that an attacker can exploit a backdoor makes a strong case against requiring vendors to build in back doors for government use. If the back door is there, a criminal will find a way to exploit it as a matter of “when” and not as a matter of “if.” This is a topic for another post.
- Small businesses (and even larger ones) without regular IT or security expertise in-house often fail to keep technology patched. When things appear to be working, there would seem to be no urgent need to go to the trouble of patching. This is dangerous thinking because vendors do fix flaws and security weaknesses periodically. Failure to patch regularly leaves the business vulnerable as many attackers regularly scan for unpatched systems to attack and exploit.
- While often overlooked, some newly purchased technology can come with vulnerabilities right out of the box. The vendor may have issued an update in the time since the device was manufactured and shipped, or, a supplier may have used an outdated version in the firmware.
What should the business do?
Management is arguably easier when issues are address at the beginning of a project rather than later, once production is in place. For this reason, it should be best practice for any business to check and see if there are any updates to new hardware or software before placing the technology into production. A check of the manufacture’s website and a review of the current configuration for version numbers is frequently a straightforward and prudent task to undertake.
Once placed into production, updates and patches require greater scrutiny because there is the risk of breaking something. While regular patching is important, the activity needs a plan and a disciplined process.
- Is the patch relevant? If the business is not running a version or application to which the patch applies, then there is no reason to apply it. Read all the release notes and determine applicability. Take for example Microsoft patches. Do they apply to the version of Windows currently in production? If not, there is no need to apply the patch. Document the decision and move on.
- Test. In an ideal world, the business should have a test environment to ensure that any patches or upgrades, once applied, do not break line of business applications. In reality, this is often a luxury many small businesses do not have. Lacking a test environment, apply updates to less critical systems first and proceed to more sensitive systems.
- Have a back out plan. In many cases, updates can be reversed. To be sure, create a system restore point, or take a complete image backup so that the system can be recovered to the exact state prior to any failed upgrade.
- Communicate to all users and stakeholders, planning for expected downtime. While downtime and outages are often minimal, issues can arise and rushing the team performing updates and patches can lead to errors and mistakes. Set a realistic window to complete the work, communicate the window in advance and give the team the necessary time to execute, test, and roll back if necessary.
As a business owner or manager, does your IT team or service provider regularly patch? What process do they follow? The above suggestions are all good metrics to report and should be discussed with IT staff on a regular basis to ensure and document that the business is provocatively taking steps to protect against known exploits.