Containing ransomware outbreaks now a top infosec priority
A comprehensive collection of articles, videos and more, hand-picked by our editors
With recent events, like the WannaCry and NotPetya ransomware outbreaks, most organizations are fully alert to...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
the threat of ransomware. They may have invested significant time and energy in response to those events, or they may have spent equal time bolstering their own preparedness. There is a potential attack surface that may have received comparatively less attention, but that is nevertheless equally important: the cloud.
Cloud environments are no less susceptible to ransomware than other environments. However, they have properties that can make response and preparedness different. For example, they might employ different notification and communications channels, they might involve different personnel, and there may be a different control set in use. It can behoove organizations to think through ransomware in the cloud the same way they prepare for ransomware for internal systems and applications.
Ransomware in the cloud
Using an infrastructure as a service (IaaS) platform gives the cloud customer more visibility into the underlying OS than other cloud models, but this, in turn, means that issues, like patching -- particularly in the case of legacy or special purpose systems -- are just as complex as in other environments, and therefore may take longer than one might like.
The issue is that an IaaS environment might be susceptible to ransomware. What is different with IaaS, though, is how the organization discovers the ransomware, how it responds and how it protects against the threat. As a practical matter, different personnel are often responsible for direct oversight of IaaS workloads compared to other technology.
For example, cloud is conducive to shadow IT. It can be hard for enterprise security teams to identify and manage shadow cloud applications used by employees and lines of business across an organization. Will a development team, business team or other non-IT organization plan for -- and be ready to remediate -- ransomware in the cloud to the same extent as the technology organization?
Even if shadow IT isn't a factor for an organization, initial notification of a ransomware event might come through a different channel than expected. For example, notifications could come from a relationship manager for larger deployments; a defined escalation channel with the service provider, which might be a business team; or through a provider-maintained service portal.
Also, keep in mind that both the resolution and implementation of specific countermeasures might need to be done through different channels. As an example, if a key activity in response to a rapidly proliferating ransomware, like WannaCry, is to proactively patch, the manner in which you affect this might vary for the cloud -- an enterprise might need to schedule a maintenance window with its provider, for instance.
Aside from IaaS, other cloud models can be impacted, as well. Even SaaS isn't immune -- consider storage such as Dropbox, Google Drive, etc. Typically, these services work by syncing local files to the cloud; for a small organization, this might constitute its primary storage, backup or data sharing mechanism. What happens when the local files are encrypted, deleted, overwritten with garbage or otherwise compromised by ransomware? Those changes will be synced to the cloud.
Mitigation strategies for cloud ransomware
What can organizations do to prepare for ransomware in a cloud environment? There are a few things that can make response significantly easier. Probably the most effective thing organizations can do -- for both cloud environments and for any other environment -- is to specifically exercise response and escalation procedures.
For example, a tabletop exercise can be very helpful in this regard. A tabletop exercise defuses the primary question: will you pay the ransom? Invariably, someone will suggest paying it regardless of law enforcement and others arguing against it -- discussing this specifically ahead of time helps clarify pros and cons when adrenaline levels aren't off the charts.
Secondly, working through alert and response scenarios ahead of time means you get answers to key questions: how will you be notified of an event? Who will be notified, and what notification pathways correspond to specific cloud relationships? Also, what is required to take responsive action in each of those channels?
It's also a useful idea to undertake a systematic risk assessment specifically for ransomware. You might, for example, look at backup and response processes to ensure that, should data be specifically targeted by ransomware that seeks to render it inaccessible, the organization has thought through protection and recovery strategies at the technical level.
For an IaaS relationship, think through and test backup and response services that service providers might offer, technical controls that they offer and the countermeasures the organization already employs. This level of risk analysis is probably already done for the enterprise as a whole, but you should take measures to specifically extend that to cloud relationships. This can be somewhat time-consuming for organizations that have numerous service provider relationships in place, but this effort can be folded into a broader activity that has value beyond just ransomware -- for example, malware mitigation more generally, data gathering about cloud relationships, threat modeling, cloud governance or other activities that involve the systematic analysis of cloud relationships.
The arguably harder situation in the event of ransomware in the cloud is the intersection of SaaS and smaller organizations -- specifically, the possibility of corruption of cloud storage through synchronization of ransomware-impacted files to a remote storage repository. Specific measures to prevent this are available, such as keeping a manually synced or time-initiated mirror of data at another repository, assuming that the volume in question isn't such that this is prohibitively expensive.
Alternatively, backup solutions that keep prior iterations of data can provide a means of recovery even if the primary storage location is compromised. Regardless of what method an organization employs, though, the most important thing is to think through it in advance and view protection measures critically.