Global Security Vision AM policies: how a single setting automates an entire asset module

Fyodor Bokov, Security Vision

In previous articles, we discussed the role of the asset as a key element of contextual automation. But the question arises: how can we make the system understand on its own what roles to assign, how often to check assets, and what data to use when setting up agents? The answer is “Global Policies.” This is a kind of “constitution” for your Security Vision Asset Management: you define the rules once, and the module operates according to them, freeing you from routine tasks.

Below, we will analyze each parameter of global policies using real‑life examples. You will see how these settings make working with assets not just automated, but truly convenient.

Global policies. Part 1

Global policies. Part 2

1. Presentation (link to the module)

What it does:

The parameter defines the URL template that is used in notifications (Telegram, email, corporate messenger) for quick access to the asset card. Instead of sending plain text like “an asset with IP 10.10.0.45 has been detected,” the system generates a clickable link that leads directly to the page for that asset in the Security Vision Asset Management module.

Why the client needs it:

Imagine that your company receives 50–100 notifications daily about new assets, changes in criticality, or detected vulnerabilities. The analyst needs to open the system each time, search for the required asset by IP or hostname, and wait for the list to load — this takes minutes, which add up to hours of lost time.

With a configured presentation template, the situation changes:

• A message appears in Telegram: “A new asset with the PowerDNS role has been detected. [Go to the asset].”

• The analyst clicks the link and is immediately taken to the asset card, without wasting time searching.

This is especially valuable during incidents, when every second counts. Instead of searching for an asset in the general list, the specialist can immediately see its card, roles, criticality, and change history — and make a decision.

2. Default applications are allowed.

What it does:

Defines the system’s behavior regarding applications that are not included in the whitelist or blacklist. If the option is enabled, such applications are considered allowed and do not trigger software control policies. If it is disabled, any unknown application will be treated as a violation.

Why the client needs it:

Imagine that you are just starting the implementation, and the infrastructure includes thousands of workstations with different software. If the system blocks or signals about every unknown application, you will drown in false positives. By enabling the option, you give the system “quiet mode”: it records the fact that an application is present, but does not interfere with its operation. Once the policies are fine‑tuned, you can disable the option and switch to full‑fledged control.

3. Automatically determine criticality.

What it does:

The system itself calculates how important an asset is to the business. Criticality can be calculated based on its role, the presence of critical data on the asset, its availability from the internet, the number of assets associated with it, and other factors.

Why the client needs it:

Imagine you need to prioritize 2,000 assets. Doing this manually would mean hiring a separate person for a month. Automatic criticality detection allows the system to automatically label assets according to their level of importance. As a result, the security team understands where to direct resources first, and administrators know which servers require maximum fault tolerance.

4. Automatically adjust criticality and roles after each inventory.

What it does:

If the option is enabled, the system does not simply assign a role and criticality once when the asset is created, but reviews them after each inventory cycle. If the asset has changed its behavior — it has started listening on new ports, critical services have appeared on it, or its network availability has changed — the system automatically updates the roles and criticality, reflecting the current state.

Why the client needs it:

The infrastructure is not static. A server that yesterday was an ordinary test bed could today become part of a critical business process. A database was deployed on it, it was connected to a payment gateway, or it was turned into an entry point for external users. Without an automatic review of its criticality, this asset would remain low‑priority, which could lead to:

• underestimation of risks in the event of incidents,

• insufficient level of monitoring,

• improper allocation of resources for vulnerability remediation.

With this option enabled, the system automatically monitors such changes. As soon as an asset begins to meet the criteria for higher criticality (for example, if it is detected to have the “Payment Gateway” role or becomes accessible from the internet), the system automatically raises its status. The analyst receives an up‑to‑date picture without having to manually review thousands of assets.

The same applies to roles: if the web server stops working on the server, but the DNS service starts, the system will update the roles, and the asset will begin to be processed according to the rules designed for the DNS infrastructure.

For the customer, this means that the asset management model is always up to date, and critical assets are not overlooked due to human error or administrative delays.

5. Perform an nslookup after creating the asset.

What it does:

If the option is enabled, then when creating a new asset (by IP or hostname), the system performs a reverse DNS query. This allows you to check whether the name matches the address, verify the asset, and avoid duplicates. This option is separated into a separate setting intentionally, as it creates additional load both on the organization’s DNS servers and on the Security Vision Asset Management module itself, which waits for a response to each request.

Why the client needs it:

Imagine that you are importing a list of 200 IP addresses obtained from different sources. One of the addresses is incorrect or no longer in use. Without nslookup, you will only find out about this when the scanning starts failing with errors. With the option enabled, the system checks each asset immediately after creation, and problematic addresses are flagged. This saves hours of debugging and keeps the asset database clean.

6. Attempt to perform actions on assets via FQDN.

What it does:

