We released v3.6 of our MTD software a little over a month ago. This release brings many long-awaited features to our MTD appliances, mainly: targeting the Managed Service Provider (MSP) market. The most prominent improvement, multi-tenancy, has so far been well-received by our customers and partners. In this post, we elaborate on the concept of multi-tenancy, as well as the various features that we have integrated into our detection, notification, and reporting processes.
What is Multi-Tenancy?
In a nutshell, multi-tenancy allows for the separation of users/customers in terms of accounts, data, and alerts, using one appliance. So instead of requiring one appliance per entity, organizations are now able to serve multiple entities with a single appliance. In which situations is this useful? In many. Think about the MSP market, where hundreds of small-business customers may be served with just a single MTD appliance. Or the multi-national that wants to monitor all his branch offices from his headquarters in New York.
Technical Description of Multi-Tenancy
Private IP addresses, such as the typical RFC 1918 ranges, are only unique per observation point; when observing multiple traffic flows with a certain source IP address, there is no way to conclude whether they have been generated by the same host, or by different hosts with the same address in different networks. At least, without any prior knowledge of the network topology and configuration. The consequence is that a host that is being monitored by the RedSocks MTD is only unique within the scope of a certain data source or observation point. That is exactly the reason why we added the concept of flow data sources to our detection process, namely to isolate hosts within their data source. Do you see why this is a huge step forward for RedSocks services providers, who facilitate a RedSocks MTD-as-a-Service to their customers?
Flow Data Sources
Key to our multi-tenancy release is the concept of flow data sources. These data sources are identified by the following tuple of attributes:
- Exporter IP address: The IP address of a flow exporter (e.g. RedSocks Probe) from which data is received, from the point of view of the MTD. We are working hard to make our MTD appliance fully IPv6-aware. The exporter IP address is therefore always shown in IPv6 format.
- Observation domain ID (ODID): The unique identifier/number that typically represents a flow exporter’s monitoring interface. For example, on RedSocks Probes, the first monitoring interface carries ODID 1, the second interface ODID 2, and so on.
You will find information on data sources all over our MTD appliance: together with alerts in our Web interface, as well as in Syslog and email notifications. For a detailed specification of the notification formats after inclusion of data source information, we can refer to our MTD release notes.
Handling Alerts that Feature no Data Source Information
Alerts that were available on the MTD prior to our v3.6 release carry no data source information. We therefore migrate such alerts to ensure they do, in the following way:
- We use a default exporter IP address: 100::. This is a special-purpose IPv6 address that should be discarded by your upstream router.
- ODIDs will feature a default value of 0.
In short: you can now identify pre-v3.6 alerts by their data source.
Over the coming weeks, we will release a major update to our v3.6 branch: v3.6.1. This release will carry a large number of improvements. The most prominent improvement? Support for the Common Event Format (CEF) over Syslog.
Written by: Rick Hofstede, Product Manager RedSocks Security