Of Assets and Threats

Richard Bejtlich responds to an earlier post - Protect the Transaction, which looked at two schools of counter insurgency - population centric and enemy centric. I really liked Richard's characterization, because it gets to some very important distinctions:

when monitoring, you can take a threat-centric or an asset-centric approach to monitoring insider threats. This is especially true when monitoring inside an organization. As I teach in my Network Security Operations class, threat-centric monitoring places sensors closer to the suspected intruders (rogue sys admins, curious call center workers, etc.) while asset-centric monitoring places sensors closer to valuable resources (source code repositories, payroll servers, etc.) Sometimes you can follow both approaches, but that usually ends up in a "monitor everywhere" style that can be cost- and operationally-prohibitive. Keep in mind that defenses are (or should be) collapsing around the item of value, which Gunnar calls the transaction. He and I would agree that data is the key resource, so resistance, detection, and response should focus on that element.

Second, in terms of threats and assets in general (i.e., "enemies" and "populations"), we as enterprise defenders can really only influence the asset or "population" variable. We address that aspect through design, architecture, secure coding, countermeasures, and so on. Only law enforcement or the military can address threats or "enemies" by prosecuting or eliminating them.

So a single monolithic "security model" like SSL, network firewalls, and a prayer, will not prepare your organization to offer security that deals with disparate needs of assets and threat environments. Rumsfeld's notion of known knowns, known unknowns, and unknown unknowns come into play here. Assets are by and large known known (after you get your paycheck and you can cash it right?) and known unknowns (we know corporate brand image is valuable, we don't know how much it would be affected by a data breach). The good thing about knowns is that they are on some level quantifiable and can be put into a rough order to facilitate planing, design, and so on.

Threats are much more in the known unknown (we know that launching SQL injection attacks is possible, we don't know if our input validation is good enough to catch the combinations the attacker sends), and unknown unknowns (what are all the attacks you can exploit on a client system via XSS?).

So making this all actionable, there is likely a blend of both asset centric and threat centric activities required for your organization to have a robust security model. Asset centric means, in part, shrinking the perimeter down to data and transaction level, because you cannot guess all the threats you face, and even if you could, you could not deal with them individually. The threat centric approach requires response, through actions like monitoring and detection, where Richard's work and training focus.