easy-accordion-free
domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init
action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mother99/jacksonholdingcompany.com/wp-includes/functions.php on line 6114zoho-flow
domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init
action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mother99/jacksonholdingcompany.com/wp-includes/functions.php on line 6114wordpress-seo
domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init
action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mother99/jacksonholdingcompany.com/wp-includes/functions.php on line 6114The constant evolution of the digital world has not only presented an abundance of opportunities, but also raised an equal amount of security challenges, ransomware being one of the most sinister. In\u2026 Read more on Cisco Blogs<\/a><\/p>\n \u200b<\/p>\n The constant evolution of the digital world has not only presented an abundance of opportunities, but also raised an equal amount of security challenges, ransomware being one of the most sinister. In response to this growing threat, our team of Principal engineers at Cisco (including myself under the guidance of our project sponsors from Cisco\u2019s Security Business Group and Cisco IT), embarked on a journey towards automating ransomware recovery not just for our own enterprise, but for everyone.<\/p>\n The underlying problem we sought to address was the ability to automatically recover hosts from a ransomware attack. An intricate analysis of assumptions and facts was necessary, as our initial assumptions had to be validated against reality. We began by knowing all incidents require an eradication and recovery process. This responsive process could leverage automation or orchestration. Furthermore, we believed that ransomware could be mitigated by response initiated from events or alerts. This meant that activities that normally would be considered administrative in nature or \u201cliving off the land\u201d had to be considered in detecting adversarial activity.<\/p>\n We began looking at all the prevalent sources of threat intelligence on ransomware activities and analysis from sources like our own Talos Intelligence, CISA ransomware[1]<\/a> guide, Splunk SURGe, our internal Cisco IT, and others. As our journey progressed, we identified new facts that shaped our approach to automated ransomware recovery. We found that effective responses needed to be close to the source, and the alerts often lacked a clear progression to the ransomware target(s).<\/p>\n A significant revelation was the limited window for response, typically less than 45 minutes[2]<\/a>, which drove us to think critically about the time-sensitive nature of ransomware recovery. Microsoft Windows is the predominate operating system used for ransomware operations. However, there have been Linux variants of ransomware too, so we needed a solution that could help in the most severe situations.<\/p>\n As we began exploring various conceptual solutions, we considered three main options:<\/p>\n API Responsive Recovery:<\/strong> Using Automation on Endpoint Recovery using third-party integration seemed promising, especially with the easy applicability of cloud capabilities. However, this solution might lead to the loss of locally stored data on user systems.<\/p>\n \u00a0<\/strong>Selective Response:<\/strong> Selective response on critical systems stood out as a solution that allows for fast recovery and rollback to the last known good state for systems. However, database and transactional systems could pose challenges for recovery.\u00a0<\/strong><\/p>\n Operating System Centric:<\/strong> Windows Volume Shadow Copy Service (VSS) administration with protection drivers, a Windows-only feature, was an intriguing solution. Despite its limitations, it offered multiple benefits, such as local storage limits and immunity to restore the system, effectively disabling the attacker\u2019s capabilities which is why almost all of the ransomware attacks target this native Windows capability.<\/p>\n Our long-term recommendation centered around the preventive measures, which include the development of a Secure Endpoint Transformation Roadmap. Incorporating endpoint integrations with memory or device protection drivers is vital for advanced protection. New recovery options for Windows systems and protection for native capabilities, and endpoint policy advancement with permit and deny lists, means that adversaries would have a harder time disabling a service that the system has access to.<\/p>\n Linux doesn\u2019t have a \u201cvolume shadow service\u201d, and yet by creating our protection driver(s), we\u2019ll be able to add a service like Linux Volume Management to \u201csnap\u201d the image to a location for protection in the future.<\/p>\n We also evaluated third-party solutions like virtual systems protection from Cohesity, Endpoints with Code42, and thin-client architectures like Citrix. Some other innovative solutions, like Bitdefender and Trellix, keep a small copy of recovery data either in-memory or on disk, providing additional layers of security.<\/p>\n Moving forward, we intend to thoroughly analyze the assumptions underlying our project. For instance, we need to decide on the systems we can protect effectively, including the most at risk (servers), the most volatile (customer devices), and the least impacted (cloud devices).<\/p>\n A critical part of our project was learning from real-world ransomware attack cases. We understand that while commodity malware provides significant value from a recovery model focused on the endpoint, targeted attacks require more prescriptive and preventative capabilities.<\/p>\n We are considering two main models for remediation:<\/p>\n Shutdown Everything:<\/strong> This model involves predicting suspicious behavior and preemptively backing up data, then restoring to that last known configuration. Predicting suspicious behavior is difficult, because you can\u2019t just use one event or parts of multiple events. You really needed to correlate an attack pattern and then preemptively backup and recover.<\/p>\n Just in Time:<\/strong> Here, we notice suspicious behavior and backup changes as they occur, like Bitdefender\u2019s module. Giving the analyst a way to surgically restore objects within the operating system on the fly.<\/p>\n We had two final recommendations that have driven our innovation and efforts into this blog and future capabilities. We knew we needed something now that would help all measures of customers. Our smaller customers are underserved by not having all the resources to create synchronized, effective recovery options for their environments.<\/p>\n We determined that API Responsive Recovery<\/em> option was less than adequate, while pretty much readily available now and does provide a measure of protection, but at the selection of cost and potential to storm a backup solution with \u201csnaps\u201d or backup requests along with the load to recover all systems.<\/p>\n Traditional API implementation with a SIEM\/SOAR solution would be chaotic to manage effectively and lack the ability to provide enough context related to the systems that are impacted. This solution provides the most customizable solution and mostly customer created. This isolates teams with lean IT options to ensure that the SOC and IT have adequate controls prior to recovery options. While this capability was well within our grasp, it left us wanting more.<\/p>\n Moving on to Selective Response,<\/em> which focused on only recovering critical systems. During our interview with our team of experts at Cisco, we found a common theme: recovery processes needed to be for the most important systems first, think Business Continuity Plan. <\/em>Individual computers in a disaster recovery scenario weren\u2019t always the first systems to be recovered. We needed to restore and recover the most critical systems that served the business. We also identified this as a critical task for all teams, including the smallest. A lot of times small teams are forced to pay the ransom because they can\u2019t trust the restoration processes based on individual recovery software, or the data loss is too great.<\/p>\n This is where our partner Cohesity comes into the picture. Cohesity provides a comprehensive protection plan for virtual systems[3]<\/a>. One of the best defensive capabilities for ransomware is a solid recovery process for those systems. Virtualizing systems has become the standard for most hybrid data centers to allow for efficient resource allocation and high availability capabilities, but it lacked features for restoration of combined application services systems. Cohesity, which works with the Cisco UCS chassis[4]<\/a> for virtualization, provides configurable recovery point objective for systems assigned to a protection plan. Cohesity Helios coalesces the data recovery needs of separate application services by synchronizing the restoration process of disparate system snapshots into a single recovery process. For example: Being able to protect a database with a one-hour recovery point objective (RPO), application server with a four-hour RPO, and web server with a twelve-hour RPOs into a single protection plan. This recovery capability allows you to restore your application service under protection with a minimal amount of effort and maximized service restoration by restoring the images at the same recovery point while protecting it from adversarial tampering<\/p>\n