<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=2975524&amp;fmt=gif">
BLOG

How to Mirror Packets to your Monitoring Tools in AWS and Public Cloud Environments

January 2, 2020

cloudsx

Traffic visibility is a crucial component in securing a business and keeping systems operational. Organizations have made significant investments in specialized tools that ingest and analyze packet-level data for on-premise data centers. However, network monitoring has been blinded in the cloud.  

With compute resources, application development and core business systems moving to the cloud, IT teams are no longer able to properly acquire, process and distribute packet-level cloud traffic to their selected tools. Consequently, the move to the cloud creates significant blind-spots and loss of ROI on vital tools that are powerless without access to packet-level cloud data. 

What is Garland Prisms?

Garland Prisms is a Software as a Service (SaaS) platform that provides complete packet visibility into any public, private, or hybrid cloud environment. Garland Prisms mirrors packets within a cloud instance and forwards them to security and analysis tools. Garland Prisms has a split SaaS architecture comprised of central control: Prisms Cloud Console and Cloud Agents (also referred to as Prisms). The control plane is split between the Prisms Cloud Console and Cloud Agents. The architecture is designed to be secure and robust.

>> Watch Now: Garland Prisms Traffic Mirroring [Free Demo]

 

Prisms Services Architecture

The diagram below shows a sample deployment in an AWS cloud environment, but can also be done in Google Cloud and Microsoft Azure. Cloud Agents filter and mirror traffic based on mirroring policies. Policies are comprised of source groups, connections, and destinations which users define using the Cloud Console.

AWS CLoud

When any instance containing a Cloud Agent launches, the agent will automatically connect to the Prisms Cloud Console and register itself, obtain configuration updates, and automatically install software updates when upgrades are available. Prisms Cloud Agents use HTTPS to make REST API calls to the Cloud Console, with control traffic always originating at the agent. Data plane traffic (mirrored filtered traffic) is routed based on the users’ network configurations. Mirrored packets are never sent to the Cloud Console. The control plane does not directly modify, nor does it require the user to modify networks or security setting, save for allowing outbound HTTPS (TCP port 443) from subnets containing Cloud Agents.

Configure & Connect

Users have praised Garland Prisms for its ease of use and simplicity. In under 5 minutes you can add Garland Prisms to a virtual machine in a virtual environment whether it is AWS, Microsoft Azure, Google Cloud, or a private or hybrid cloud environment. You can designate tools such as Wireshark, that you want to inspect the data and then create a connection to the tools.

The process is simple:

  1. Create cloud agents
  2. Create and configure source groups
  3. Create destinations
  4. Create direct connections
  5. Install docker

New call-to-action

See Everything. Secure Everything.

Contact us now to secure and optimized your network operations

Heartbeats Packets Inside the Bypass TAP

If the inline security tool goes off-line, the TAP will bypass the tool and automatically keep the link flowing. The Bypass TAP does this by sending heartbeat packets to the inline security tool. As long as the inline security tool is on-line, the heartbeat packets will be returned to the TAP, and the link traffic will continue to flow through the inline security tool.

If the heartbeat packets are not returned to the TAP (indicating that the inline security tool has gone off-line), the TAP will automatically 'bypass' the inline security tool and keep the link traffic flowing. The TAP also removes the heartbeat packets before sending the network traffic back onto the critical link.

While the TAP is in bypass mode, it continues to send heartbeat packets out to the inline security tool so that once the tool is back on-line, it will begin returning the heartbeat packets back to the TAP indicating that the tool is ready to go back to work. The TAP will then direct the network traffic back through the inline security tool along with the heartbeat packets placing the tool back inline.

Some of you may have noticed a flaw in the logic behind this solution!  You say, “What if the TAP should fail because it is also in-line? Then the link will also fail!” The TAP would now be considered a point of failure. That is a good catch – but in our blog on Bypass vs. Failsafe, I explained that if a TAP were to fail or lose power, it must provide failsafe protection to the link it is attached to. So our network TAP will go into Failsafe mode keeping the link flowing.

Glossary

  1. Single point of failure: a risk to an IT network if one part of the system brings down a larger part of the entire system.

  2. Heartbeat packet: a soft detection technology that monitors the health of inline appliances. Read the heartbeat packet blog here.

  3. Critical link: the connection between two or more network devices or appliances that if the connection fails then the network is disrupted.

NETWORK MANAGEMENT | THE 101 SERIES