Asset and Vulnerability Management in Practice: A Working Process Example
This article continues the practical series “Vulnerability Management for Beginners” and shows how asset and vulnerability management principles operate in a real project. The description is a composite drawn from multiple implementations rather than a single company. Examples use MaxPatrol VM and PDQL queries because the author knows the platform internally, yet the logic of dynamic groups, automatic asset ingestion, linkage of servers to unacceptable events, and state control applies to any mature vulnerability management system.
At the initial stage most effort must go into asset management, because without trustworthy infrastructure data vulnerability reports become merely attractive but meaningless pictures. The analogy with BI systems is direct: they collect data from multiple sources and build dashboards, yet if input data are unreliable the dashboards display a beautiful lie. The primary goal of asset management is therefore to supply accurate and timely information about the infrastructure.
A second critical success factor is the capability of the IT department. IT is usually considered only in the context of patch installation, but its influence on vulnerability management effectiveness is much broader. Before starting, teams must assess existing IT processes, their maturity level, and whether they can meet the required workload. Security specialists should act not only as customers but also as partners, advocating for necessary IT resources when they are insufficient.
Eight Principles for Building the System
The system rests on eight principles that ensure organizational and technical solutions do not contradict each other:
- Minimization of human dependency – processes must survive employee absence through documentation, error minimization, and automation.
- Just-in-time information – changes must be known exactly when they occur or are planned.
- Maximum data accuracy – solutions must confirm with certainty whether an asset exists in the infrastructure.
- Management by exception – normal operations should require no human intervention; specialists spend no more than 50 % of time on routine tasks.
- Self-control – processes must include easy verification of their own correctness.
- Explicit information exchange – colleagues in IT, DevOps and other units must receive clear explanations of actions and their reasons.
- Embedding into existing processes – new procedures must integrate into established workflows rather than create additional overhead.
- Combination of suitable tools – existing systems should be reused whenever they reduce effort.
Data Exchange Between Components
Two CMDB systems are used: NetBox for server and network infrastructure, subnets, IP addresses and perimeter services, and 1C:ERP for client equipment such as laptops and monitors. Only the employee-to-laptop mapping is imported from 1C:ERP. Data enter NetBox both manually and automatically from virtualization platforms and clouds. A webhook on asset creation in NetBox triggers a microservice that initiates scanning in MaxPatrol VM, creates tasks in the ticketing system, or updates the knowledge base.
Asset Onboarding and Automated Scanning
Every new asset must receive logging to MaxPatrol SIEM, an MaxPatrol EDR agent, and accounts for Audit-mode scanning before entering production. The webhook mechanism starts the scan automatically; the specialist only reviews results. Additional triggers include daily asset-change reports, new accounts in specific Active Directory OUs, and procurement of new communication channels or cloud resources. Security is also embedded into contract-signing processes with telecom and cloud providers to learn about planned infrastructure changes at the earliest stage.
Scanning Algorithm and Group Structuring
Scanning begins with core elements: network devices that define real subnets, virtualization management nodes, domain controllers, and configuration-management systems. Known subnets are first scanned with Service Discovery and Host Discovery profiles. Assets with unknown operating systems are moved to dynamic groups and processed through OS Detection, then brute-force Audit profiles for Linux and Windows if necessary. The goal is to reach the target state of “know everything about the asset” through Audit scanning for internal networks and Host/Service Discovery for external perimeters.
Dynamic groups are preferred over static ones for thousands of assets. Static groups are reserved for rarely changing devices such as core switches, routers, virtualization systems, and domain controllers scanned via LDAP. PDQL queries allow specialists to compare actual subnets against NetBox records and to classify asset freshness according to policy-defined time windows (NotDefined, UpToDate, NeedUpdate, Obsolete).
Categorization and Remediation
Application systems are defined in NetBox so that servers can be automatically linked to unacceptable events. Each application system is manually mapped once to an event category (target, key, neutral); scripts then propagate the linkage to individual virtual machines. Non-technical attributes such as SLA and scanning agreements are stored in custom fields populated via the integration server.
Planned updates occur monthly, aligned with Patch Tuesday for Windows and cumulative patches for Linux. Infrastructure is divided into priority tiers using criteria translated into a single numeric score. Windows Update checks can be performed with a lightweight profile rather than full Audit. When patching is impossible, compensating measures—organizational restrictions or technical controls—are applied; removal of the software remains the final option.
