Are you deploying a private or public cloud solution or maybe in the planning stages? Of course you are. Or if you’re not, someone within your organization may already have started! In this particular blog posting, I will focus on cloud being deployed as Infrastructure as a Service (IaaS), which in the public setting would be Amazon EC2, Google GCE, or Microsoft Azure Virtual Machines. The equivalent private cloud vendors would be VMware and Microsoft’s Hyper-V. Disclaimer. There are MANY MANY more vendors in both private and public cloud spaces than I have listed. Please do not take the omission as a disregard of the excellent products and services other solutions offer.
Additionally, the fundamental technology which will be discussed (802.1AE/MACsec) in this blog post can be leveraged outside the cloud as well.
Growing up in Northeast Ohio, I was fascinated with all things “security”. In my youth, SNORT was on version 1.8 and I had just installed it up on a 133 MHz PC. I installed it to justify the creation of a security budget at my then employer at the time. The concerns over security quickly started to pile into our cubicles as we started to evangelize our security messaging.
As we started to express the need to inspect traffic inbound and outbound to the internet, folks were concerned about their privacy. The now defunct SSL 3.0 was just starting to gain traction and we noticed how useless our signatures had become on this subset of traffic.
These concerns directly coincide with the CIA triad of Confidentiality, Integrity and Availability. This triad existed then, and I would argue that it has even more usefulness and purpose today.
What I quickly learned back then was there was a need for balance. You can lock everything down with encryption, and immediately you hamper (note I did not say limit) your visibility into both integrity and availability. In the world of service triage, we must be able to understand historical trends to be able to define availability. The same is spelled for integrity, as we are unable to monitor and perform analytics on the user’s traffic.
MACsec aka 802.1AE
When MACsec was first presented to me, I immediately and foolishly thought it was some new Apple security applet. It is actually a data link (layer 2) level encryption which is increasingly being deployed in both private and public clouds. This functionality permits point-to-point encryption between pieces of network gear OR between hosts on the same network. MACsec is an ideal deployment option within the VXLAN space.
Layer 2 encryption gives a unique capability, where depending on the deployment methodology, could mean zero impact on the individual hosts. Server and security teams rejoice as they are now able to “break bread” together. All the while the NOC, monitoring teams, and problem solvers are scratching their heads on how this implementation impacts their monitoring tools.
Some, even within the very security teams recommending MACsec, start to question how the tools (which they likely bought after the last breach) will interface with this new world of confidentiality. The reality is that the common methodology of tapping network links and deploying aggregation switches is useless in this scenario.
So, if you use this method you just implemented a security strategy which ensures complete confidentiality from the risk of your cloud vendor snooping on your data. However, you have effectively locked out every other team and workflow utilized to ensure availability and ensure integrity.
How do we re-balance this scenario?
Service Triage of Yesterday, and Today
If you haven’t been keeping tabs on the service triage market place, you may have missed the significant developments this space is churning out. It once was a singular solution with only taps/spans going into hardware based probes. It then evolved into a bipedal approach with taps/spans feeding into aggregation switch manufacturers, which then fed monitoring solutions. For the past 5 years that approach was very successful for numerous vendors and customers.
The introduction of cloud forced the market place to rethink the service triage market. How do we implement the hardware solution based in probes and aggregation switch when our applications reside virtually inside the cloud? You simply cannot start deploying hardware inside Amazon, Google or Microsoft. As we begin to look at SDN and NFV deployments, the questions start outpacing the answers, and I haven’t even mentioned containers! The simple answer is we must go with a hybrid approach across the board to address these types of environments.
Once we define the problem we are attempting to solve, we can select the tools which can solve the said problem.
Hybrid Service Triage
As stated in the previous section we need to “call an audible” during the kick off of these projects. Covering the various network edges such as Internet, cloud connections (Direct Connect, Express Route, etc), WAN and MAN is a good start.
But to the point of this article, if we were to implement taps across our infrastructure which leverages MACsec, we would simply see large sums of indiscriminate traffic. So while we have the edge devices to understand network utilization of our finite network resources (Internet/WAN bandwidth), we need to deploy micro services inside our cloud environments to better define availability.
By deploying these micro services dedicated to service triage, we implement visibility prior to the encryption occurring. BINGO! But what about those security tools ensuring integrity?
Micro-Services Answers the Call of Enabling Integrity
Micro-services having direct access to raw packets, can either create smart-data for security tool consumption or even export traffic to the previously mentioned aggregation switches. That’s right, I said it! The micro-service can tunnel traffic back to your aggregation switches to your “ground locked” security tools.
So let’s take a step back for a moment. Your service triage tool set can take your traditional hardware based security tools, and “cloud enable” them!! This can be a HUGE budget slashing opportunity and cost savings. By deploying service triage solutions into the cloud, you have visibility into cloud application traffic that can be backhauled to your existing security solutions (on premise). The net win of this deployment is that you now have necessary visibility into the cloud traffic, AND effectively make “existing security tools” capable of seeing this traffic as well. Leveraging existing investments always yields a cost avoidance budget wise.