A Minimalist View of Security

Day to day, the things we do as security professionals can be pretty complex. From a control perspective, it is fairly common to take a product category-like view and work from there. But nowadays, the security functions being performed have all been defined and anything "new" really is a flavor of something we've already done (this is why those of us who've been in the industry for awhile lament that everything's been done before).

The resulting maturity of the security market creates a situation where thinking in terms of product categories becomes increasingly difficult as any new category feels vaguely familiar and existing categories extend into adjacent territory. In short, we spend a lot of time getting better at what we are doing, adapting to new technology, and improving deployment options more than we are fundamentally changing the rules of the security game.

It may be useful to have a set of "atomic security functions" that act as building blocks so that all other solutions can be shown to be combinatorial or derivative of these functions. All of these functions are inline - between source consumer and target provider.

Here's a start:

1. Authenticate
   • source (e.g. user | machine | program | message)
   • destination
2. Filter
   • source (e.g. access control based on source identity)
   • destination
   • traffic characteristics (non-deterministic)
3. Obfuscate (e.g. encrypt, usually)
4. Validate (e.g. check integrity of program | data | content)
5. Monitor (I am not convinced this one belongs, but have included it given our propensity to monitor. I think in the end, this is really another form of filter.)

I am not convinced this list is complete for inline functionality, so please feel free to offer up your own. When you think about it, it can be surprisingly difficult to factor out what we think we know about security functions, especially in the face of existing mature product categories.

Comments

Log.

[Amrit]

Gosh I wonder who in the world would have added "log"

[Pete Lindstrom]

@[blank]

There is no security benefit to logging in and of itself. It requires action. I think maybe "respond" could work, but I'll have to think about it - maybe "respond" is better than "monitor" and the two are the same. In some respects, logs are also inputs to filter events.

[Amrit]

I agree, I was just making fun of Dr. Log Chuvakin.