When the system needs to access an asset (for inventory, scanning, or script execution), it first attempts to use the fully qualified domain name (FQDN) rather than the IP address. If access via the FQDN is not possible, the system switches to the IP.

Why the client needs it:

In modern infrastructures, IP addresses can change (DHCP, virtual machine migration). If the system “remembers” an asset by its old IP, it won’t be able to reach it. Working via FQDN ensures that the system always finds the current address via DNS. For the customer, this means fewer inventory errors and more reliable execution of all automated operations.

7. The number of simultaneously running identifications and inventories.

What it does:

Two parameters that limit how many assets can be processed simultaneously at the identification or inventory stage:

The values are set as numbers. For example, “2 identifications, 4 inventories” means that at any given time, the system processes no more than two assets in asset recognition mode and no more than four in full data collection mode.

Why the client needs it:

When new assets are added to the infrastructure en masse, the system may attempt to process them all simultaneously. This creates peak loads:

• on the network — multiple simultaneous connections to assets;

• on the assets themselves — active scanning can load the processor or network interface;

• on the Asset Management server — high competition for database resources and computing power.

By limiting the number of assets being processed simultaneously, the administrator receives a predictable and gentle load on the infrastructure. The inventory process is stretched out over time, but at the same time:

• servers do not crash due to simultaneous scanning by dozens of threads;

• business applications do not experience performance degradation during working hours;

• the system remains responsive for other tasks.

This is especially important in large networks, where, if the number of assets being processed simultaneously is not limited, hundreds or even thousands of devices could be affected at once.

7. The value of the subnet mask

What it does:

Sets the default subnet mask for new assets that do not have one defined (for example, when importing from a CSV file without specifying a mask or when creating them manually).

Why the client needs it:

To build a network topology, calculate availability, and perform segmentation, it is important to know which subnet the asset is in. If the mask is not specified, the system uses the default value. This allows assets to be automatically grouped into subnets even when the source data is incomplete.

8. Asset obsolescence

What it does:

Two interrelated parameters:

• How many days to notify about an outdated asset — if the asset did not respond to the inventory check within the specified period, the system sends a notification.

• How many days to automatically delete outdated assets — if the asset continues to remain silent, it is automatically removed from the database after this period expires.

Why the client needs it:

Any infrastructure contains “forgotten” assets — temporary VMs, test environments, decommissioned servers that no one has removed from accounting. They clutter the database, distort statistics, and can trigger false alarms in security systems. Manual cleanup is time‑consuming; a global policy automates this process: an asset that no longer exists first reminds you of its existence and then disappears on its own.

10. Agent

A real‑life example:

The company has 2,000 servers spread across different data centers and offices. Previously, when implementing agent‑based data collection, engineers had to manually access each server, configure the collector’s address, port, and credentials — this took weeks and was a source of errors (some ports were forgotten to be changed, some IP addresses were entered incorrectly).

With the setup of the agent block in the global policy, everything has changed:

1. The engineers specified the agent download URL and the collector service URL once.

2. The command to install the agent was sent via the configuration management system (Ansible) or group policies.

3. The agent downloaded the distribution from the specified URL itself and connected to the collector.

4. All 2,000 servers came under management within a few hours, without manual intervention on each node.

For the customer, this means: scaling without headaches. Adding a new server to the infrastructure no longer requires calling an engineer to configure the agent — it’s enough for the server to appear on the network, and the policy will do the rest.

Conclusion

Global policies in Security Vision Asset Management are not just a set of technical settings hidden in the depths of the administrative interface. They are the foundation on which the usability of the system and the efficiency of asset management in general are built.

When we talk about modern asset management, we’re talking about three things: speed, flexibility, and reliability. It is these qualities that global policies provide. Instead of configuring each asset individually, assigning it roles, criticality, inventory parameters, and methods of interaction with agents, the administrator defines the rules of the game once for the entire fleet of devices. And then the system does everything on its own.

This fundamentally changes the approach to work:

• Speed — new assets appear in the system already with the correct roles and criticality, and analysts can access them via a link from a notification with a single click.

• Flexibility — scanning and inventory management are handled through different connector services, the load is distributed predictably, and assets don’t “crash” due to simultaneous processing by hundreds of streams.

• Reliability — forgotten and decommissioned assets are automatically deleted, the database isn’t cluttered with “zombie nodes,” and criticality always reflects the actual state of the asset.

But the main thing is that global policies free the customer from routine tasks. The administrator stops being a “firefighter” who runs around fixing one thing and then another. Instead, they become an architect: they think through the logic of how the entire system works once, and then only monitor and adjust the processes.

At Security Vision, we are convinced that a good tool should work for the customer, not force the customer to work with it. Global policies are exactly about that. We made them flexible and user‑friendly so that you could focus on real security tasks rather than endless accounting setup.