Reflecting on IP addresses, and about factors contributing to having a proper inventory of active ones, recently led me to put up a Twitter poll. Here are the results:
Looking at these numbers it seems quite a few organizations struggle with maintaining an accurate inventory of active addresses in their networks. At this point, information security (infosec) purists may stress the importance of a thing called ‘asset management’ (there’s a reason why it’s the first function in the first category of the NIST Cybersecurity Framework), but I’d like to reflect a bit more on the role of IP addresses for certain processes within an organization.
Related aspects and questions often become even more important once a whole new class of addresses enters the corporate infosec sphere.
Enter IPv6
Let’s imagine there’s a certain number of systems in your organization’s network, and some of those systems are now getting IPv6. Which security processes could potentially be affected? In a sufficiently large organization, which teams should know about the ongoing IPv6 effort?
From a simplified perspective, security processes can be grouped into the following categories (those interested in other categories can find them here):
- Preventative. For our purpose, let’s take filtering of network traffic and patch management as examples.
- Detective. These can include detecting deviations of a desired security state like the detection of vulnerabilities (vulnerability management), or the detection of security violations (such as by system-local mechanisms like log files or agents, or by means of network security telemetry).
- Reactive. Such as incident response.
Traffic filtering is usually mainly done in one of these two flavours:
- Gateway-based filtering (firewalls or router ACLs). Once this is used it may be of (security) interest if there’s at least one active IP/system of a specific address family (such as IPv6) in use within a given subnet.
- Local packet filtering. Once the respective rules are centrally managed, those in charge should know about active IP speakers, I’d suggest. Once they’re not centrally managed (which is the case in many environments), first and foremost one might ask: Who manages them at all? 🤔😂
Jokes aside, for entities responsible for the configuration of local packet filters, knowledge of active addresses of all address families is probably valuable.
To properly perform patch management, one usually has to know which systems are out there. And how does one identify those systems? For example, in environments using MS Active Directory (AD) probably all domain members can be identified by some AD-inherent logic, and other systems might be identifiable by means of their Fully Qualified Domain Names (FQDNs). Still, it’s safe to assume that at least some fraction of to-be-patched systems are identified by their IP address(es), so having a proper inventory is helpful.
In the course of patch management, one might be interested in OS, software components, and their respective versions, as well as actively running systems. Coming up with that type of information commonly falls into the realm of vulnerability management.
The vast majority of vulnerability management tools and frameworks primarily use addresses as identifiers of systems. From that angle, an accurate inventory of addresses certainly helps. The advent of IPv6 might bring some extra challenges here, as simply scanning IP subnets for active systems (in order to subsequently subject those to vulnerability scanning) no longer works with IPv6, so the need for a proper source of truth becomes more crucial. I discussed this earlier in IPv6 security best practices.
Finally, in the context of incident response, general situational awareness (what’s happening, which assets are affected, where is the source of issues, and so on) is needed. I could imagine that the ability to map IP addresses to systems can be helpful here (for identification, evaluation, and follow-up), so a proper IP address inventory would be valuable.
tl:dr
Having an understanding of active IP addresses within an organization potentially affects (at least) the following security controls and processes:
- Traffic filtering
- Patch management
And definitely affects:
- Vulnerability management
- Detection of security violations
- Incident response
So, talking to the owners of these processes is needed to make sure that deploying IPv6 does not lead to increased risk exposure.
Enno Rey is a long-term IPv6 enthusiast with extensive practical experience in the space.
Adapted from original post which appeared on The Internet Protocol Blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.