Bio

CHARLES HERRING

WitFoo Chief Technology Officer

By the end of 2015 it was clear to me that the craft of cybersecurity was broken. My mind continuously compared SECOPS with other mature crafts that I had observed and executed, and it bothered me to the point of stealing peace and sleep. I decided I was going to start a revolution to “Build the tools and data needed to enable the craft of cybersecurity operations to mature.” This focus formed the mission of WitFoo and the battle cry for the revolution. Most revolutions fail because there is a myriad of devious factors stacked against them. Most Davids are murdered by Goliath. It is very rare for bold, underdog revolutions to succeed. We knew that even before we filed Articles of Incorporation. We knew to deliver sustainable, healthy change into a toxic market, we were going to have to have a set of plans resilient to the dangers and evils that existed.

Rock On

For the last 4-5 years of running with the WitFoo revolution, I have constantly had to defend our small team. In the early days, potential investors would remark, “You can’t get all this done with such a small team.” Now that we have accomplished building the product, the go-to-market strategy, have many happy customers we are still told, “I don’t see how you can get so much done with such a small team.” I want to respond with “that seems to be a problem with your ability to see since we’ve already done it and you are looking at it,” but I realize that is not going to help the situation.

In dealing with customers, analysts, partners and investors I am regularly faced with having to decide whether I should acquiesce and deliver what they want or try to teach them why they should change their minds and accept what I believe they need.

Slides of our talk can be downloaded here.

Details on the session are available here: https://exploitcon.com/#/west

WitFoo’s Global Indicator of Compromise feed is a secure and reliable way for the WitFoo community to share intelligence about emerging threat sources.

The feed is updated in near-real time as attacks occur across the WitFoo Community. It consists of the IP address and hostname of the attacking source, the tools and methods that the community is using to detect the threat and how many incidents the source has been a part of across the community.

Hits in the feed are automatically shared across the entire community and big data stacks of each deployment are retrospectively analyzed to find hits that may have been missed. All records including firewall, proxy, EDR and NetFlow records are checked for communications with the known bad indicators.

Slides for our talk at Secure360 2020 can be downloaded here.

Details on the session are posted here: https://secure360.org/session/charles-herring-metric-driven-secdevops/?conference=11809&date=20200505

Later today I am headed to see my surgeon to schedule a proceedure. I need to have a surgery that is going to leave me off my feet for a week or more. My family will have to pick up the slack at home and my co-workers will have to take on my share of the work. The surgery is disrupting to my life and carries with it a measure of enduring risk. The most troubling thing is it could have been prevented had I adopted some healthier habits earlier in life. An ounce of prevention is worth a pound of cure. 

Abstract

Developing software that changes the world, exceeds customer expectations, provides turn-key functionality in diverse scenarios while meeting security and compliance requirements is the holy grail of Security Development Operations (SECDEVOPS). There are thousands of variables that need to be constantly addressed to find the balance that delivers sustainable and secure success. In this session, WitFoo’s chief engineers will outline an innovative approach to secure devops called Metric Driven Development. It will cover the following topics:

From  IIA/ISACA IT Hacking Conference : Developing software that changes the world, exceeds customer expectations, provides turn-key functionality in diverse scenarios while meeting security and compliance requirements is the holy grail of Security Development Operations (SECDEVOPS). There are thousands of variables that need to be constantly addressed to find the balance that delivers sustainable and secure success. In this session, WitFoo’s chief engineers will outline an innovative approach to secure devops called Metric Driven Development. 

From DEFCON & GrrCON: Network Behavior Anomaly Detection (NBAD) and User and Entity Behavior Analytics (UEBA) are heralded as machine learning fueled messiahs for finding advanced attacks. The data collection and processing methodologies of these approaches create a series of new exploitable vectors that can allow attackers to navigate network and systems undetected. In this session, methods for poisoning data, transforming calculations and preventing alerts will be examined. Proof of concept code will be demonstrated and made available. Approaches to harden against these attacks will also be discussed as well as outlining needed changes in detection standards.

tldr; – Just Download the Spreadsheet

I put together an Excel spreadsheet that does all the calculations I am going to explain below. If you don’t need to know how the sausage is made, feel free to download it and plug in your numbers.Download here: ROI Calculator.xlsx

As I have had opportunity to demonstrate our product to cybersecurity veterans I am often asked “How did your very small team do this when larger, well-funded teams cannot?” It is true, the WitFoo development team has never been larger than 5 active members at any time and we have only had 10 contributors to the code-base. We don’t Frankenstein together open source code, we custom build it all. All told, our code consists of more than 4 million lines of proprietary code written by a handful of hard-hitting warrior developers. As we wrap our newest and grandest release, I’d like to share some insight into how we pulled it off.

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.

I am looking forward to speaking at the Georgia Annual ISSA Meeting on 11/15. The blog series that the talk is based on is below.

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.

Better detection mechanisms through algorithms (code) & machine learning (pattern recognition) are valuable tools to the human responders. Playbook Automation can reduce the routine and certain tasks an analyst must perform so she can focus on what is important.

Playbook automation collects data from different security and logging tools and makes decisions on behalf of the incident responder.

Computer scientists love the idea of artificial intelligence (AI). It is the centerpiece of many mainstream science fiction works. It’s also a preferred buzzword of lazy vendors and marketers. Until computers can convince (trick) a reasonable human being that they are living beings (Turing test) all claims of AI are misleading at best. In this installment, I won’t debunk the types of claims of AI. We will examine the difference between how computers and humans think and the implications of the differences.

When I was learning how to troubleshoot and repair electronics in the Navy, I would sometimes challenge one of the instructors on how something worked. If I delved into a complicated subject I was often told it worked on “FM” which meant f***ing magic. That rarely stopped me however, and I often found the concepts were not overly complicated, just not directly relevant to my training.

There is some FM in information security that I’d like to demystify as we examine how tools can enable and not hinder the craft. We’ll examine algorithms and machine learning in this installment.

Cybersecurity Incident Response has only been a part of human history for a couple of decades. Over the short course of time, industry leaders, analysts and vendors have put a heavy focus on the importance of technology solving problems within the craft. In this series, we will examine the preeminent importance of the craftsman over his tools and the role tools should play in making the world safer.

Learning Wit

Fail fast.  It’s one of the Agile buzz phrases that gets thrown around a lot in software product organizations these days.  Particularly, organizations trying to embrace the Lean/Agile approach to production.  The term ‘fail fast’ is grounded in the Lean concept of continuous learning.  Lean theory contends that learning is not a singular event, but rather a continuous process of trial and error.  The Lean approach advocates that the smaller the ‘set’ of learning and the faster it takes place, the better.  Thus, fail fast should really be ‘learn fast’ or ‘learn something small fast,’ but that’s not nearly as catchy.  This is all grounded in the heavily researched area of human learning.  Humans learn by trial and error.  Lean simply says so should the organizations.

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.

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.

A core tenet to success in any endeavor is defining, collecting and analyzing core metrics. Incident Response teams can only develop plans that lead to success when it can be defined and metered. Understanding and collecting two key metrics can aid in defining, metering and reporting on success.