Back in my days at Cal, I worked part-time as a “Data Entry Specialist” (uh, typist) at the Earthquake Engineering Center Library in Richmond for a couple extra bucks. I typed abstracts into a database – nothing too glamorous, although it did pay for more than a few IB’s Hoagies and Top Dogs for a hungry EECS student.
Beyond picking up a few pounds, I also picked up some tidbits from technical journals and abstracts about the process of engineering for disasters, like earthquakes. There were some common themes in these articles – from what I could tell in between the mostly incomprehensible (to me) dialogue on issues like torsion analysis and plasticity versus elasticity.
- Studying failure is the best way to master compensating factors.
- Safety should not preclude efficiency.
- Disasters occur when poor engineering meets unexpected circumstances.
What we as security practitioners do is roughly comparable to earthquake engineering, and these themes are just as true when discussing SQL injection as inelastic oscillations. A crumbling structure may be more dramatic than a hacked system, but security folks’ specialized knowledge is highly prized because it removes mystery from tragedy and derives lessons for the next time. Earthquakes are unpredictable – like attacks. We must study what has happened in the past to understand how to protect ourselves in the future.
Looking back in this New Year is a good opportunity to consider what has worked, and what hasn’t (I will post on my experiences with this later). I think overall software security specialists could collaborate more, interact more, and gain from each other’s real-world experience. However, because security knowledge can be sensitive, it may not be as simple as submitting every piece of analysis to the local college intern to enter into a world readable database.
