IT Lessons from Military History

Occasionally, colleagues will ask me about what I read to keep up with industry. First of all, everything I read isn't about software, or IT security, or other "industry stuff." I have a healthy range of outside interests that also guides my reading material (e.g., I love to surf, so I get a couple of surf mags to ogle when I am not catching waves). However, one of my outside passions does indeed have a knock-on benefit to my day job, and that is my interest in military history. The more I learn about military history, the more applicable I find the basic concepts (not to mention historic battles) to be to IT security.

I read at least one military history book a week, and if I am not prepared to refight the battle for Guadalcanal, I nonetheless thrive on the material for reasons as diverse as historic value, intellectual stimulation, and last, but really first, the inspiration of the heroism and sacrifice that make our freedoms possible. (Small factoid: there were 27 Medals of Honor awarded to individuals who fought at Iwo Jima. Thank the next Marine you see, for as long as people remember Iwo Jima, there will be a United States Marine Corps. Semper fi.)

One of my favorite battles of all time is the battle for Midway (June 4-June 6, 1942). This battle changed the course of the Pacific War. Before Midway, Imperial Japan had known only continuous expansion of the amount of territory under its sway: after Midway, Japan expanded no farther. It's such a stunning victory that you forget that the United States did not have the advantage in terms of number of ships, pilots, or planes: the Japanese sent a literal armada to Midway.

There are two or three salient points I take away from the battle for Midway that are directly applicable to my day job. One of them is that history is shaped not only by "the big guys," but also by the people in the trenches who do the work. One of the reasons the United States prevailed at Midway was because of the carrier Yorktown. Yorktown had been badly damaged at the Battle of the Coral Sea, to the extent that the estimate was that it would take three months of repairs to fix her; however, ADM Nimitz gave the shipworkers at Pearl Harbor a mere 48 hours to repair Yorktown, as the US Navy needed Yorktown at Midway. A key reason the United States prevailed at Midway was the presence of the magic third carrier--Yorktown--in addition to Enterprise and Hornet. While many remember the names of the leaders at Midway (e.g., Task Force 16 and 17 commanding officers Raymond Spruance and Frank Jack Fletcher) few remember those anonymous steelworkers who made the victory possible, because Yorktown sailed from Pearl Harbor for Midway, welders still fitting plates and beams into place.

I had a journalist ask me the other week why my name wasn't in the IT security press so much any more, and didn't it bother me? My response was that on the contrary, so many capable people I work with in security at Oracle (or who work for me) are the ones in the spotlight now, and that is as it should be. Not only are they the subject matter experts on so many aspects of security (how we engineer security into the development processes, our ethical hacking team, our program management in security, and so on), they are Oracle security, and I am only too happy to see their names in the press, getting credit for what they do so well. (They have all too often done the equivalent of making Yorktown seaworthy in 48 hours when they really could have used a full 3 months.) I recall the motto of the Seabees (US Navy mobile construction battalions, of which I used to be a member): "The difficult we do immediately, the impossible takes a little longer."

A second lesson of Midway is the value of intelligence for those who are willing and able to act upon it. The United States had broken the Japanese JN25 cipher and tricked the Japanese into disclosing that the atoll of Midway was their destination, and their intent was to finish off the US Pacific Fleet in a decisive battle. There was some debate as to whether the Japanese were laying a trap, but ADM Nimitz nonetheless committed two carrier task forces to the battle for Midway, where they lay in wait for the Japanese.

From an IT security standpoint, the lesson here is to ensure you avail yourself of the intelligence that exists. I know all too many enterprises that turn off auditing ("too much overhead") or throw away their audit logs, or ignore the alarms on their intrusion detection systems because they can't be bothered to parse through them. In a very real way, the network is the battlefield, as "bad guys" are far more likely to try to glean your secrets and steal your property electronically than they are to try physical means to affect the same ends. If you don't use the "electronic intelligence" you have, you will be left "blind and naked," and wondering where and when your enemy will attack you (or is attacking you). (A second security lesson is that you should not assume your codes cannot be broken, as the Japanese did.)

A last aspect of Midway I take to heart is the power of the individual to influence history. One of the turning points--perhaps the turning point of Midway--was LCDR Wade McClusky from Enterprise's Scouting 6 "following his hunch," which led to him finding three of ADM Chuichi Nagumo's carriers about to turn into the wind (i.e., launch their planes), their decks littered with ordnance. The United States set three carriers on fire within 6 minutes (ultimately, four Japanese carriers were sunk at Midway). Japan never recovered from the loss of so many ships, planes, skilled pilots and mechanics. One wonders what would have happened if LCDR McClusky--who was running dangerously low on fuel--had not showed the initiative in following his hunch? Furthermore, individual initiative and flexibility in battle--rather than slavish adherence to a battle plan--has often been credited as a "cultural advantage" the West successfully exploited over the armed forces of Imperial Japan.

I try to encourage the people who work for me to show individual initiative, and also to "push back" at me, because I am not right about everything, and certainly not right in every last security detail. I try to be a good leader, but ultimately, out on the battlefield, it is the fighter pilot who has to fly the plane and shoot down the Zero, rather than the Admiral back in the relative safety of Pearl Harbor. Good leadership principles are timeless: you hire and train the best people you possibly can, and then you let them fly. I am so pleased to have a squadron of the very best security people one could ever want to work with. We will prevail.

