The traditional security model has put significant emphasis on what’s typically called the ‘external edge’. That is, the connection between your network and any third party network. This is also where we create a delineation between ‘trusted’ and ‘untrusted’ networks. Regardless of how you define this boundary, it becomes the focal point for any security related tooling. This creates some interesting challenges…
Scale – Applying security tooling at the external edge introduces some possible scale concerns. You now have a single point in the network has to scale to provide connectivity and security services to all of the users and applications. While this might make sense in smaller networks, aggregating everything in one place on larger networks can be challenging. Considering that many security tools can handle significantly lower amounts of traffic than routers and switches, you may find that doing this all in one place introduces a bottleneck in the network. Scaling security appliances is often a much larger task than scaling network links.
Network magic – I often joke that network engineers have to perform network magic to get all of the security tools all of the traffic they want to see. The security industry is booming right now with thousands of different vendors offering new and different security tools. Even if you wanted to, you couldn’t possibly implement them all. This sprawl has made dedicated packet broker networks that manage spanning traffic to all of these tools almost a requirement in modern networks. To make matters more interesting, many of the newer tools are deployed ‘inline’ making the network engineering piece of this considerably harder.
Trust vs. Untrusted – The external edge model makes a clear delineation between what networks are considered trusted and which are considered untrusted. Given that the majority of the major attacks and data breaches we read about originate from inside the company (from the ‘trusted’ network), we need to change this model. Considering everything on your internal network 100% completely secure is no longer entirely possible.
It’s pretty clear we can’t continue focusing solely on the external edge of the network. So where do we go from here?
Enter Skyport Systems and their SkySecure computing platform. Skyport sells hardened servers which are the building blocks for your virtual machine infrastructure. But it’s much more than just servers running virtual machines, it’s an entire security platform. So how is this different than any other server running a hypervisor?
Secure Hardware – The system is built from the ground up to be entirely secure. The system is split into two halves, an x86 system and a security co-processor. Each half has its own dedicate TPM (Trusted Platform Module) which measure system registers of each hardware component. When the system boots, it calls home and checks the current measurements against known good values. If the measurements check out, the system is allowed to start its secure boot process. Once the system boots, the hardware measurements are continually taken to ensure the system hasn’t been tampered with.
Security I/O Co-Processor – The security co-processor offloads much of the security related tasks from the x86 half of the system. It has a 40 gig flow processor and is the connection point for the system to the network. This is a unique piece of hardware built by Skyport systems and allows much of the security related tasks to stay off of x86 compute.
Security Model – Each VM in the system is described as being it’s own individual DMZ. As VMs boot on the system, each instance is given it’s own dedicated instance of the NIC. There are no vSwitches or port-groups for VMs to talk directly to each other. Each VM has to transit the security co-processor to get to another VM on the same system. Additionally, Skyport defaults to a zero trust model. That is, VMs can’t talk to anything without explicit rules allowing the communication.
Management – The Skysecure compute nodes are managed through a cloud based secure portal which makes the system largely plug and play. In addition to management, the portal also provides a secure data warehouse which exists for the lifetime of a system. This provides an important feature – full accounting and auditing. This means that everything from administrative tasks to attacks on the system can be reported on and correlated. The portal is also designed to support multi-tenancy right out of the box.
Applications Proxies – The system itself provides service proxies for common protocols that need to go off box. These proxies cover everything from crypto to active directory and allow the system to shield the VMs from any possible protocol misuse.
All of these components (and much more) make Skyport the first of it’s kind. There are some obvious benefits to this type of infrastructure. From a network perspective, it helps reduce the need for ‘network magic’ by including many of the security tools directly into the compute platform. The use of the security co-processor makes this almost entirely transparent to the x86 compute. It also helps manage security scaling. If the controls Skyport delivers meet your security requirements, you can consider excluding server traffic from inspection on your external edge. In some scenarios ,like DMZs, the Skyport system may in itself provide the majority of the security controls required.
However, as with any new technology, there will be some concerns…
Correlation – While I believe Skyport does a great job of correlating data between all of their tools on box, this will likely not entirely replace your security toolset. This means that we still have the problem of correlating data between all the other disparate security systems. While this is not Skyport’s problem, their system is another portal and another system that needs to be added to the mix.
Compute – For Skyport to work well, it requires custom hardware. The trend today has been to move to more ‘open’ compute platforms that are more generic in nature. The reasoning for this trend has been mostly around cost. The tradeoff between open compute and Skyport is likely obvious – cost vs inherent security. In addition, Skyport doesn’t sell you the systems. The servers are leased and Skyport takes care of refreshing the hardware over time making sure you don’t get stuck with out dated proprietary hardware.
Brand familiarity – While I’ll be the first to admit this is wrong, lots of us are prone to brand preference. While there are many reasons for this, one of the big problems is that we usually have a lot of time and money committed to incumbent products. I expect most security experts will want to see comparisons between the service Skyport offers and competitive products.
All in all, I think Skyport is offering a turn key secure compute platform. Many of the features they offer are the first of their kind in this space and the culmination of all of these tools on on box is more than appealing. If you’re looking for more information on Skyport, I recommend you check out the following videos…
Thank you for this description of what we do at Skyport, you really captured well our value proposition. Two things I would add to the mix:
1) We support packet-mirroring and encapsulated packet-mirroring on a per-VM and per-VM-policy basis: this lets us integrate with external tools without using a dedicated packet broker or passive taps – saving considerable cost.
2) We absolutely agree that we need to be able to get the data we harvest ‘off’ of our system and into a customers SIEM system or other log analysis platform. This is key to integrating into the existing enterprise and not replacing wholesale toolsets people know how to use. It does let us correct one rather gaping hole in the entire SIEM space though – we can prove that the logs received by the SIEM are exactly the logs generated and have not been modified or ‘trimmed’ before being sent.
dg
Great additional points. The per VM packet mirroring capability is a major win on both the cost and complexity side of things.
It’s nice to see that Skyport has already addressed many of the common operational issues that can surface during product integration.
Thanks for chiming in!
Pingback: Skyport Systems – Moving the Edge - Tech Field Day