First, Do No Harm

When we hear the phrase “first, do no harm,” most of us think of the Hippocratic Oath and its guidance for physicians. I was surprised to learn that the phrase as translated does not actually appear in the Greek, and that the origins are more modern, dating from the 17th century, and likely simply congruent with the Greek theme. I pondered these deep mysteries because I realized “first, do no harm” should be a requirement for anyone responsible for network security monitoring (NSM). In this post I will examine its relevance and discuss why implementing NSM via passive instrumentation delivers on the promise of the Hippocratic Oath.

I was inspired to write this story after reading an online security discussion. The original poster (OP) said he wanted to use a Raspberry Pi to monitor a family member’s home network. The OP was not sure how to do this. As I read the post, I imagined the common home network environment consisting of an Internet service provider (ISP) all-in-one access router and WiFi gateway. One end of the box connects to the ISP line from outside the residence, and users can either connect to the router via a few (often four) Ethernet ports, or more common, WiFi on several bands.

I was disturbed by several of the replies to the OP’s question. One person recommended making the Pi a new gateway, such that all traffic had to route through it. In this scenario, the Pi is either a so-called “one legged router” with its one native interface, or by adding a second network interface card (NIC) via a USB port, it works like a regular multi-interface router. Once the Pi is routing traffic (and I’m not even sure how this might work, given that the ISP device must still provide WiFi access), one could run NSM software on the Pi to inspect network traffic.

Another person recommended ARP spoofing the gateway, such that the Pi pretends to be some upstream device in the path from the Wifi client to the ISP network. In this scenario, the Pi is again either a one-legged or two-legged router, except that it is using essentially a “hacking” technique to fool clients that it is the device to which traffic should be sent when a client wishes to visit the Internet. Again, once it is seeing traffic, the Pi inspects it by running NSM software.

Another person contributed to the conversation by saying the OP could run a full packet capture application on the Pi once it saw traffic. Remember that NSM suggests three main data types for collecting and analyzing data — full packet capture (FPC), transaction or session logs, and alert data. FPC is self-explanatory, whereas transaction data is the sort of logging provided by Zeek and Corelight, and alert data is provided by an intrusion detection system like Suricata or Snort.

As a NSM professional, to be honest, I was horrified by these recommendations. I realized that I had internalized the moral “first, do no harm” when introducing NSM to an environment.

NSM should strive to be a passive, non-interfering element of network security. Ideally, NSM applies zero impact to the network, aside from a safe physical access point. This is most effectively created by a network tap, preferably one engineered to fail open in the absence of electrical power. The NSM platform connects to a passive interface on the tap, and in no way interferes with the network. I do not recommend using network taps with ports that allow injecting traffic on the monitoring ports. I would much rather be able to tell the C-suite that their new NSM enterprise sensor grid is incapable of interfering with the network, by design. If one cannot deploy taps, then a secondary option is to use switch span ports. These must be carefully configured and monitored for changes. One must be careful that network administrators neither disable the span port nor affect the behavior of their switch due to the load introduced by spanning network traffic.

With this in mind, it is easy to see why using a Raspberry Pi in the manner just described is a terrible idea for NSM. One should not deploy a low-cost, albeit cool, device into a network and force it to become the weakest link in the Internet access chain by putting it physically or virtually inline. In the gateway or the even more terrible ARP spoofing scenarios, if and when the Pi fails, the family member loses Internet access. If the family member is remote, returning him or her to the network will require a walk at best or a flight at worst.

A device like a Pi might run Zeek or Suricata to produce logs, but it is likely to suffer as a full packet capture device. A cheap SD card is not designed for constant writing, as required by a FPC solution. Robert Graham posted a series of Tweets on SD cards recently, if you would like to know more about SD cards for Pi usage.

To summarize, NSM is always your next best move, assuming you didn’t start with NSM by building visibility into your enterprise. However, when making that move, never forget to “do no harm.” Don’t introduce fragility into your architecture by making Internet or other network access dependent on the NSM hardware or software. Ideally, NSM is completely passive, and better yet, invisible to users and intruders. In this way, security staff enjoy the benefits of knowing they are improving visibility on a platform that is more trustworthy, thanks to the way it was designed and deployed.