Sideband and the Trouble That Wouldn’t Sit Still

An intermittent network fault is an excellent way to start an argument. The application slows down. Someone checks the network. By the time the right person is looking, everything appears perfectly respectable. A graph survives. An explanation does not. Sideband Networks built its early proposition around this awkward interval between something happening and somebody understanding it.

• The job: connect live traffic, historical records and a changing network map.
• The approach: observe copied traffic, analyze behavior, then help teams respond.
• The turn: by 2015, focus that observation on communications around critical assets.

This is a story about Sideband’s documented early products and its later security positioning. Its interesting idea was that knowing a network’s inventory was insufficient. You also needed to know what the occupants were doing, where they were doing it, and whether anyone could use that information before the moment had passed. A directory of addresses makes a poor detective.

01 / A network with an alibi

Sideband was founded in 2012 by Zane M. Taylor and Sherman Tang. Their intended buyer was refreshingly specific. Asked whom the company served, Tang replied, “the frustrated, overworked network administrator.” There was little romance in the job description. The attraction lay in making an unpleasant, recurring task less unpleasant.

The company’s own account of its early work emphasized live connectivity problems, particularly intermittent ones. It described looking across network layers 2 through 7, tying devices and applications to observed activity. In that account, earlier notice could sometimes help teams avert a connectivity failure. The operative word is sometimes. Prediction is a product ambition; it does not turn every failure into an appointment.

Its expertise came from people who had spent considerable time with infrastructure. Taylor’s published biography listed Cisco, Exodus Communications, NetScaler, Citrix and FireEye. Tang’s background included the design and manufacture of networking, security, server and storage systems. Those biographies help explain the choice of problem. The company was addressing the operational mess familiar to people who had lived with networks, rather than treating a network as an abstract collection of cables.

Observation supplies evidence. An alert asks for attention. An action changes the network.

The three decisions inside the product promise

02 / Watching from the sidelines

The name supplied a clue to the machinery. Sideband referred to out-of-band management. Its published SSP-1000 description specified passive deployment through a span, tap or mirror off a backbone or core switch. These arrangements provide a copy of traffic for observation. The observer can study the conversation without requiring every packet to travel through its appliance.

That choice matters to a buyer. A monitoring product has to be installed somewhere, and its usefulness depends on what that position lets it see. The published appliance pages also described agentless deployment and the option of combining multiple physical and virtual appliances for broader coverage. In practical terms, the architecture invited an enterprise to extend its observation across a distributed environment.

The visibility claim therefore has a physical condition attached. Traffic has to reach the observer. A copied stream that misses an important segment leaves a gap in the picture. This follows from the deployment arrangement; it is not a reported Sideband customer failure. The same distinction applies to capacity: the traffic an appliance can process is a constraint on what it can faithfully observe.

03 / Three verbs, a demanding promise

In a 2014 analyst brief, Enterprise Management Associates described Sideband’s approach as “Analyze Alert Act.” The appeal was the connection between monitoring and corrective controls. Proposed uses included restricting non-business traffic, adjusting quality-of-service settings for important applications and quarantining users whose activity suggested a policy problem. These were described capabilities and use cases, rather than a published tally of successful interventions.

A useful distinction hides inside those verbs. Observation supplies evidence. An alert asks for attention. An action changes the network. Each step needs a different kind of confidence. A product that moves between them has to connect a technical finding to an operational decision, including the possibility that the proposed response would inconvenience someone who was doing legitimate work.

Sideband occupied the meeting point of application-aware network performance management, topology discovery and controls. Its integration pitch also made commercial sense: let an organization keep existing tools while gaining a more connected view. The buyer already had investments, habits and people trained to use them. A new appliance had to earn a place among those commitments.

04 / The appliance ladder

The historical SSP pages presented three capacity levels. The virtual vSSP was advertised at 1 Gbps, SSP-1000 at 2 Gbps and SSP-2000 at 10 Gbps. The virtual product was pitched for highly virtualized environments and enterprises with multiple locations. Those are advertised processing rates, not independent benchmark results.

The business was a commercial enterprise-appliance business, offered in physical and virtual forms. An appliance ladder gives buyers a way to match a deployment to the traffic they expect to inspect. It also makes a demonstration more useful: a buyer can ask whether the candidate system sees the right conversations at the required rate, with enough detail to support an actual decision.

Sideband’s February 2014 Series A was reported at $6 million, with investors undisclosed in contemporary coverage. That figure describes capital raised, rather than the cost of developing a particular feature or installing a customer deployment. For a purchaser, a free trial and a financing announcement answer different questions. The meaningful economic test is what time, equipment and operating effort a deployment requires relative to the problems it helps resolve.

05 / The asset becomes the subject

By November 2015, Sideband’s overview put critical-asset protection at the center. The SBN series used network behavior analytics and machine intelligence to watch traffic to and from important assets and alert teams to unusual activity. The company described learning how typical behavior changes over time and adapting to dynamic environments, without requiring complicated threat-signature sets.

The change is visible in the product story. Earlier, the question concerned a network behaving badly. Later, it concerned communications around something an enterprise particularly wanted to protect. That is a narrower unit of attention and, potentially, a more useful one. The public descriptions establish the change in emphasis; they do not establish what private discussion caused it.

Sideband positioned this security product within defense in depth, integrating with existing security infrastructure. Its claim was an additional view of behavior around valuable assets. An unfamiliar connection might deserve investigation because it departs from a learned pattern. The departure is a clue, however, and its meaning still depends on context. A changed work process and an emerging threat can both disturb yesterday’s normal.

06 / Copy the question

The transferable lesson is practical. Pick the system that matters. Establish which communications you can actually observe. Learn its ordinary behavior. Decide who should investigate a departure, and which responses are safe to automate. Those steps turn a broad wish for visibility into an assignment that somebody can own.

Sideband’s story is useful wherever evidence arrives faster than explanations. Its proposed method depends on adequate traffic coverage, a meaningful baseline and a response path that the organization trusts. Where those conditions are absent, adding another alarm can add another task. The interesting promise was to shorten the distance between a packet, an explanation and a sensible next move. The network administrator had enough arguments already.