Cyber Security Institute

§ Current Worries

Top 3 Worries

  • Regulations
  • Old Firewall Configurations
  • Security Awareness

§ Listening

For the best information

  • The underground
  • Audible
  • Executive Excellence
  • Music (to keep me sane)

§ Watching

For early warnings

  • 150 Security Websites
  • AP Newsfeeds
  • Vendors

Friday, August 16, 2013

Security incident response procedures: When to do a system shutdown

At the same time, the attackers that target enterprises for their valuable information, or sometimes for political reasons, have never been more sophisticated, which has increased the pressure on enterprise security teams to be able to keep critical systems running securely and without interruption. Shutting down a system in response to an information security incident is one of the most drastic options that can be taken, but it might be the best option in certain scenarios. Occasionally, regardless of how well prepared an organization might be from a security perspective, an attack will leave the security team debating whether the risks involved with keeping a system running outweigh the potential impact of taking an infected or targeted system offline.


Shutting down a system in response to an information security incident is arguably the most drastic option that can be taken, but it might be the best option in certain scenarios.

For example, if there were a possibility that an attacker could gain control of a computer system that regulates traffic lights, it would likely be best to disable that system, and thus the traffic lights, because drivers would hopefully know to treat the non-working traffic signals like stop signs.

Such a decision would also depend on the security and availability controls implemented, including if there were controls in place that limited the compromise from spreading to the complete system versus just a compromised account.

In a system that contains no sensitive data and only has availability requirements, the security team could just do a basic calculation of the cost incurred from the downtime versus the recovery cost from containing and remediating the compromised system, and then make a decision based on the numbers.

This will lead into developing a business continuity and disaster recovery plan (BCDRP), which is similar to an incident response plan in that they both need to be developed prior to an incident and periodically tested so if a shutdown becomes necessary, a playbook for dealing with the situation is on hand.

In developing the BCDRP or incident response plan, establish a channel of communication with the necessary people, including the chief information security officer, chief information officer, helpdesk, business owners and marketing so they will be able to quickly make an informed decision about potentially shutting down a system.

For example, a Web server with a Web application susceptible to an SQL injection vulnerability might be shut down while a patch is being developed, a Web application firewall is set up or the configuration is changed to remove access by the Web server to run commands on the system.

Regardless of which option is the best in a given scenario, ensuring a plan and communication channels are in place prior to an incident is critical to minimizing the impact on your organization.



Posted on 08/16