Best practice #3: Set filters to detect anomalous behavior
In addition to maintaining a continuous, week-long capture of all network traffic, it’s often helpful to define a secondary capture consisting only of network anomalies that may signal a security violation. If no anomalies occur, then no secondary capture is initiated and no alerts are raised. But if anomalies occur, IT engineers and security experts can take advantage of the evidence in a small capture file containing just the relevant data.
To configure a capture like this, IT engineers simply capture a file that starts recording data when any of the following conditions occur:
• Mail traffic (SMTP traffic) is not going to mail servers, possibly indicating the presence of a worm on the network.
• DHCP offers are coming from a source other than the DHCP servers, possibly indicating the presence of a rogue DHCP server.
• Offnet traffic is not destined for the MAC address of a router, possibly indicating the presence of a Man-in-the-Middle attack.
• Any user other than a member of the Finance team tries to connect to the Finance department’s servers, possibly indicating a hacker and a probably Sarbanes-Oxley violation, as well.
• Any server in the DMZ tries to initiate an outbound connect other than to known backend servers, possibly indicating that a server has been compromised.
Each organization can identify its own list of anomalies relevant for the infrastructure and services being maintained.
If a secondary capture begins, IT engineers can open the capture files (which will be small) and know immediately where to begin their investigation.
The graphic below shows a series of NOT conditions that define a filter to capture anomalies on the network, such as SMTP traffic that does not involve the organization’s mail server and DNS traffic that does not include the organization’s DNS server.
