Pop quiz hot shot...
It's a chaotic Thursday afternoon. A series of bombs have gone off across your city paralyzing local transportation and infrastructure. You and co workers are trying to get information about loved ones and friends but your Internet link seems to keep going down. Local law enforcement has just entered your operations center saying that they're evacuating the building due to a suspicious van that's sitting unattended across the street...
...and you just got word that your website was defaced.
What do you do?
Sadly, it can't be as simple as "Call Keanu Reeves."

Tabletop exercises are incredibly useful from the perspective of Information Security folks: Drilling incident response so that it comes second nature can make the times when a crisis happens so much easier. However, all to often we focus on everything within our little silo: "A firewall just got down", "A server was compromised", "A worm is spreading across the LAN", etc. Bringing in a fresh set of eyes to look at exercises and suggest additional variables to toss into the equation can keep teams on their toes and start to think about problems beyond their area of control.
Recently, I was in a discussion with some peers regarding a recent exercise one of them had where there was a fire drill during the middle of it. While they were lamenting this, I asked "Well, what happens if there was a fire drill during an incident? Or worse, a fire?" seizing upon this dicussion followed and scenarios like the one described above started to form. They all boiled down to one question: What happens when the real world intrudes on your incident handling process?
While most businesses have some kind of Continuity of Operations plan, how many folks know how it applies to them? More importantly, how does it fit within your own procedures? Most IT pros know how to handle a virus outbreak on an internal network, but it's a completely different monster when halfway through the entire staff has to be evacuated due to a natural or man made disaster.
Some questions to consider (and discuss with your staff (and bosses)):
- What if something happens and your operations center is no longer able to be staffed during an incident?
- What's your chain of command? Who's in charge if there is a event similar to a Case Orange scenario with regular staff being incapacitated or unable to communicate?
- How do you contact people when regular lines of communications are down?
- Is security a stakeholder in the DR process?
- If all company sites are inaccessible and information is unable to reach your staff, where is your rallying point?
A lot of security professionals know that electronic networks are fragile and vulnerable, still, how many of us assume that telephones, cellular networks, and power will be up during an attack? Exercises should start preparing staff for a large scale disaster that may impact these services and designing processes to work around them.

The hell?! Ok, so in the sake of full disclosure - this is not running *ON* the Apple IIe. As far as I know, nobody has ported Ruby to Apple IIe. I can't imagine how painfully slow that would be. I used the native Apple Super Serial Card and a DB25 <-> DB9 null modem cable. The other end terminates to a USB to serial adapter hooked up to a net book running a persistent install of backtrack 4. From there, a little /sbin/getty action and I've got shell access over serial. I'm using ProTERM 3.1 as the terminal emulator on the Apple IIe connected to a vt100 terminal type. savant