Disaster Recovery Planning

I hosted a Disaster Recovery tabletop exercise for the operations teams earlier this week. Hosted? The teams may say "tortured" is a better word. The main idea was to take our DR document out for a spin and see how it handled. The scenario was a little far-fetched, but the situation was that our core data center was damaged and not accessible. The exercise was designed for the members of the various teams to think about what the priority order of events would be to get us back into an operational state. The result of the exercise is that we have some work to do, especially regarding getting dependencies identified. I have about 10 pages of notes that I took and I invited everyone to send me their comments. My job for several days is going to be synthesizing all of the notes and comments and then suggesting changes to the DR plan.

There was at least one happy consequence. In the words of one team lead, "This was a tremendous team building exercise for my team. Previous to this exercise, it was not clear to all members how hard each person in the group works, nor how much passion these individuals have for their job. While people explained what they had done in their area to prepare for this type of disaster, I saw facial expressions change. Some people who hadn't spoken to each other in over a year, were having full fruitful conversations. Even better than that, they are talking this morning! I am not sure this was meant to be a team building exercise; however, for my group it was an excellent experience."

What's On Your Bookshelf?

Toward the end of the SANS 564 class I led last week, one of the students asked what security books I'd recommend. So here is a list of what's on my office bookshelf with a brief review.

Carrier. File System Forensic Analysis.
THE book on the topic
Stoll. Silicon Snake Oil.
Contrarian view of the "tech revolution" and its accompanying sales creatures.
Mitnick. The Art of Intrusion.
I know. But I had to read it
Long. Google Hacking.
THE book on the topic, but I have an old copy.
Winkler. Spies Among Us.
Practical view of personal information security.
Wiles. Techno Security's Guide to Managing Risk.
Only the chapter by Long is worth reading.
Middleton. Cyber Crime Investigator's Field Guide.
A usable reference, but not well written.
Worral and Hemmens. Criminal Evidence, An Introduction.
A text book that doesn't read like one (it is good).
Nemeth, et al. Unix System Administration Handbook.
A well worn copy that is now nearly old enough to buy liquor.
Mandia & Prosise. Incident Response.
Haven't read through it all, but what I have read is good.
Alder, et al. SNORT 2.1.
Same comment as on Incident Response.
The Honeynet Project. Know your Enemy.
I think I read the cover, but nothing else.
Gentile, et al. The CISO Handbook.
Seriously over priced list of common sense ideas.
Kovacich. Information Systems Security Officer's Guide.
Same comment as on CISO Handbook.
Tannenbaum. Operating Systems Design and Implementation.
Maybe a bit long in the tooth, but THE book on the topic. Brush up on reading C.
Abrahams, et al. UNIX for the Impatient.
Hilarious title for a 800+ page book.
Montgomery. Underground Guide to Unix.
Better than a poke in the eye with a sharp stick.
Allen. Getting Things Done.
I have no idea what it is about or where it came from.
Krutz & Vines. The Advanced CISSP Prep Guide.
It helped.

DHS Industrial Control Systems Seminar

I spent the day at a Department of Homeland Security Computer Control Systems Security Awareness program. The fellows conducting the training, Jonathan and Julio, did a nice job presenting the material. The content was an excellent high-level fly over of information security with an emphasis on industrial control systems. Industrial control systems operate or monitor things like pharmaceutical production, municipal water systems, the electrical grid, and that kind of stuff. It would be great seminar for executives who need to learn more about what goes into securing information or production systems. Most of the audience today were IT people for whom the content should have been old hat, but may not have been. A couple of good ideas I picked up were a definition systems administrators' priorities as "a culture of making things work" and some recent survey data on computer crime. I looked up one of the referenced surveys at http://www.gocsi.com/ and was disappointed to find that it requires registration to download the free preview of the survey report--I really dislike that. Here is a similar survey without the registration hassle: http://www.consumerfraudreporting.org/internet_scam_statistics.htm. The surveys can be useful for raising executive security awareness.

Passwords

Everybody knows that passwords are weak authentication. But sometimes it's all we have. A while back an irate prof. accused me of being inflexible (imagine--an info sec guy inflexible?). The prof. felt he should not have to change his password. He made his argument claiming he didn't have access to any sensitive information. I asked him if he thought his banking information and social security number were sensitive. He agreed that they were. I pointed out that his univ. ID and password gave him access to his banking information and social security number in our ERP (not to mention student records). He came back saying his bank doesn't make him change his password or PIN. What could I say other than telling him I care more about his private information than his bank does?