The Self-Defeating Network

At the risk of adding yet more fuel to the fire, I'd like to share a few more thoughts on NSM. Although the title of this post is The Self-Defeating Network (SdN), I don't intend it to be a slam of Cisco's Self-Defending Network (SDN). Rather, the post's title demonstrates a probably lame attempt at branding an otherwise potentially boring issue.

Thus far I've tried to explain NSM, and the related concept of Defensible Network Architecture (originated in my Tao book, expanded in Extrusion), from the view of best practices. I've tried to say here's what you should do, because it gives you the best chance to survive on the mean streets of the Internet. In this post I'll take a different approach by describing the Self-Defeating Network -- what you should not do if you want to have a chance to defend your enterprise.

These are the characteristics of the Self-Defeating Network (SdN).

1. The SdN is unknown, meaning no one really understands how it works. There is no complete, current inventory of all infrastructure, hosts, services, applications, and data. No one knows what patterns of activity are normal, or which are suspicious or malicious. One cannot defend what one does not understand.


2. The SdN is unmonitored, which results in trust without verification. Those using the SdN trust the integrity, confidentiality, and availability of information resources but have no idea if their trust is well-placed. (Here's a hint: it's not.)


3. The SdN is uncontrolled, which means anything goes -- including suspicious and malicious traffic. Security is seen as an impediment and not a requirement, and as a result the enterprise is actually less capable of providing resources than one which is controlled. The uncontrolled environment also makes monitoring exceptionally difficult because no policy exists saying what is allowed and what is disallowed.


4. The SdN strives to be unmanned (i.e., to reduce headcount to zero), because products, not processes and people, are perceived as the "solution." Sadly enough one could argue this aspect of the SdN is shared by the SDN. For an explanation of why people are necessary, please read Hawke vs the Machine.


5. In addition to (mis)placing trust in an untrustworthy network, the users of the SdN also (mis)trust their products to provide alert-centric warnings when "bad things happen." If no alerts are sounded, SdN users assume everything is fine.
   
   A friend described a case of this approach taken to the extreme, when a large company paid a MSSP for three years of service, during which no alerts were ever raised. After paying several hundred thousand dollars, the company realized the MSSP misconfigured the SPAN ports feeding the MSSP sensors. For three years no trafic was inspected so the MSSP reported nothing. The MSSP wrote a big refund check.
   
   Hint on a future post: this is also the problem with log-centric detection methods. The absence of logs does not indicate an absence of problems. An absence of network traffic, however, does at least indicate an absence of remote connectivity with a suspected victim computer. Obviously an absence of network traffic does not preclude physical problems like stealing data via USB token.

Eventually I'll take all the notes I write in the wee hours of the night into blog posts. For now that's all!