Comings & Goings (on networks)

Imagine for a moment what happens when we walk into commercial buildings in urban areas. Typically, we step up to a registration desk staffed by people trained in security protocols who ask politely for identification. This is very basic but as a step is critically important: asking us to identify ourselves and verifying we are who we say we are. This helps establish a baseline of insights that are important: who’s here, who did they come to see, when did they arrive, are they still in the building, when did they leave, etc.

Is asking for identification infallible as a security control? Of course not. It does, however, establish some important baselines and raises the cost of any attempts to do harm. Simple protocols used consistently dramatically reduce unplanned activities of the avoidable sort, both online and off.

A few months ago, I started teaching myself more about some open-source technologies that exist to aid with keeping us notified of network traffic and activity on different kinds of networks. There are parallels between observing virtual, network traffic, and physical traffic, such as people moving into and out of a building and similar insights to be gained that are valuable in the context of resilience.

For example, in either case, such quantitative data generates quick insights by illustrating traffic patterns: times of day, days of the week, who comes and goes (inbound/outbound network traffic, IP assignments, ARP table updates, etc.), and with what frequency. Such intel assists with capacity planning as organization grow and even when everyday people start demanding more from their home networks.

And just like keeping a physical inventory of visitors, these tools can help us more quickly respond to incidents and minimize the damage they can cause. Because incidents will happen. In particular, I’ve gained some fluency in technologies like arpwatch, implementing a set of monitoring/notification tools that complement it, working together to deliver simple but valuable insights.

I’m learning to refine them as I go. At first, the rate of false positives and/or innocuous information was overwhelming. It took me some time to establish my goals and define value. This is always unique to each culture and goal. Mine is simple: reduce the noise-to-signal-ratio so notifications are real, prioritized, predictable and actionable information.

I’m nearing a good point to write up a post about how I failed so far by initially over-engineering it, writing too many of my own scripts and tools that are not-at-all friendly for everyday folks to use.

I need a bit more time to achieve a reasonable path forward in that context. Meanwhile, it’s satisfying to gain much better insight into the devices coming and going on networks and their typical behaviors, services, ports, without much cognitive demand.