<div dir="ltr"><a href="https://it.toolbox.com/blogs/kevinbeaver/considering-storage-in-your-incident-response-planning-010318" target="_blank">https://it.toolbox.com/blogs/<wbr>kevinbeaver/considering-<wbr>storage-in-your-incident-<wbr>response-planning-010318</a><br><br>Incident response – the art and science of responding to security breaches – is an often-overlooked component of business continuity. The necessary procedures required for properly handling network intrusions and insider shenanigans aren’t forgotten until the going gets rough. In the relatively small number of enterprises I come across that do have a viable incident response plan the storage environment containing all the critical information assets is often not included in the overall scope. <br><br>One of the most common gaps I come across is the assumption that incident response plans that are “good enough” will suffice. Plans deemed “good enough” will most certainly include critical servers, cloud applications, database systems and so on. Mobile devices are typically included as well. But there’s something about storage systems that doesn’t seem to ring a bell when the time comes for determining which business-critical systems need to fall under the umbrella of protection. <br><br>Storage systems can be viewed from two different angles. On one hand, they’re often part of a larger information system. This is the common stance. But storage systems are technically standalone boxes with their own unique footprint. They have their own IP addresses and URLs through which they’re managed yet I rarely see them mentioned – much less covered – in any given incident response plan. Furthermore, storage systems are fair game for attack including: <br><br>· Malware outbreaks including ransomware that can impact network shares used for storage <br>· Weak password exploits that can lead to unauthorized information access <br>· Missing patches that are easily-exploited for full remote system access <br>· Web security flaws that can be manipulated for things like cross-site request forgery and SQL injection <br><br>On top of all of this, the logging and alerting associated with storage systems are often lax which can minimize the visibility of incidents. It’s bad enough that the appropriate technical and operational controls aren’t in place to keep critical storage systems from being attacked. Keeping storage systems out of the incident response loop compounds these problems ten-fold. <br><br>Make sure that you’ve fully documented your storage environment and you’re keeping it on your radar for incident monitoring. This may involve existing network security systems such as SIEM, DLP, and IPS. It may even require new controls to be deployed if you don’t have proper coverage of your storage systems (local or in the cloud). Next, do what you can to ensure your business has a reasonable set of incident response procedures so that the what, when, where, why and how of storage-related incidents is properly covered. As with any attack or exploit, the last thing you want to be doing while under attack is figuring out how to respond. <br><br>Incident response is about proactively monitoring for incidents on all your critical business systems. Given that most storage systems equate to where the money is you can’t afford to not have these systems at the top of your priority list. Get a hold of incident response and make sure you’re doing it right. As the saying goes “good enough” hardly ever is.</div>