Date
$brainstorm = 1; // I reserve the right to contradict myself repeatedly and leave gaps.  you’ve been warned.

I want to combine my last posts, Cause and Effect and Clausewitz and DiD.  Indeed, it was originally one post that I chopped up in order to provide some focus to each topic.  My Cause and Effect post was attempting to make the connection that offense and defense operations are simply two forms of security operations.  I also want to clarify my stance of Friction and DiD (actually, tweak it a bit).  Let’s do that first:

friction : security operations :: defense in depth : security architecture
Defense in depth is a method of designing IT architecture in order to prevent bad things from happening.  I’m cool with that (though I believe it’s generally practiced fairly poorly and is unrealistic).
The idea of friction applies more to security operations.  Architecture can arguably be a subset of security operations at any given moment in time.  This mean friction applies at the technology level but it’s design is to work to the advantage of the security operations team and how the detect and respond.
I really wanted to coin my new term for the idea of applying friction and other novel concepts to security.  Ultimately, I believe all of that falls into the security operations umbrella.
I believe people wrongly categorize operations as being a component to a DiD strategy.  DiD is an architecture that ultimately outputs some degree of security.  Operations then must figure out how to  lower friction for defense and increase it for various opponent classes. In more concise terms, friction can be seen as  humans dealing with the architecture that they have been dealt with. Maybe they can overlap at a particular level, however DiD is the architecture; while operations is dealing with the output of the architecture. Applying the idea of friction, or operational superiority if you will, is an important mental construct.