The Basics

This guide describes the basic requirements of a NetWitness deployment and outlines optional scenarios to address the needs of your enterprise. Even in small networks, planning can ensure that all goes smoothly when you are ready to bring the hosts online.

Note: This document refers to several additional documents available on NetWitness Community Link. Go to the NetWitness All Versions Documents page and find NetWitness Platform guides to troubleshoot issues.

There are many factors you must consider before you deploy NetWitness. The following items are just some of these factors. You need to estimate growth and storage requirements when you consider these factors:

  • The size of your enterprise (that is, the number of locations and people that will use NetWitness)
  • The volume of network data and logs you need to process
  • The performance each NetWitness user role needs to do their jobs effectively.
  • The prevention of downtime (that is, how to avoid a single point of failure).
  • The environment in which you plan to run NetWitness
    • RSA Physical Hosts (software running on hardware supplied by RSA)
    • Software Only provided by RSA:
      • On-Premises (On-Prem) Virtual Hosts
        See the NetWitness Virtual Host Installation Guide for detailed instructions on how to deploy on-prem virtual hosts.
      • VCloud:
        • Amazon Web Services (AWS)
          See the NetWitness AWS Installation Guide for detailed instructions on how to deploy virtual hosts in AWS.
        • Azure
          See the NetWitness Azure Installation Guide for detailed instructions on how to deploy virtual hosts in Azure.
        • Google Cloud Platform (GCP)
          See the NetWitness Google Cloud Platform Installation Guide for detailed instructions on how to deploy virtual hosts in Google Cloud.

Basic Deployment

Before you can deploy NetWitness you need to:

  • Consider the requirements of your enterprise and understand the deployment process.
  • Have a high-level picture of the complexity and scope of a NetWitness deployment.

ProcessProcess

The components and topology of a NetWitness network can vary greatly between installations and should be carefully planned before the process begins. Initial planning includes:

  • Consideration of site requirements and safety requirements.
  • Review of the network architecture and port usage.
  • Support of group aggregation on Archivers and Concentrators, and virtual hosts.

When ready to begin deployment, the general sequence is:

  • For RSA Physical Hosts:
    1. Install physical hosts and connect to the network as described in the NetWitness Hardware Setup Guides and the NetWitness Physical Host Installation Guide.
    2. Set up licensing for NetWitness as described in the NetWitness Licensing Guide.
    3. Configure individual physical hosts and services as described in NetWitness Host and Services Getting Started Guide. This guide also describes the procedures for applying updates and preparing for version upgrades.
  • For On-Prem virtual hosts, follow the instructions in the NetWitness Virtual Host Setup Guide.
  • For AWS, follow the instructions in the NetWitness AWS Installation Guide.
  • For Azure, follow the instructions in the NetWitness Azure Installation Guide.
  • For Google Cloud, follow the instructions in the NetWitnessGoogle Cloud Platform Installation Guide.

When updating hosts and services, follow recommended guidelines under the "Running in Mixed Mode" topic in the NetWitness Host and Services Getting Started Guide.

You should also become familiar with Hosts, Host Types, and Services as they are used in the context of NetWitness also described in the NetWitness Host and Services Getting Started Guide.

NetWitness High-Level Deployment Diagrams

NetWitness is inherently modular. Whether organizations are looking to deploy on-premise or in the cloud, the NetWitness components are decoupled in a way which allows flexible deployment architectures to satisfy a variety of use cases.

The following figure is an example of a hybrid cloud deployment, where the base of the components are residing within the SecOps VPC. Centralizing these components make management easier while keeping network latency to a minimum.

Network, log, and endpoint traffic could then be aggregated up to the SecOps VPC. The on-premise location would function just like a normal physical deployment and would be accessible for investigations and analytics.

Cloud SaaS visibility could be captured from a Log Decoder residing in either the cloud or on-premise locations.

netwitness_hybridcloud.png