Setting Sail on Secret Seas with Trireme

trireme-b

Container networking is a tough challenge to solve. The evolving needs of creating virtual networks to allow inter-container communications is difficult. But ensuring security at the same time is enough to make you pull your hair out. Lots of companies are taking a crack at it as has been demonstrated recently by microsegmentation offerings from Cisco, VMware NSX, and many others. But a new development on this front set sail today. And the captain is an old friend.

Sailing the Security Sea

Dimitri Stiladis did some great things in his time at Nuage Networks. He created a great overlay network solution that not only worked well for software defined systems but also extended into the container world as more and more people started investigating containers as the new way to provide application services. He saw many people rushing into this area with their existing solutions as well as building new solutions. However, those solutions were all based on existing technology and methods that didn’t work well in the container world. If you ever heard someone say, “Oh, containers are just lightweight VMs…” you know what kind of thinking I’m talking about.

Late last year, Dimitri got together with some of his friends to build a new security solution for containers. He founded Aporeto, which is from the Greek for “confidential”. And that really informs the whole idea of what they are trying to build. Container communications should be something easy to secure. All the right pieces are in place. But what’s missing is the way to do it easily and scale it up quickly. This is where existing solutions are missing the point by using existing ideas and constructs.

Enter Trireme. This project is an open source version of the technology Aporeto is working on was released yesterday to help container admins understand why securing communications between containers is critical and yet simple to do. I got a special briefing from Dimitri yesterday about it and once he helped me understand it I immediately saw the power of what they’ve done.

In The Same Boat

Trireme works by doing something very simple. All containers have a certificate that is generated at creation. This allows them to be verified for consistency and other things. What Trireme is doing is using a TCP Authorization Proxy to grab the digital identity of the container and insert it into the TCP SYN setup messages. Now, the receiving container will know who the sender is because the confirmed identity of the sender is encoded in the setup message. If the sender is authorized to talk to the receiver the communications can be setup. Otherwise the connection is dropped.

This is one of the “so simple I can’t believe I missed it” moments. If there is already a secure identity setup for the container it should be used. And adding that information to the TCP setup ensures that we don’t just take for granted that containers with similar attributes are allowed to talk to each other just because they are on the same network. This truly is microsegmentation with the addition of identity protection. Even if you spin up a new container with identical attributes, it won’t have the same digital identity as the previous container, which means it will need to be authorized all over again.

Right now the security model is simple. If the attributes of the containers match, they are allowed to talk. You can setup some different labels and try it yourself. But with the power behind using Kubernetes as the management platform, you can extend this metaphor quite a bit. Imagine being able to create a policy setup that allows containers with the “dev” label to communication if and only if they have the “shared” label as well. Or making sure that “dev” containers can never talk to “prod” containers for any reason, even if they are on the same network. It’s an extension of a lot of things already being looked at in the container world but it has the benefit of built in identity confirmation as well as scalability.

How does Trireme scale? Well, it’s not running a central controller or database of any kind. Instead, the heavy lifting is done by a local process on the container. That’s how Trireme can scale. No dependency on a central process or device failing and leaving everyone stranded. No need to communicate with anything other than the local container host. Kubernetes has the infrastructure to push down the policy changes to processes in the container which are then checked by the Trireme process. That means that Trireme never has to leave the local container to make decisions. Everything that is needed is right on deck.


Tom’s Take

It took me a bit to understand what Dimitri and his group are trying to do with Trireme and later with their Aporeto solution. Creating digital signatures and signing communications between containers is going to be a huge leap forward for security. If all communications are secured by default then security becomes the kind of afterthought that we need.

The other thing that Aporeto illustrates to me is the need for containers to be isolated processes, not heavy VMs. By creating a process boundary per container, Trireme and other solutions can help keep things as close to completely secure as possible. Lowering the attack surface of a construct down to the process level is making it a tiny target in a big ocean.

