Engineering Disasters in Information Security Magazine
The December 2005 issue of Information Security magazine features an article I wrote titled History Lessons with the subtitle "Digital security could learn a lot from engineering's great disasters." It is based on this blog entry describing analog engineering disasters like the 1931 Yangze River damn failure, the 1944 Cleveland LNG tank fire, the 1981 Kansas City Hyatt Regency hotel walkway collapse, and the 1933 Atlanta Marriott parking lot sink hole.
I am considering expanding this topic of digital security disasters to encompass a new book. I would like to take a historical and technical look at digital security failures on a case-by-case basis. Ideally the cases would be based on testimony from witnesses or participants wishing to (anonymously) share lessons with their colleagues.
My concept is simple: when a bridge fails in the "analog" world, everyone knows about it. The disaster is visible, and engineers can analyze and learn from the event. The lessons they take away make future bridges stronger and safer. I do not see this happening in the digital world. Organizations suffer disasters all the time due to poor techniques, tools, configuration, management decisions, and so on. Unfortunately, few people ever hear about these problems, so they are repeated elsewhere. The only parties to benefit are intruders. Security engineers never get to learn from the mistakes of others.
What would a sample story look like? As a simple example, I know of an ISP who suffered a two hour router ACL drop that allowed remote intruders to exploit their development network. The ISP suffered a major compromise by Russian intruders that required a dedicated multi-week, guerilla-warfare incident response effort. Several lessons can be learned: (1) a router with an ACL is not a firewall, especially when you can attack any high port using source port 20 TCP; (2) development networks with unpatched machines should not bear publicly routable IP addresses and be Internet facing; and (3) there is value in monitoring to detect when your defensive measures fail.
Would any of you be willing to share your stories with me? I would be willing to communicate in any reasonable manner you wish to preserve your identities and sensitivities. The goal of the book is to provide real-world cases that can teach lessons to fellow security engineers. I am not trying to embarrass or humiliate anyone. I do not expect to hear any company or personal names, and if you still provide them I will not repeat them in the book. I am most interested in stories that have plenty of technical details.
Please email your thoughts to richard at taosecurity dot com. Thank you.
I am considering expanding this topic of digital security disasters to encompass a new book. I would like to take a historical and technical look at digital security failures on a case-by-case basis. Ideally the cases would be based on testimony from witnesses or participants wishing to (anonymously) share lessons with their colleagues.
My concept is simple: when a bridge fails in the "analog" world, everyone knows about it. The disaster is visible, and engineers can analyze and learn from the event. The lessons they take away make future bridges stronger and safer. I do not see this happening in the digital world. Organizations suffer disasters all the time due to poor techniques, tools, configuration, management decisions, and so on. Unfortunately, few people ever hear about these problems, so they are repeated elsewhere. The only parties to benefit are intruders. Security engineers never get to learn from the mistakes of others.
What would a sample story look like? As a simple example, I know of an ISP who suffered a two hour router ACL drop that allowed remote intruders to exploit their development network. The ISP suffered a major compromise by Russian intruders that required a dedicated multi-week, guerilla-warfare incident response effort. Several lessons can be learned: (1) a router with an ACL is not a firewall, especially when you can attack any high port using source port 20 TCP; (2) development networks with unpatched machines should not bear publicly routable IP addresses and be Internet facing; and (3) there is value in monitoring to detect when your defensive measures fail.
Would any of you be willing to share your stories with me? I would be willing to communicate in any reasonable manner you wish to preserve your identities and sensitivities. The goal of the book is to provide real-world cases that can teach lessons to fellow security engineers. I am not trying to embarrass or humiliate anyone. I do not expect to hear any company or personal names, and if you still provide them I will not repeat them in the book. I am most interested in stories that have plenty of technical details.
Please email your thoughts to richard at taosecurity dot com. Thank you.
Comments