High-profile media coverage over recent ransomware attacks have brought substantial attention to cyber security issues. The potential for a serious incident to undermine the viability of an organization feels higher than ever to many business leaders following the news. If high profile organizations with huge IT budgets including Sony Pictures and the UK’s National Health Service can’t deal with ransomware effectively, how can smaller teams cope? C-Level executives and board members are now faced with an unsettling question – “Could we be next?”
When discussing the potential for a cyber security incident, leaders without an IT background may feel ill equipped to assess their overall risk. Taking the word of technical staff isn’t necessarily going to assuage their fears. IT professionals’ skillsets do not necessarily include the ability to communicate effectively with senior leadership. Complex technical architecture, arcane industry jargon, defensiveness over turf, and confusion created by an ever-changing security environment can all contribute to miscommunications. This does not absolve leaders of the responsibility to understand and mitigate risks in IT. More than ever
So, what indicators can leadership teams look at to assess the health of their IT department and their readiness to deal with an incident? Here’s three suggestions on where to focus additional attention:
Patching
Patching of software should be a routine item on the IT Operations calendar. It is one of the most critical steps you can take to avoid an incident. The impact of the WannaCry malware would have been negligible had users been working on full patched and fully supported systems. Clearly this means patching isn’t being done in an effective manner in many organizations. So why doesn’t patching always occur?
First, the patch may break some other critical component. If your organization is running software that is incompatible with the patch, it may be impossible to install it without losing a critical application. This is also why most enterprise IT shops do not use “automatic updates” that deploy patches as soon as they are released. Patches need to be tested and understood before they’re deployed or the consequences could be just as bad as malware.
Second, there may be contractual obligations for hardware and software provided by a third-party vendor that prevent your team from patching the systems. These systems and their interaction with the rest of your network need to be carefully studied and well understood. For high profile organizations, they can expect that they will be the ones who take the reputation hit, not the third-party vendor.
Third, you may not have any maintenance windows available. Patching usually requires IT to take systems offline for an extended period. In some industries with a 24x7 workplace, this is difficult to get approved, especially if IT cannot effectively communicate just how big the risks of not patching are. In other industries, there may be seasonal rules on when systems can be modified that prevent patching. Retailers are very averse to making any IT changes during Q4. Any restriction that prevents patching should be carefully reviewed and understood by the leadership team.
Policies, Procedures, and Documentation
Having policies and procedures in place may strike some as mundane but it’s a good indicator of the overall health of an IT department. Many IT organizations have some challenges when it comes to keeping their documentation fully updated. If however, there’s almost no documentation, inconsistent or informal policies, and no internal procedures that should be a major red flag to leadership.
Documentation of your networks, systems, and integration points is a critical tool for maintaining your IT investments. It is also a critical resource should there be an incident, to be able to understand and isolate the damage. Without effective documentation, the knowledge trapped in the IT team’s heads will be difficult to share and could potentially be lost if a key team member is unavailable. You would not want to purchase a building without any documentation of its systems and you should feel equally as anxious if your organization relies on IT systems with no documentation.
Policies and procedures play a different role but are equally as critical. End user policies and procedures govern how systems can be utilized, set user expectations for service, and help to inform users of their shared responsibilities around reducing risks. In some cases, policies may exist but a deeper look would reveal that they aren’t being followed or enforced. Security policies are the most obvious place to look, but the processes for provisioning and de-provisioning of accounts is often more telling. Lack of consistency in this area not only creates extra work and confusion but can also create unintended risks. If there are not robust controls around how accounts are built and delivered you may have users getting inappropriate levels of access. If there aren’t constant checks to make sure accounts for users no longer at the organization are decommissioned, you may have zombie accounts that become an easy vector for malicious activity. Imagine the potential damage if an employee, terminated for cause, retained access to your systems after they’ve already left.
Backups
Backups aren’t always considered when thinking about cyber security but when dealing with ransomware, they may be the best tool available. After all, if all of your files are locked out, the easiest approach may be to simply wipe out the affected drives and restore from the last good backup. This begs the question – how good are our backups?
When it comes to backups, the most important thing to understand is what is being backed up and how often does the backup occur. Often there will be different backup schemes for different users, departments, systems, or applications. Understanding the nuances of these backups and where their limitations exist is important. Hard choices should be made here because backing up “everything” does not align with budgetary reality for most organizations and the complexity of a system that could do that would be very high.
The second piece to understand is restoration of data. Restoration is all about two different components: Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO). These are often found as part of the organization’s disaster recovery plan. RPO specifies what point in time a backup should go to – IE if we do a daily backup at midnight each night, we know what we can always restore to that last point. RTO is focused on how long the backup takes to deploy once a decision is made to restore from backup. In most cases this is not an instantaneous process so understanding the amount of additional downtime is important.
One other item that usually gets overlooked with backups is a testing plan. Backups should be routinely tested to ensure that the contents line up with what is expected and that they can be fully restored within the RTO. You want to have confidence in your backup technology and the only real way to deliver that confidence is through testing.
Conclusions
Proactive questions from leaders can highlight gaps that may have otherwise been overlooked. While these discussions may initially be uncomfortable they may also reveal governance issues with how IT decisions are being made. After all the decisions made at the IT level about what risk to accept may be very different than what the rest of the business can tolerate. Inappropriate decisions in either direction can be damaging. If risk tolerance is too high, the potential for an incident may increase. If risk tolerance is too low, the expense to operate IT may be unsustainable. Looking at patching, documentation, and backups is an easy way to start conversations and assess if there are major gaps in your IT department.
Looking for a more in depth discussion or an outside assessment? Our IT Strategy and Operations Practice focuses on the intersection of people, processes, and technology. We can provide an impartial outside look at IT and the ways in which it can better support your business. Our impactful work at organizations large and small often starts with a simple conversation. Reach out and let us know what you’re concerned about.
About Systems Alliance, Inc.
Organizations that make the best use of technology enjoy a distinct competitive advantage. Since 1993, Systems Alliance, Inc. (SAI), has been helping clients thrive by leveraging IT and Digital assets to their best advantage. SAI delivers consulting, development and product-based solutions to complex business challenges, helping their client-partners win in the marketplace.
