By simulating software security crises, your organisation can rehearse how to react in the event of an actual attack. These fire drills should lead to faster, more effective responses.
The time it takes for some security vulnerabilities to go from announcements to exploits is startling. For instance, the Drupal announcement in October 2014 showed that websites were being attacked in an automated fashion only seven hours after the vulnerability was announced. In June 2014, a user announced a cross-site scripting vulnerability in TweetDeck, and only 96 minutes later a self-propagating worm was tweeted that retweeted itself if it appeared in victims' feeds.
Vulnerability discovery is automatic and efficient
Attackers have frameworks and vulnerability exploit packages that automate discovery, exploit selection, and exploit deployment. Successful exploitation is just a matter of selecting a well-worn building block and then tuning it to the actual target system.
Tools such as Metasploit are obvious and are well-known to good guys and bad guys; however, attackers will have individual and shared collections of shell code, scripts, and query fragments that are not circulated as publicly. Over time, these exploit payloads circulate and are absorbed into tools such as Metasploit and become the basis for future variations.
Conduct software security fire drills
One of the findings of the Building Security In Maturity Model (BSIMM) is that many mature organisations simulate software security crises; these simulations are essentially fire drills related to software failures -- servers unavailable because of attack, major software failing to work, vulnerabilities being exploited actively to harm the business, and so on. The simulations - which are similar in spirit to Netflix's Chaos Monkey and other frameworks -- intentionally induce actual faults in live production systems during business hours to provide real-life experience recovering from failure.
These software crisis simulations are different from disaster recovery or business continuity planning, which most organisations already perform. Attacks on software often cause public embarrassment, either intentionally or as a side effect. Many software attacks do not cripple a business, thereby invoking business continuity practices. Unlike disasters, a software crisis might be a rapid response to fix software that is running normally and working as planned.
Moonpig's mobile API, for example, was working as designed, but was designed with a massive security flaw that the firm had known about for 18 months. When the exploit became publicly known, there was no disaster to respond to, and no impairment of its business that would trigger a business continuity response. It is likely, though, that Moonpig's response involved many of the same people who would be involved in disaster recovery: software engineering, IT operations, software security, public relations, and executives.
The principle is sound: a business gets good at what it practices. The important lesson is that software crises are not phenomena that are already covered by existing IT and business processes. IT and business leaders need to rehearse responses to software vulnerabilities for the same reason they rehearse evacuating a burning building: They limit the damage and achieve a faster, more effective response than figuring out what to do while in the middle of a crisis.