(For excellent reading material on Midway, I recommend Incredible Victory by Walter Lord and Miracle at Midway by Gordon Prange. For reading material on Iwo Jima, I recommend Iwo Jima: Legacy of Valor by Bill D. Ross.)


Nice. Hope things are going well with you these days. Surprised you didn't mention your own background in this post...

Posted by Mike Friedman on March 24, 2006 at 11:28 AM PST #

Excellent post. I appreciate the analogy between IT security and military.

Posted by Ivan on March 25, 2006 at 01:55 AM PST #

If there's one military figure I would use to improve my own mentality (Oracle, IT or otherwise), it would be Marine Sargeant Carlos Hathcock: Amazing dedication and valor! So let the security holes get sniped one-by-one... Rich

Posted by Rich J on March 30, 2006 at 05:29 AM PST #

Post some pictures of yourself surfing!

Posted by a on March 30, 2006 at 10:09 AM PST #

I recommend Barry Strauss' Battle of Salamis as a great blend of history and naval warfare expertise. Thanks Mary Ann.

Posted by Greg Ness on April 05, 2006 at 05:48 AM PDT #

EBS:User Management (UMX) & Role Based Access Control (RBAC) When is Oracle going to update the EBS System Administrator documentation and applicable classroom & Technology-Based Training courseware to show the EBS user community how to implement the new UMX/RBAC features introduced with EBS Release 11.5.10? This is very relevant to SOX compliance.

Posted by Joe Arnold on April 05, 2006 at 07:01 AM PDT #

I would recommend the Book by the former Commandant General of the Mainre Corps. "War is a racket" Butler, Smedley Darlington, 1881- OR The costs of war : America's pyrrhic victories Denson, John V., 1936- First person accounts of the smoke noise have little to do with security, history. Butler book is very relevant to post 9/11

Posted by George Giles on April 06, 2006 at 04:22 AM PDT #

Nice write-up! Here's another lesson we can learn, but this one from a Japanese mistake. Don't overreact to a minor problem. Sometimes the attempt to eliminate a "minor problem" can lead to a major one. (The "minor problem" in the historical case was the American ability to launch small, suicide bombing raids against Japan itself).

Posted by Robert Vollman on April 06, 2006 at 03:26 PM PDT #

Hi Mary Ann, You're much more than a techie I see. Military history always good for the next high-tech war. Aloha, Rusty

Posted by Rusty K. on April 10, 2006 at 08:06 PM PDT #

Can you publish the presentation that you gave at OAUG Collaborate 06 Nashville as a part of your blog, and/or via the OAUG conference website? I missed your presentation (had conflicting timetable) and there weren't any printouts left. Oracle's current position is of great importance to my company, and our DBAs and security people would like to better understand Oracle's current efforts and position Miles Thomas Enterprise Architect, Tesco in a Box & ORUG/OAUG Rtech SIG leader Tesco plc.

Posted by Miles Thomas on May 21, 2006 at 10:47 PM PDT #

Thanks for your suggestion. I really liked Miracle at Midway by Gordon Prange.

Posted by Kirtan Desai on June 05, 2006 at 07:24 AM PDT #

my new favorite blog! keep it coming

Posted by reader on June 14, 2006 at 02:51 PM PDT #

explore manufactruing quality improvement / cost reduction - TQM (renamed six sigma). SAP seem to be exploring it? if the process of generating software is CAPABLE, then quality (security) product will result. If the process is sloppy, not. SImple isn't it? Cars (and planes) were buggy when new - thirty years ago! Ralph Nader - "unsafe at any speed" - changed that and the Japanese sent Taguchi to study in USA and improved their production processes. What is needed stick: law makes it compulsory for software to be safe carrot: - cheaper "get it right first time every time" and faster software generation process, no (or low) need for patches.

Posted by albert on June 18, 2006 at 08:52 PM PDT #

i am not only information security expert but also manufacturing process improvement expert - 11 and 13 years of experience in the 2 fields respectively... and I have not been to Hawaii (yet)

Posted by albert on June 18, 2006 at 08:54 PM PDT #

Interesting comments on language translation and biblical hebrew as I also have a little knowledge of hebrew. Like the word ne'phesh for soul, many translations are not consistent in it's usage. On a different note, would be interested in who is your counterpart in UK. Particulary who heads up BCP in UK? Feel free to email me.

Posted by Mark on July 06, 2006 at 01:46 AM PDT #

I suspect there are not many infosec practitioners who moonlight as surfer poets. I hugely enjoyed the years at Oracle and "everything I know about Oracle security" being learned from and with you as well as our interactions with Oracle customers through the years. The blog is excellent, please keep it up! As for readers of this blog, I would recommend you obtain a copy of "The Black Book on Government Security" where Mary Ann contributes a chapter along with Gregory Akers, Will Pelgrin, and others -- a good read, I have an advanced copy - not sure when it goes up for sale or where but perhaps MAD can shed some light. MAD--- Mahalo Nui Loa --

Posted by Jim Lee on July 16, 2006 at 12:25 PM PDT #

Hi, Yes, Military history and tactics plays a big role, and I too super-impose military over IT. I think you have already read "Art of War" written during 6th century BC. If no, it is a good read. Ashly A K

Posted by Ashly A K on August 19, 2008 at 01:31 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed



« April 2014