Enemy-Centric vs Population-Centric Security
Gunnar Peterson pointed me to a great blog post he wrote called Protect the Transaction. He quotes Dave Kilcullen's post Two Schools of Classical CounterInsurgency, which discusses the difference between “enemy-centric” and “population-centric” counter-insurgency operations.
I consider two responses to these posts. First, 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.
I consider two responses to these posts. First, 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.
Comments
http://www.joeyoder.com/papers/patterns/Security/appsec.doc
Couldnt find a none word version (sorry)
http://1raindrop.typepad.com/1_raindrop/2006/02/systempunkt_in_.html
What I like about RIchard's asset and threat characterizations is that you can plan, design, and execute differently for each concern.