Advertisements

Will Cisco Shine On?

Digital Lights

Cisco announced their new Digital Ceiling initiative today at Cisco Live Berlin. Here’s the marketing part:

And here’s the breakdown of protocols and stuff:

Funny enough, here’s a presentation from just three weeks ago at Networking Field Day 11 on a very similar subject:

Cisco is moving into Internet of Things (IoT) big time. They have at least learned that the consumer side of IoT isn’t a fun space to play in. With the growth of cloud connectivity and other things on that side of the market, Cisco knows that is an uphill battle not worth fighting. Seems they’ve learned from Linksys and Flip Video. Instead, they are tracking the industrial side of the house. That means trying to break into some networks that are very well put together today, even if they aren’t exactly Internet-enabled.

Digital Ceiling isn’t just about the PoE lighting that was announced today. It’s a framework that allows all other kinds of dumb devices to be configured and attached to networks that have intelligence built in. The Constrained Application Protocol (CoaP) is designed in such a way as to provide data about a great number of devices, not just lights. Yet lights are the launch “thing” for this line. And it could be lights out for Cisco.

A Light In The Dark

Cisco wants in on the possibility that PoE lighting will be a huge market. No other networking vendor that I know of is moving into the market. The other building automation company has the manufacturing chops to try and pull off an entire connected infrastructure for lighting. But lighting isn’t something to take lightly (pun intended).

There’s a lot that goes into proper lighting planning. Locations of fixtures and power levels for devices aren’t accidents. It requires a lot of planning and preparation. Plan and prep means there are teams of architects and others that have formulas and other knowledge on where to put them. Those people don’t work on the networking team. Any changes to the lighting plan are going to require input from these folks to make sure the illumination patterns don’t change. It’s not exactly like changing a lightbulb.

The other thing that is going to cause problems is the electrician’s union. These guys are trained and certified to put in anything that has power running to it. They aren’t just going to step aside and let untrained networking people start pulling down light fixtures and put up something new. Finding out that there are new 60-watt LED lights in a building that they didn’t put up is going to cause concern and require lots of investigation to find out if it’s even legal in certain areas for non-union, non-certified employees to install things that are only done by electricians now.

The next item of concern is the fact that you now have two parallel networks running in the building. Because everyone that I’ve talked to about PoE Lighting and Digital Ceiling has had the same response: Not On My Network. The switching infrastructure may be the same, but the location of the closets is different. The requirements of the switches are different. And the air gap between the networks is crucial to avoid any attackers compromising your lighting infrastructure and using it as an on-ramp into causing problems for your production data network.

The last issue in my mind is the least technically challenging, but the most concerning from the standpoint of longevity of the product line – Where’s the value in PoE lighting? Every piece of collateral I’ve seen and every person I’ve heard talk about it comes back to the same points. According to the experts, it’s effectively the same cost to install intelligent PoE lighting as it is to stick with traditional offerings. But that “effective” word makes me think of things like Tesla’s “Effective Lease Payment”.

By saying “effective”, what Cisco is telling you is that the up-front cost of a Digital Ceiling deployment is likely to be expensive. That large initial number comes down by things like electricity cost savings and increased efficiencies or any one of another of clever things that we tell each other to pretend that it doesn’t cost lots of money to buy new things. It’s important to note that you should evaluate the cost of a Digital Ceiling deployment completely on its own before you start taking into account any kind of cost savings in an equation that come months or years from now.


Tom’s Take

I’m not sure where IoT is going. There’s a lot of learning that needs to happen before I feel totally comfortable talking about the pros and cons of having billions of devices connected and talking to each other. But in this time of baby steps toward solutions, I can honestly say that I’m not entirely sold on Digital Ceiling. It’s clever. It’s catchy. But it ultimately feels like Cisco is headed down a path that will lead to ruin. If they can get CoAP working on many other devices and start building frameworks and security around all these devices then there is a chance that they can create a lasting line of products that will help them capitalize on the potential of IoT. What worries me is that this foray into a new realm will be fraught with bad decisions and compromises and eventually we’ll fondly remember Digital Ceiling as yet another Cisco product that had potential and not much else.

