The Risk Of Friendly Fire

Earlier this month I happened to pick up and read a book about the Battle of the Bulge – the insane last ditch major offensive launched by Germany against Allied Forces in December 1944. When the attack was stalled by a thin line of under equipped US forces, and then later counter-attacked by reinforcements, the result was a more rapid end to the war against Germany due to their expenditure of resources and rash decision to “come out of their trenches”.   

Reading the book reminded me once again about the horror of war and what a desperate, last-option it needs to be to decide to wage war.  It also reminded me of the valor, often talked about but also often forgotten in day-to-day life, of the men and women (on all sides) who are tasked with waging such war.

Another thought that occurred to me was the importance of Intelligence and Communications.   Many view the Battle of the Bulge as the biggest single failure of the Allied intelligence effort in WWII.  Apparently, there was a lot of evidence of Germany’s build up of troops before the offensive that made the location and timing somewhat predictable.  Had this intelligence failure not occurred, imagine what plans the Allies could have made and executed in response to the offensive.

The book also made me aware of a tragic circumstance that occurred during the battle that hit close to home for me, given some things I have been working on recently.  The weather wasn’t very good during the first part of the Battle of the Bulge, which was something the Germans counted on.  They wanted to negate the huge air power advantage that the Allied forces had. But occasionally there was a break in the weather.  During one such break, the Allied Air Force Command took the opportunity to perform massive bombing of the town of Malmedy.  The problem was, the night before, Allied forces had taken the town.  The effect on those forces and on the civilian population was devastating.  To make matters worse, Allied bombers returned again the next day and then again the day after that.

Yikes.  Talk about a breakdown in communications.  In this case, the root issue was lack of visibility.   For various reasons, the Allied Air Command had no visibility into the success and state of the ground forces.  They also literally couldn’t see rooftop signals and such that the troops used to try to warn off the planes.  They also didn’t interpret the behavior of the ground troops well – there was no anti-aircraft fire, blackout procedures,  spreading of troops and equipment and other actions that you might expect of an enemy digging in to minimize the effect of an air strike.

I’ve never been in a war, but I can imagine with all the craziness that goes on, that there are a lot more casualties due to Friendly Fire than get reported.  While it may be important to learn from Friendly Fire incidents, post-incident analysis must be difficult, because in many cases the source of fire is probably ambiguous, the damage has already been done, and any “lessons-learned” would be so tactically specific, what’s the point of looking at it more closely?

In many ways, it’s kind of awkward to segue from a war discussion to an IT discussion, but I’ve come this far, so I’ll do it. 

Over the past several years I’ve been involved in many security projects and products.   Since I’m a networking guy, these have tended to be network security endeavors – setting access control rules, separating internal and external address spaces, encrypting data over the network so no one can listen in, detecting external hackers, providing robustness against denial-of-service attacks,  authenticating users before they gain access to the network, etc.   Most or all of these techniques are valuable and needed, but they do all depend on one major assumption – that legitimate and seemingly legitimate users of your applications and the sensitive data they may provide access to, are safe.  But this simply isn’t the case.  Bad guys can steal credentials or identities or simply guess passwords via dictionary attacks.  When this occurs, the capability of all of the network-oriented security protections is completely circumvented.  True legitimate users can hurt you, too.  It’s sometimes politically incorrect to say that you worry about the malicious behavior of your trusted employees, but it can happen.  Also, employees with the best intentions can simply make mistakes and accidentally copy your sensitive corporate information to insecure locations, or corrupt it in ways that are difficult to roll back after the fact.  These can be big issues, especially if you have regulatory agencies increasingly looking over your shoulder.  All Compliance regulations are oriented towards the safekeeping of sensitive information.  These days, “Friendly Fire” can cost you a lot of money and/or some very bad publicity.

Technically, the risk is rapidly being increased by the deployment of web-enabled business applications.  The advantages of this application delivery architecture are that it leverages industry standard protocols and techniques to expand application access to a much larger pool of far-flung employees, consultants, business partners, etc.  These same advantages bring significantly new security challenges with them.   Everything you do to protect against “Unfriendly Fire” - authentication, intrusion detection, denial-of-service, log analysis, security event management, security policy management, data management, etc. – becomes much more difficult due to both the scale and nature of the tasks.   As the level of Unfriendly Fire increases, it becomes even more difficult to find the time and energy to protect against Friendly Fire.  You now have a much bigger pool of legitimate users, accessing the application in a variety of ways, with varying access and usage rights.

Yet I believe that providing visibility into potential Friendly Fire episodes is essential.  To enable that, what is needed are tools that allow you to monitor Friendly Fire efficiently, while at the same time providing robust protection against many forms of Unfriendly Fire, so that you can focus your dollars and energy on a smaller number of tools that support your total needs.

While searching for such a tool, I think I have discovered one where I least expected it, which I will discuss in next month’s Musing.