Introduction

Network and application resource inventory is an integral part of infrastructure management. We will focus on the technological challenges and look at the available solutions, which may vary depending on the type of environment. For this reason, I will describe two scenarios that will serve as examples of implementation.

Example Environments

Internal Network

The first environment is an internal network, divided into several geographical locations. Each location is independent, with its own network structure. The datacenter is located in the main office and, in addition to supporting several key services for employees such as email and shared network drive, also supports the ability to log into the ticket system by end customers. The ticket system is connected via a dedicated link with Internet access. The datacenter also has a closed DMZ network for critical applications.

Hybrid Architecture

The second environment has a hybrid architecture, where both physical locations have access to resources in the cloud. All office employees use the servers and application services in the cloud, while administrators have additional permissions to manage these resources. Administrators also have to manage several important local services such as DHCP, DNS, and VPN between locations.

Examples of Inventory Data

Regardless of the size of the environment and the division of services, inventory can have many use cases. Below are some example fields divided by object type.

• Employee device or computer – IP address, physical MAC address, owner, location, type, operating system, department
• Server – team responsible for support, service type, role, priority, rack number
• Application – full name, manufacturer contact, contract number, port, priority
• Subnetwork – name, description, location, function, traffic policy, priority

Depending on the application, some fields may be repeated, e.g., priority. A full inventory should also include dependencies between resources, such as:

• Client and server roles in network connections
• List of network ports used within a given application
• Applications running within a given server or subnetwork
• Network connections between IP addresses, subnetworks, and the cloud

Challenges in Controlling Distributed and Hybrid Networks

New and Dynamic Objects in a Distributed Network

Let's now look at the daily work and challenges that await administrators and operators. The most important aspect of inventory is current and accurate data. Regardless of whether we have a local or distributed infrastructure, we must be prepared for changes. The creation of new resources and services or their modification affects how dynamically our infrastructure changes. We expect our monitoring and inventory systems to present up-to-date information, which means that in a dynamic environment, new resources should appear as quickly as possible, and automation is highly desirable here.

Analysis of Network Communication Between Objects

We have also touched on creating dependencies between resources. One of the most important points is the connection of applications and their network traffic. Communication can take place between a workstation and an application server, as well as between servers, e.g., an application and a database server. In distributed networks, we can observe additional traffic between local and cloud resources. Adding this information to the inventory of services and applications will allow us to obtain a complete picture of what exactly is happening in our network and how individual elements are connected.

Security Policies in Distributed and Hybrid Environments

In the case of security policies, the above data should also be verified taking into account the defined rules and security measures. Having information about network connections, we can create an automatic inventory of ports, traffic volume, and used applications. When we combine this data with the inventory of local and cloud resources, we obtain a complete set of information and fill the gap between application administrators and security specialists. By adding additional rules and alert actions, we also obtain an immediate response to situations outside our policy.

Combining Data Between Systems

We should also keep in mind the possibility of integrating our inventory data with external systems. In most cases, we will want to share the data obtained by monitoring resources with applications such as ticket systems, CMDB, SIEM, or others. An additional advantage may be the synchronization of individual parameters in the other direction, where we add information to our inventory. For this reason, easy integration and automatic synchronization are desirable functions.

Effective Ex Post Analysis

Obtaining inventory through infrastructure monitoring has another huge advantage in the form of historical data and the ability to compare it with the current status. Thanks to this, we can analyze various security incidents or service interruptions and understand exactly what happened and how to prevent it in the future.

How Can We Act?

Ensuring Up-to-Date Inventory Data

Referring to the previous arguments, the best solution may be to create such data automatically or at least semi-automatically, where the user adds the missing elements. This will allow full support for new or dynamic resources, where the user's role will be limited to their verification at the inventory level. However, in the case of policies and alerts, such resources will be verified immediately.

Active Infrastructure Scanning

We have various technologies at our disposal that allow us to scan the infrastructure using network protocols such as ICMP, SNMP, REST API, WMI, or SSH. However, they often have additional requirements that must be met through various changes in the infrastructure. In the case of servers, applications, and network devices, the user will have to prepare appropriate permissions to log in and monitor various parameters. Also, security policies must be appropriately modified for additional active monitoring traffic, especially in the case of verifying open ports. This can be problematic in distributed environments where we require monitoring of resources in the cloud or another separate part of the infrastructure such as a DMZ. When scanning, we must also consider its scope, which is most often defined by subnetworks or IP address ranges. Such a list must always be up-to-date, because otherwise, there is a risk of incomplete data about resources.

Passive Infrastructure Scanning

The solution to our challenges will be passive monitoring, where scanning the network and application infrastructure is based on collected information. Such monitoring systems listen and receive statistics and information about network traffic through technologies such as NetFlow, sFlow, JFlow, or IPFIX. This allows direct access to the actual traffic in the infrastructure and the creation of inventory data about all resources that use our network. Regardless of whether we are talking about workstations, servers, applications, or even traffic sent to the cloud or the Internet, NetFlow technology and its derivatives have all this information. The mentioned systems also do not have to generate additional traffic, which we observe for the aforementioned active monitoring. The only element for implementing passive monitoring is the configuration of network devices such as a router to send NetFlow packets to our installation. If our device does not support such technology or we require additional statistics from the level of network packets, the mentioned systems often have support for additional probes that collect data directly from the network card of a given server or the SNAP/Mirror port on the network switch. So we can be prepared for any scenario.