Ransomware: When Policy Matters Most
Most CISOs divide their approach to cyber defense into three pillars: people, technology, and processes. These pillars define a cybersecurity program’s defensive architecture and arsenal, available assets, and policies and procedures that together inform critical processes.
Ransomware crystalizes the value of this pillared approach, and in particular, points to the necessity for a focus on policy.
CISOs value the people who comprise and support critical programs. Any component of a program that isn’t automated relies on personnel to develop, configure, operate, and maintain it. Any automated component achieves a state of confidence only because personnel test and confirm that steady state.
“Processes inform a cybersecurity team about how to get things done as well as indisputable clarity on the organization’s expectations.”
People form the core of every successful cybersecurity program. Quality cybersecurity professionals are hard to find and retain, and modern CISOs therefore emphasize recruiting and retention as a key objective for their cybersecurity programs.
CISOs also value the technology that we deploy to protect and defend our organization’s assets, information, and operations. In simple terms, CISOs can’t deliver on the expectations set by organizations without technology that is current, useable, designed and devoted to the cybersecurity mission. Technology must be properly configured and maintained, but first those technical parts and pieces must be procured—as a product or service—and deployed.
Most CISOs have a significant collection of technology with specific cybersecurity tasks: secure the organization’s network or endpoints, protect data, observe, collect, and detect potential indicators. The list of available technology is growing, and CISOs’ choices are only constrained by budgets and detailed design conflicts.
Processes and Policy
The third pillar, processes, is the one that is typically deemphasized, or worse, sometimes entirely neglected.
Processes include how a cybersecurity organization operates, its procedures and policies, and finally standards and guidelines. Processes inform a cybersecurity team about how to get things done as well as indisputable clarity on the organization’s expectations.
“Policy, by comparison, is the place where an organization exhibits its rules for all cybersecurity engagement. Policy lies at the nexus of procedure and culture.”
To begin, processes define an organization’s behavioral expectations; not just how an organization operates, but why it operates that way. They are documented rules of behavior. Policy, by comparison, is the place where an organization exhibits its rules for all cybersecurity engagement. Policy lies at the nexus of procedure and culture. What are an organization’s compliance considerations? What are approved behaviors for activity monitoring, log collection, and behavioral observation? What are the limits of the organization’s risk tolerance?
Most policy is established outside of the CISO’s organization. Policy—with a capital P—is owned by the broader organization and fostered by the organization’s leadership. Policy at this level can define an organization, and so it makes sense that the most senior level of an organization must approve it. Most organizations have a limited number of policies at this level, because each of them matters so much. A subset of these policies may even require approval and stewardship by an organization’s board of directors.
Ransomware and Its Impact on Processes and Policy
As the unprecedented risk of ransomware continues to pervade every business, CISOs have redoubled their efforts to attract and train ever more capable cybersecurity teams. They have also identified gaps in their technology set and filled in as many of those gaps as possible, to detect and react to ransomware attempts early and comprehensively.
While people and technology try to mitigate the risk or impact of ransomware, policy development or redevelopment for ransomware tends to lag. Some organizations have no particular ransomware policy at all. Others have a basic policy that may fail to serve the organization when it is pressed to make critical ransomware-related decisions.
“It’s not sufficient for most organizations to stipulate that, if confronted with a successful ransomware attack, they will or won’t pay.”
These decisions aren’t easy, and each option needs to be informed by a clear understanding of its implications. A smart organization, for example, contemplates the ransomware scenarios it may someday face, long before the first evidence of an actual attack. The organization then articulates and adopts policy that guides its response to each scenario. If organizations haven’t done so already, they should develop or redevelop ransomware policy right now.
Ransomware scenarios appear, on the surface, fairly binary: pay or don’t pay.
It’s not sufficient for most organizations to stipulate that, if confronted with a successful ransomware attack, they will or won’t pay. While some organizations may have a blanket “never pay” policy, there are still details or conditions they should consider: the size of the ransomware demand, the organization’s ability to respond with mitigations, recalls, and restores, and the organization’s culture and mission. More on this in a moment.
By contrast, for an organization to adopt an “always pay” policy in all ransomware cases, it must assume worst-case scenarios in which the ransom demand may exceed the organization’s ability to pay. More reasonably, an organization’s policy to pay would need to be capped at some amount so that the organization could actually afford to pay. Otherwise, you have an untenable policy.
An organization with an “always pay” policy arguably doesn’t have much confidence in its organization’s—or its CISO’s—ability to weather a successful ransomware attack. Could an organization recall and restore all its data and systems? Are there viable, tested backups that could serve as trustworthy replicas of the production environment? Are the backup, recall, and restore processes themselves reliable? An organization that has an “always pay” policy doesn’t have much faith in its ability to withstand the storm. If it had any faith, then its policy wouldn’t be to always pay, but instead to pay in certain conditions and not to pay in other conditions.
The reliability of the ransomware attackers and the financial structure behind them matters, too. Would an “always pay” policy make sense if cryptocurrency intermediaries assess the attackers are unreliable and that, even if they get paid, they may not release some or any of the ransomed assets? What if the criminal was simply inept, very good at encrypting things, but not very good at decrypting them? What would an organization do if it paid the ransom but was unable to get whole after? That is a bridge no organization wants to cross.
“An organization with an ‘always pay’ policy arguably doesn’t have much confidence in its organization’s—or its CISO’s—ability to weather a successful ransomware attack.”
More recently, we’ve seen a hybrid kind of ransomware attack, which combines asset encryption (data and systems) and possible data exfiltration (a copy of the organization’s data has been stolen). An organization’s ransomware policy becomes much more complicated in this scenario. Would it be okay to “always pay” to receive a decryption key for an organization’s data even if a copy of that data was already available on the dark web?
An alternative to an “always pay” policy is a “never pay” policy. Such a policy can be equally challenging to abide. There are well-publicized examples of ransomware victims that flatly refused to pay a ransom under any conditions. Such a policy position places enormous faith in an organization’s ability to restore to a workable production state in all cases; that is, regardless of what data and systems have been encrypted, what operations have been disrupted, or what degree of impact severity the organization experiences, it will not pay any amount to recover, but instead, will in all cases rely on its backup/recall/restore processes to get whole.
While a “never pay” policy may align with an organization’s culture, the inherent pain caused by unknowns in the recovery process likely can’t be calculated in advance. Thus, an organization with a “never pay” policy says that, regardless of surprises in backup processes, regardless of failures in recalls and restores, regardless of any eventuality other than success, the organization is willing to accept every potential outcome.
A “never pay” policy also assumes that an organization is prepared to weather a different kind of storm—potentially of its own making. Processes don’t always work as expected, technology fails more often than any of us plan for, and people under stress sometimes make mistakes. Establishing a “never pay” policy means that an organization is willing to accept surprises, detours, and failures of every kind along the way to a state of recovery that may not satisfy the organization’s needs.
There are happy mediums, of course, including policies that are neither so loose that they are unworkable nor so tight as to restrict granular considerations for “what-ifs.” An organization may decide to pay up to a specific, previously defined amount, or it may decide to never pay unless the potential impact, as projected or calculated, is more than an organization can reasonably bear.
“A ‘never pay’ policy also assumes that an organization is prepared to weather a different kind of storm—potentially of its own making.”
The critical path for an organization’s ransomware policy discussion runs right through the boardroom. No two organizations are the same, and generic policy should be filtered out early in that discussion. Every organization should decide what matters most, appreciating that often organizational imperatives conflict with organizational culture.
It’s crucial that every organization establish and understand its position on ransomware. It is equally critical that organizations establish and understand this position before an attack, not in the heat of a fire but before the flames starts.
Carl Timmons was given 24 hours to decide what he wanted to do. This was a tactic. Twenty four hours to sit alone and think about all the money he could want and the price he’d pay for it. And 24 hours to also contemplate what Andre Savin might do to him before...
Andre Savin and Lincoln Palmer had met on several occasions and had the type of relationship you’d expect between two men of their standings on the billionaire scale. Contemptuous but also understanding. They were both driven by the same desire—access to...
Belfast, New York - 1889 They called him The Boston Strong Boy—arguably the first real boxing star and one of the highest paid athletes of his time. He’d always been good at school. He attended Boston College where his parents thought he might pursue...
About three minutes into planning this post, I had one of those “god, I am old” moments. Here is why I had the moment. I have worked in cybersecurity since 1994. My first job was at a big 3 working for the U.S. government through one of the world’s...
Account takeover fraud may sound like a familiar term in cybersecurity, yet its prevention methods in the e-commerce domain are still nuanced. Retailers are historically concerned with payment fraud systems related to chargebacks. This happens when a customer makes a...
Kuwait, 1990 I’m launched out of a submarine a few miles off the coast of Kuwait City. When I swim to shore, I quickly change into my dry land clothes—a full burka. I was a six-foot-one Marine posing as a good Muslim woman. The catch, beneath the modest...
The cyber security marketplace is hot. Ask any candidate for a cybersecurity role. Better yet, ask any supplier to CISOs. The supplier audience is especially vast, and it’s continuing to grow. Just three years ago, there were estimated to be less than 2,000...
Automated measuring of control effectiveness is a very good idea conceptually. When you can combine control gaps with relevant threat information, you get a very good picture about the actual technical cyber risks your business faces. If done correctly, it provides...
Keith and I left the scene like we found it: the two kidnappers dead on the floor, their shotgun up against the wall, and the rope used to tie up Carl Timmons sprawled out on the floor. We tipped off local law enforcement and were gone before they arrived, leaving no...
An increasing complexity of technologies, as well as an increasing number of failures and attacks followed by an increasing dependency on business goals is changing the way we run Security Operations Centers. I previously discussed the concept of a Fusion Center as an...
Until recently, cyber awareness metrics have been treated by many as a tick-box exercise driven by regulations. The regulator requires x number of hours of cyber awareness training per employee per year, and once that is done, the organisation ticks a box and waits...
The cyber risks we face today are more than we faced previously but also fundamentally different in several respects. Our adversaries are more adept and their tools and tactics more protean in capability. In light of these increasing challenges, our cyber defenses...
In our final installment, we are going to discuss how you roll all the concepts previously covered into a plan of action. The difference between the success and failure of a data classification program is a lack of action. I have reviewed over 10 programs in my...
Cyprus ~ 2006 Ali Hassan was a low-level operative in Hezbollah, but we had it on solid authority that he knew where three high-level leaders of the terrorist organization were hiding. Keith arrived fifty-seven hours into Hassan’s interrogation and by the looks of it,...
Previously, we discussed the requirements of a mature data classification program. In this post, we are going to review the administrative mechanics of such a program. Data classification, you’ll recall, usually includes a three- or four-layer system akin to the...