Are you looking for Embrane Flow Reporting Support? When we heard about the acquisition of this company by Cisco, we immediately looked into how we can report on the flow details generated by their system.
If you haven’t heard of Embrane, they claim that their Application-Centric Network Security Solutions deliver better security for your network. They believe that their system can make your applications faster and that they can do it for less money than conventional security products.
What’s interesting about the Embrane approach is their claim to dedicate an internal firewall (virtual) to each application. Their heleos-powered firewalls support the ability to add or delete firewall rules as needed with no impact on the other applications. They claim that this strategy avoids the issues many enterprises face in regards to “the massive explosion of firewall rules”. Specifically, the issues that can arise when “it is unclear what impact eliminating rules might have on other applications”. Embrane’s approach is to have less rules on the firewall but, more firewalls to administer. Additional firewalls isn’t a problem because “heleos enables network security professionals to create firewalls in seconds with a single tool.” Rather then purchase additional firewalls, their claim is that additional heleos firewalls are less money (50% less), run on standard servers and require less time to setup. Seems smart and I’m sure we’ll learn more as our customers roll it out in their environments.
As most of you know, we can already export NetFlow or IPFIX data natively from most operating systems including VMware. Embrane however, takes an API approach to flows. As a platform specifically designed for the cloud, Embrane flow reporting requires working with their RESTful APIs for heleos DVAs as well as the heleos ESM. Their API also allows our Network Incident Response System to report on syslogs and many real-time metrics. It could also allow our system to participate in change management.
Below you can see that the flow details available don’t yet rival Cisco AVC reporting but, don’t despair as Embrane Flow Reporting is still in its infancy.
In the image above, we see fields like:
- entries.flow.original.source.ipAddress
- entries.flow.original.source.port
- entries.flow.original.destination.ipAddress
- entries.flow.original.destination.port
- entries.flow.mapped.source.ipAddress
- entries.flow.mapped.source.port
- entries.flow.mapped.destination.ipAddress
- entries.flow.mapped.destination.port
Notice that you don’t see ‘properties’ related to interface. This missing detail will cause problems for many flow reporting solutions but, not ours. We made provisions for this years ago. Even so, most of the details above map to existing NetFlow and IPFIX elements which means our existing reports will provide 100% of the Embrane flow details.
The Embrane API support or approach to flow reporting is not new to us. We started using similar approaches years ago to report on Microsoft event logs and recently to integrate with the Cisco ISE API. If you would like to reporting on Embrane flow details, give our team a holler to try our network incident response system.