Backdoors By Design

I was listening to the new No Strings Attached Wireless podcast on my way to work and Andrew von Nagy (@revolutionwifi) and his guests were talking about the new exploit in WiFi Protected Setup (WPS).  Essentially, a hacker can brute force the 8-digit setup PIN in WPS, which was invented in the first place because people needed help figuring out how to setup more secure WiFi at home.  Of course, that got me to thinking about other types of hacks that involve ease-of-use features being exploited.  Ask Sarah Palin about how the password reset functionality in Yahoo mail could be exploited for nefarious purposes.  Talk to Paris Hilton about why not having a PIN on your cell phone’s voice mail account when calling from a known number (i.e. your own phone) is a bad idea when there  are so many caller ID spoofing tools in the wild today.

Security isn’t fun or glamorous.  In the IT world, the security people are pariahs.  We’re the mean people that make you have strong passwords or limit access to certain resources.  Everyone thinks were a bunch of wet blankets.  Why is that exactly?  Why do the security people insist on following procedures or protecting everything with an extra step or two of safety?  Wouldn’t it just be easier if we didn’t have to?

The truth is that security people act the way we do because users have been trying for years to make it easy on themselves.  The issues with WPS highlight how a relatively secure protocol like WPA can be affected by something minor like WPS because we had to make things easy for the users.  We spend an inordinate amount of time taking a carefully constructed security measure and eviscerating it so that users can understand it.  We spend almost zero time educating users about why we should follow these procedures.  At the end of the day, users circumvent them because they don’t understand why they should be followed and complain that they are forced to do so in the first place.

Kevin Mitnick had a great example of this kind of exploitation in his book The Art of Intrusion.  All of the carefully planned security for accessing a facility through the front doors was invalidated because there was a side door into the building for smokers that had no guard or even a secure entrance mechanism.  They even left it propped open most of the time!  Given the chance, people will circumvent security in a heartbeat if it means their jobs are easier to do.  Can you imagine if the US military decided during the Cold War to move the missile launch key systems closer together so that one man could operate them in case the other guy was in the bathroom?  Or what if RSA allowed developers to access the seed code for their token system from a non-secured terminal?  I mean, what would happen if someone accessed the code from a terminal that had been infected with an APT trojan horse?  Oh, wait…

We have been living in the information age for more than a generation now.  We can’t use ignorance as an excuse any longer.  There is no reason why people shouldn’t be educated about proper security and why it’s so important to prevent not only exposure of our information but possible exposure of the information of others as well.  In the same manner, it’s definitely time that was stop coddling users by creating hacking points in technology deemed “too complicated” for them to understand.  The average user has a good grasp of technology.  Why not give them the courtesy of explaining how WPA works and how to set it up on their router?  If we claim that it’s “too hard” to setup or the user interface is too difficult to navigate to setup a WPA key, isn’t that more an indictment of the user interface design than the user’s technical capabilities?

Tom’s Take

I resolve to spend more time educating people and less time making their lives easy.  I resolve to tell people why I’ve forced them to use a regular user account instead of giving them admin privileges.  I promise to spend as much time as it takes with my mom explaining how wireless security works and why she shouldn’t use WPS no matter how easy it seems to be. I look at it just like exercise.  Exercise shouldn’t be easy.  You have to spend time applying yourself to get results.  The same goes for users.  You need to spend some time applying yourself to learn about things in order to have true security.  Creating backdoors and workarounds does nothing but keep those that need to learn ignorant and make those that care spend more time fixing problems than creating solutions.

If you’d like to learn more about the WPS hack, check out Dan Cybulsike’s blog or follow him on twitter (@simplywifi)