Security Considerations

Overview

NetoFlow has API access to Netography Fusion to upload NetFlow and sFlow records. A threat actor that gains access to the system you deploy NetoFlow on in your environment could read these credentials, modify the NetoFlow code, or access these APIs directly. Therefore, it is important to implement the security concept of least privilege to reduce the risk of unauthorized access to this system.

Best Practices

Here are recommended best practices to use in deploying NetoFlow in production environments:

• Use the NetoFlow container for deployment. It is built on the Google distro-less container image, which significantly reduces the attack surface compared to a default Linux distribution.

• If you choose to deploy NetoFlow as a software package, deploy it on a dedicated system that adheres to your organization's security policies and is updated and hardened, and all external services that are not strictly required are disabled (e.g., no open ports or services except SSH and the UDP port NetoFlow is listening on). Limit network access to the system to authorized administrators only. Exercise general security best practices in operating a limited-use system of this type.

• Ensure that only legitimate network devices can deliver NetFlow and sFlow protocol UDP packets to the NetoFlow system.

• Disable the NetoFlow API or restrict access to its listening port to prevent others from reading statistics (see Reading statistics from NetoFlow API.

• Create an API key configured with the neto_flow role in Fusion.

• Store API credentials in an external vault or secrets management system and pass them in at runtime rather than store them locally. Choose the most secure credential storage approach for your environment.

• Regularly expire and rotate API keys being used.

Understanding the data

All flow data and user metadata in the Netography cloud are stored encrypted at rest. The NetoFlow Connector sends the flow records it collects from your local network devices to the Netography Fusion SaaS. These flow records contain network meta-data but not packet payloads. Metadata includes the NetFlow 5-tuple (source IP, destination IP, source port, destination port, protocol). NetoFlow also parses out of the flow record associated network interfaces and statistical information. An example of a flow record is shown below:

JSON

{
  "timestamp": 1574220661,
  "srcip": "10.0.0.1",
  "srcport": 34765,
  "srcowneras": {
    "asnumber": 3333,
    "asorg": ""
  },
  "srcas": {
    "asnumber": null,
    "asorg": ""
  },
  "dstip": "192.168.2.2",
  "dstport": 179,
  "dstowneras": {
    "asnumber": 14618,
    "asorg": ""
  },
  "dstas": {
    "asnumber": null,
    "asorg": ""
  },
  "nexthop": null,
  "nexthopowneras": {
    "asnumber": null,
    "asorg": ""
  },
  "bgpnexthop": null,
  "bgpnexthopowneras": {
    "asnumber": null,
    "asorg": ""
  },
  "bits": 480,
  "packets": 1,
  "pbratio": 0.0020833333333333333,
  "flowbrate": 480,
  "flowprate": 1,
  "protocol": "tcp",
  "protocolint": 6,
  "tos": 192,
  "srcmask": null,
  "dstmask": null,
  "start": 3056874,
  "end": 3056874,
  "duration": null,
  "input": null,
  "output": 4,
  "samplerate": 10,
  "uptime": null,
  "flowsrcip": "172.16.10.10",
  "tcpflags": {
    "urg": false,
    "ack": true,
    "psh": false,
    "rst": false,
    "syn": false,
    "fin": false,
    "ece": false,
    "cwr": false,
    "ns": false
  },
  "tcpflagsint": 16,
  "flowtype": "netflow",
  "flowversion": 10,
  "srcvlan": null,