When I was leading the Network Security Group at the US Naval Postgraduate School, I was overwhelmed with the degree of failure we experienced. The amount of events, complexity of investigations and immature security infrastructure created an environment of perpetual failure. After gathering the basic business metrics I discussed in Metering Incident Response 101 I decided it was time to push the problem up the chain of command.
We started WitFoo because we were moved by the pain we were seeing on the faces of our customers in previous endeavors. We knew that there had to be fundamental changes to how security software supported the craft. We decided we would study, listen and follow the needs of our front line investigators. We would build what they need to win against adversaries and to communicate with their broader business.
One of the areas we research heavily at WitFoo is how to reduce the number of investigations our customers have to perform each day. Internally, we call this the “n” problem. Another area of focus is how to reduce the amount of time our customers spend on each investigation. We refer to this as the “t” problem. The lower we drive n and t, the more work our customers can accomplish each day.
First, the nature of evolution discards noise. Much like the concept in biology, only fit, useful facts survive the evolution process. When exposed to more complex systems, noise goes the way of the dodo bird. A “possible SQL injection attack on MySQL” event becomes irrelevant when vulnerability reports show the targeted server isn’t running MySQL. As data becomes a more mature, evolved object the irrelevant events fall away.
In 1995, I started my Navy training as an Aviation Electronics Technician. I spent more than a year learning electrical theory, how to use sophisticated tools (like time domain reflectors) and the logic associated with troubleshooting avionics. I was ready to go to mano a mano against any aircraft that was daft enough to challenge my acumen.