Network Integration Guide › About Network Integration › Choosing a Deployment Architecture › Connected Inline with a Network: Active and Passive Modes

Connected Inline with a Network: Active and Passive Modes

The diagram below summarizes the NBA deployment architecture when the NBA is connected inline with the monitored network, and also when data is output via a socket connection.

Using this configuration, the NBA can run in either active or passive modes.

In passive mode:

• The NBA cannot actively block network events.
• The NBA cannot decode SSL sessions.

In active mode:

• The NBA can actively block network events. The NBA blocks events by not passing packets across the Internet boundary, closing network sessions, or communicating at a protocol level with applications either side of the Internet boundary.
• The NBA can decode SSL sessions and detect files and emails in them.

To allow real-time analysis of network events in active mode, connect the NBA via the Socket API to policy engines. This allows CA DataMinder to apply policy to data streams to determine whether they need to be blocked.

Example Architecture: Active Mode

In this example, data packets destined for the Internet pass through switch 1. From here, these packets pass through the NBA, are reassembled into files and emails, and passed to policy engines for processing.

When policy processing is complete, any resulting ‘block’ or ‘allow’ actions are returned to the NBA. If permitted, the NBA then forwards data packets from paired ports on the back of the device, via the firewall, to their intended Internet destination.

Example architecture: Output to socket connection, Active mode

1. Switch: Data packets passing through the switch from your corporate network to the Internet are directed via the NBA Data Inspection ports.
2. Network traffic: Replicated data packets containing emails, Webmails, files and IM conversations are passed to a receiving data port on the back of the appliance (for example port s0.e0 on a Bivio appliance and port 1 on a Linux server).
3. NBA: This hosts the NBA console (3a) and the nbapolicy.xml policy file (3b). The NBA reassembles the incoming data packets into emails and files and passes them to policy engines (6) for processing.

   You connect to the NBA via the management port (3c) to manage NBA operations and to pass captured data to policy engines for analysis.

4. PE hub and Socket API: In this example, the NBA uses the Socket API (4a) to pass captured items from the management port (3c) to a policy engine hub (4b). But see the alternative deployment below (5a).
5. Policy engines: The hub then distributes items to policy engines for processing. The results of any policy processing are returned via the Socket API to the NBA.

   Alternatively, the NBA can pass captured items direct to policy engines, using a Socket API (5a) on each PE host machine.

6. CMS: The resulting events are replicated up to the CMS and stored for subsequent retrieval and reviewing.

More information:

Passive Mode

Active (Inline) Mode

Connecting the NBA Ports