Vulnerability versus configuration management
Nowadays, IT professionals are inundated with reports of vulnerabilities. In most cases, these are products that are not in use. Or the product is in use but still under an old name due to a rebranding by the manufacturer, which causes confusion and additional work for clarification. In addition to understanding how the vulnerability is being exploited and what an attack could look like, the security officer needs to know which products are currently in use. This should be visible in aconfiguration management database (CMDB).Caution: a vulnerability management tool is no substitute for a proper asset management tool. A vulnerability management tool provides interfaces to such CMDBs. Tenable itself offers a variety of integration aids.
However, the difficulty is not in implementing the tool, but in establishing the vulnerability management process in the company and filling it with life.
We distinguish between five asset types:
1. classic IT systems, on-prem servers, switches, clients or similar.
2. OT systems
3. hybrid assets, application servers, e.g. database systems, ERM / ERP systems or similar
4. cloud assets; IaaS, PaaS, SaaS.
5. private assets; BYOD e.g.: smartphone with calendar-mail connection, private notebooks (VPN or terminal server access).
There are different responsibilities, security standards and stakeholders for the five types. Vulnerability management should therefore be understood as a process that is defined, known and practiced throughout the entire company.
Know Your Assets
"Know your assets" is more than just a mantra that IT managers can recite. Functioning vulnerability management also means knowing which systems are in use, which data is stored where and, above all, who is responsible for it. This is then entered in aCMDB (Configuration Management Database). In the best case scenario, this is linked to a vulnerability management tool. Unfortunately, operating a CMDB is time-consuming and there is rarely a body that checks the extent to which the information in this database is up-to-date and available.
In the best case scenario, vulnerabilities are quickly identified through regular scans and passed on using a ticketing tool. This is where the real work begins:
- Assessment of the vulnerability
- Planning the patch management
- Coordination with other stakeholders
- Processing the ticket
- and much more.
Not all of this work can be automated. There still needs to be a human element here - even if it's just asking the system administrator.
Assessment of vulnerabilities
The published vulnerabilities usually have a so-calledCVSS score(Common Vulnerability Scoring System), which indicates how dangerous they are. This score is divided into three subcategories: Base, Temporal and Environmental.
The score focuses on the vulnerability and is not applicable to every company. It is therefore important to consider your own "environment". Who has access - the public, customers, employees? What is needed for exploitation? Network, physical access, local users? The following example illustrates this.
"If a system is accessible via the network, it is more vulnerable than if it is in a locked basement room and disconnected from the network".
It is therefore important to know your assets. A vulnerability is often made public, hotly discussed in the media and patched in a hurry. This hasty approach often harbors risks for operations and can damage the reputation of the VM. Stick to your processes.
- Classify the vulnerability
- Assess the risk potential
- Think about the motivation of a potential attacker (know your enemy)
- Then decide whether emergency patching is necessary
Tenable has defined theVPR (Vulnerability Priority Rating), which is an automated situation assessment that evaluates the vulnerability in correlation with extended information. The subsequent recommendation for patch prioritization is intended to support the security team. With regard to the question: Does our security team always have the knowledge and, above all, the time to assess new vulnerabilities?
Blog by Tenable: What is VPR and how is it different from SVSS
Cloud and vulnerability management
The shift of assets outside the perimeter has become normal in many companies.Tenable Attack Surface Management provides exactly this function by scanning the Internet and using publicly available information to create a list of possible attack vectors. For example, it indicates which IPs are accessible in my public address block, which vulnerabilities are present and which assets at Amazon Web Services are associated with my company.
For cloud assets, it is particularly important to know who is responsible for what; this is part of a cloud strategy and not part of vulnerability management. Every cloud provider will have a shared responsibility model.
Here is the example of Microsoft
Based on this model, responsibilities are regulated, and it is important that vulnerability, patch and asset management are included in the cloud strategy. A vulnerability management system can only check what it knows, which is why cooperation is desirable from the start of the project.
Conclusion and recommendations
Vulnerability management helps every company to know its infrastructure better. A functioning vulnerability management system is not a tool that is installed once and then all problems are solved. It is a process that is constantly optimized and must be accepted and lived by everyone involved.
A well-functioning vulnerability management system requires a CMDB and patch management. The CMDB serves as the basis for identifying assets and the patch management is of course used for patching.
We recommend initially focusing vulnerability management on a sub-area of the infrastructure in order to gain experience and incorporate this into the further development of the VM. Remember that assets, stakeholders and the level of security and its perception are not always comparable.
