The Ransomware Problem, Part 2: Getting Real about Expectations

In the previous post, we took a hard look at why cybersecurity attacks are often successful. Here, we’ll use those findings to determine what healthcare IT and security leaders can do to more effectively safeguard data.

Set the right example. The most critical message you can deliver is that cutting corners isn’t acceptable, even if it means delaying something that might be considered critical. And this expectation must come from the top. It needs to be backed up with actions and continual follow-up.

Two-way communication is a must. Don’t be like certain Silicon Valley entrepreneurs who use an open-door policy as a way of firing people who they feel are out of line, when in reality, they’re trying to bring light to issues. Cutting corners is not to be tolerated, and the security standards of the organization must be met. They are standards, not something people can beg out of because a project needs to get done.

It’s important to bring in a strong security leader with experience in risk assessment and strong communication skills. Let them do their job and perform a strong quantitative assessment of the organization. Don’t remove systems because they are out of scope for your regulatory requirements such as HIPAA or PCI. Don’t handicap them by trying to control their every move. Experience has shown that those “out of scope” systems will end up back in scope as soon you do an assessment.

There will be gaps or items that they find. Let them address those items. Don’t try to bury them. Your technical team already knows about them — so will a Ransomware attacker. Develop plans to address the top 20 percent of identified risks within the first two years. Focusing on the 20 percent will address many root causes of the other 80 percent. Anything critical must be addressed immediately; even if there are stopgap measures. Use these findings in your strategic planning.

Set the right expectations for deliverables. Make sure that projects, initiatives, and capital projects have the following components identified and addressed:

• Key stakeholders identified
• Realistic project plans vetted by stakeholders and customers
• Realistic contract language that meets security standards
• Communication plans that give customers a chance to be heard and voice their concerns. (If there is one area where IS can improve, it starts here.)
• Updated policies that meet use cases and needs, especially if they involve any type of penalties for team members
• Realistic staffing plans that meet customer requirements and don’t make assumptions that IT has enough resources to handle them
• Downtime procedures for what happens when the system is not available (as required by the Joint Commission)
• Security plans that address whole system protection, not just endpoints
• Procedures and processes for daily operations vetted by key stakeholders
• Vulnerability management and patching processes that have been vetted
• No exceptions that add risk to the organization (this includes encryption, default passwords, firewall holes, and remote support exceptions)
• Defined management processes for the system, including remote management
• Defined processes for performing security reviews and audits of accounts
• Defined processes for handling exceptions and addressing anomalies in the system
• Defined processes for handling privacy issues

Stop the “product first” approach. No insult to the companies that sell security products, and especially my friends there. Telling customers that you have a solution for every problem leads them to practice risk avoidance by buying products that may or may not work. I’ve heard “but we have X and can solve for X” too many times in my career. Leaders need to stop anyone that says that and ask for the plan and above deliverables. We’ve been conditioned that computer systems are like air conditioners or refrigerators; our systems are much more complex, and can’t be fixed by using a different brand of refrigerant or belts.

Many security product marketers need to accept the reality that buying their product isn’t going to save a company from dedicated attackers, and that their claims of a panacea have caused management to short-circuit and not critically evaluate risks. Too many times in my career I’ve heard, “but we bought X to address Y. Why didn’t it work? Why did we get hacked?” The current marketing places too much trust in tools, and not enough in management processes that exist to mitigate risk. For the good companies out there, the message is drowned out by snake oil.

Stop putting in products or processes because someone else did it at a big system. Mimicry leads to failure. One of the challenges we have in healthcare is the number of managers who think because a larger organization implements a particular system or process, it will work for them. We have had to field a number of phone calls and requests because customers implement these systems without thinking of the project or staffing plans. These large health systems have staffing and funding beyond that of many organizations. Emulating without understanding leads to non-working systems and processes.

Instead, collaborate with peer organizations in your area. In healthcare, when there is a disaster and organizations need help with basic operations, mutual aid can be invoked to share resources. Cyberattacks threaten all businesses. While before there may have been apprehension in speaking with the competition, now it’s necessary to ensure mutual survival. Sharing information through initiatives like Healthcare ISAC, or informally through local groups, can help identify issues and solutions.

Risk management is continual. Set the expectation from the top that there will be annual risk assessments, security plan updates, and continual plan execution. Also, set the expectation that there will be continual following up. This is not something you do once. And, in the words of a former manager, “get security done.”

Ransomware criminals take advantage of gaps in process and monitoring, as well as shortcuts. They attack organizations dependent upon critical systems and processes that are configured for convenience, not for security. They know that many organizations don’t collaboration. They know where to attack and how. They go after organizations they know they will likely pay because of the reconnaissance work they have done. Most importantly, they attack organizations that don’t stand together. Set the right expectations, collaborate, and work toward plans to assess and address your risks. By sending a message from the top, setting the right expectations, and establishing good standards, it puts us all in a better place to address technology risks and improve technical management.