Older: 
Some Q&A Catch Up
Location: Flying to Las Vegas for Interop
First, my apologies for being quiet for a while. Had a crazy two weeks that required me to do my full-time job much more than full time.
While I have a number of topics in the queue, I wanted to take a run today at a few of the comments and questions that emerged from my Security post.
Here’s a few that capture the tone of the dialog:
- Many wrote “…Where would you put security to insure payload integrity?”
- BigBaadBob wrote “Actually, the thing I think is MOST forgotten is that the threat models are fundamentally different from those in the past scenarios you cite.”
- LSC wrote “The transport network should be concerned with connectivity, Quality of Service and protecting the integrity of the network itself (as opposed to trying to protect the endpoints: users, devices and applications) - but maybe that is exactly what you refer to as ‘network security’.”
I love this kind of dialog, where we begin to see that the word “Security” is a complex and fundamental topic that is not solved by a silver bullet of any single technology. In the communications environment, for us to achieve any realistic security posture we must look holistically at the problem to find the solution. I won’t offer a silver bullet (see above…none exists), but I would like to take a few minutes to expand on some of the comments and ideas in the dialog.
A few years ago, I spent a lot of time talking to people about how to address security in the context of compliance with various laws and regulations that existed at the time. One thing I found was that if you tried to address any specific compliance obligation (SOX, HIPAA, GLB, …), you would find that although you solved for that law, because your networking systems were actually common, used to transport all data, they were impacted by multiple laws and needed to support a wide range of compliance obligations simultaneously. In many cases, companies that did exceptional jobs addressing one obligation created systems and solutions that were mutually exclusive of the solution needed for the next obligation. What came out of that dialog was that the better approach to dealing with compliance was to focus on the primitives or core needs that were shared by all of these laws (super or sub set).
In order to achieve an acceptable compliance posture from a networking perspective, the model I talked about back then was that you should focus on achieving the following three capabilities:
- Message Integrity – Assure that the parties involved are trusted and that the message has not been modified in transit nor is it malicious.
- Message Assurance – Assure that in the presence of the unknown event (virus, worm, hacking, DDoS…) that the message is delivered.
- Message Privacy – Assure that the message is visible to the parties that need to see it and masked from those who do not.
What was interesting with this model is that if you focused on these capabilities you could meet the spirit and intent of HIPAA and SOX and other laws over the same communications network. The reuse of solving for these issues was quite high and, over the years that I was positioning this approach, new standards and regulations emerged that did not break the model.
While communications security is clearly an ongoing process and the security threat model evolves as the risk profile and opportunity/targets change, there are clearly some elements of a security strategy that create a strong reusable foundation. If we take the three capabilities above (which I think I started talking about in the late 1990’s), are they still at the center of security? My opinion is yes. If we have an ability to trust and know who is using the system and originating communications, if we are able to protect the delivery of critical traffic, and if we can protect the privacy of data in transit, we are in a pretty good position in today’s world.
So what should we use today to do this? And, where should it be optimally placed?
Decomposing the three capabilities, let’s start with message integrity. Today, we as an industry fail to grasp that access control is an expectation but not a reality in the communications network. While protocols such as EAP, 802.1X and others exist and are available in almost all communications systems, they are still not widely deployed. To achieve integrity in our systems, a great step would be to control access. Simply keeping unauthorized devices off, or at least actively controlling them, is a huge security capability. Moving up the stack, having some degree of authenticity checking in the message allows for end-to-end integrity service. The Auth header in Internet Protocol is a good first step, and although it is mostly being advocated as part of IPv6, it could be applied to the IPv4 world with little effort. Using encryption methods for integrity checking is another good tool, as is simply protecting the links in our interconnect with MACsec or other link layer security methods. Although any or all of these approaches is correct, clearly integrity is easier to achieve if the communications system participates and, in some cases (with unintelligent end systems), is the only way to deliver these services.
The second one is message assurance, which is a function of the network. I have had my share of debates over the “end point security versus network security” dialog. One camp says the network is a dumb pipe; the other says it must be intelligent. When dealing with message integrity or even privacy, the network may, in fact, be somewhat optional. In the case of message assurance, however, the network is critical. If the network cannot assure that critical traffic is delivered in all cases, then the applications and associated business services fail. For message assurance, the technology is about creating a capability where the system can recognize classified traffic and act to assure some traffic while other traffic degrades. I sometimes call this negative QoS.
To use QoS for security, you must classify traffic into at least three buckets: the known good; the known bad; and the unknown. The known good are applications or systems that must always work and do so in a predictable manner. Use QoS to assure that that behavior is present even when other traffic exists out of profile. The known bad are the applications and traffic that are either known threats (block proactively) or are known to behave in a manner that is likely to be high risk. In the late 1990’s, peer-to-peer sharing technology was this class of traffic. Highly likely to be exploited but could have legitimate uses. Instead of simply treating it as low priority or filtering it, the approach was to classify it, make it low priority and also cap the acceptable levels of traffic in this class. The unknown is everything else that could traverse your network. These are the applications that you either do not understand or cannot predict. They may emerge as known good or bad but exist as unknown prior to that moment. In dealing with the unknown, it is critical to bound the behavior so the known good is never affected. It is also critical to monitor that space and have the ability to reclassify such traffic into the known bad when thresholds are met. Usually the best place to use security analyses tools - such as IDS, IPS, NBAD (Network-Behavior Anomaly Detection) - is in this class of service.
There are other technologies that also assist in assurance. Fast failover technologies such as SMLT, 802.1s and even PBT and RPR help in this effort of recovery, as do hardware high availability, software fast recovery, L4-7 technologies and geo-redundancy and replication. What is clear is that if the network is a dumb pipe, every application using that network is at risk of security failure simply by disruption of the network transport or saturation of a link. If the network is involved, then assurance is possible and likely.
Last is message privacy, which is as foundational as the other two. This capability is about assuring that only the intended recipient can read the message. At a high level, good strong encryption is the key technology here. A strong encryption model will go a long way to assuring that communications over a common network or the Internet is private. There are other aspects to this, though, that are part of the lower level stack. A great example is the use of gratuitous ARP messages to redirect traffic in switched networks. A tool called Ettercap makes this kind of attack simple.
If the network is unintelligent and does little to protect itself from misuse of control protocols, the ability to steal sessions, grab messages and eavesdrop becomes much more likely. Countering this is not a function of just encryption between end points. It is best addressed by having a networking system that utilizes techniques that control unauthorized access, suppress misuse of control protocols (for example, it is pretty obvious that a device sending a million ARPs in a short timeframe is not normal but most networks do little to detect or suppress even such gross misuse), and protect the very composition of the network (using mutual authentication of network links or using authentication for routing updates). The key is that achieving a strong data privacy posture, just like achieving the other two areas, is an effort of the IT system and that includes a robust integrated security capability in the network itself.
The questions raised in the dialog reflect the reality of security: it is a journey, not a destination. In order to survive that journey, we need tools and strategies to use those tools that optimize our effectiveness. In my original post, the key take away was that if we fail to engineer our systems to be an inherent asset to the overall security capability, then they are likely to become a liability to that same strategy. That liability could be through inaction or through overly complex and overly costly layered and random security technology adoption.
Simplicity and elegance trumps complexity in every dialog and, in security, the simplicity advantage of an inherent capability is clear.
