Enterprise vulnerability management: from detection to analysis

Blog articles

Step 1: Defining safety rules

The Information Systems Security Policy (ISSP) sets out the cybersecurity rules that a company or organisation, public or private, wishes to respect. It can be broken down into major themes to cover the different aspects of cybersecurity.

The various rules to be respected will then be defined, in the form of organisational and/or technical measures, from which it will be possible to build a vulnerability management process. All these rules and principles are compiled in a complementary document to the IHSP, which will include the key steps for managing vulnerabilities:
- Vulnerabilities collection and analysis,
- Decision-making,
- The development of an action plan when necessary,
- Monitoring the application of patches,
- The control,
- Capitalization,
- Awareness raising.

Step 2: Detection and data collection

Many methods for detecting IS (information systems) vulnerabilities exist.

The monitoring activity consists in collecting information concerning the security of components from reliable information sources (publishers, specialized sites, CERT-FR*...), to identify potential vulnerabilities of IS components.

Audits make it possible to assess the level of security within a defined perimeter. They give an image at a given moment T of the weak points and strong points of the targeted perimeter. It is also possible to automate audits by using automated vulnerability scanners to detect vulnerabilities in a restricted area.

Vulnerabilities can also simply be reported by operators, administrators, users and sometimes even customers. Whether this information comes from inside or outside the company, it must be shared via a simple and secure system.

How to detect the most crafted attacks?

Download our whitepaper about the latest rising threat : Hybrid Malware.


Step 3: Data analysis

Once the collection phase has identified one or more vulnerabilities, this information should be processed by:
- Verifying that it is not a false positive (false alarm),
- Assessing the impact and likelihood of exploiting the vulnerability on the component,
- Assessing the risks associated with this vulnerability throughout the IS (information system).

To prove that the detected vulnerability is real, it is necessary to collect information on its characteristics and compare it with the configuration of the component that you think is vulnerable. Not all components are sensitive to the same vulnerabilities: while for some they may be critical, for others they will have no impact.

Once the threat has been proven, a more or less important task of analysing the risk to the organisation begins: it is necessary to determine how to act to reduce it.

Under these conditions, the application of remediation must be immediate. Indeed, a vulnerability that would allow an attacker to easily take control of a server that has a strategic business function for the company calls for the application of a patch or the implementation of urgent measures

In the vulnerability analysis, it is also necessary to determine the consequences of a patch on the other IS bricks. On a given perimeter, especially when the exploitation of vulnerability remains low, it is sometimes more risky to correct. An in-depth analysis then makes it possible to make the right decisions.

Related Contents

This website uses cookies to ensure you get the best experience on our website. Learn more.