This article is part of a series of insights on Data Security that we have published in these weeks: the topics we are going to address here are related to the theme of Vulnerability Assessment (VA), one of the key concepts underlying modern IT security methodologies.
As always, we will start from the definition, and then recover the historical context in which the need to conduct vulnerability checks on IT systems is determined; in the subsequent sections of the article we will try to definine some best practices and guidelines taking as reference the most authoritative standards available today.
To better understand the general context from which this article moves, we recommend to read our post The 4 pillars of IT Security according to ENISA, which offers an overview of the Technical Guidelines for the implementation of minimum security measures for Digital Service Providers issued by the European Union Agency for Cybersecurity (ENISA).
Definition
The Vulnerability Assessment is a process that, through the results of a series of automatic and / or manual security checks, allows to define, identify and classify the main risks associated with the commissioning and / or operation of a given IT ecosystem (e.g. a software application, a company network, a single device or a web application). To put it another way, the VA allows you to answer the following question: how likely is the system to fall prey to cyber attacks?]
Background Context
The origins of the Vulnerability Assessment date back to the second half of the 1970s, when the first rudimentary computer attack prevention software began to spread: however, it was only after a decade, when personal computers began to spread in every workplace, that we began to understand the need to carry out a preventive assessment on the security risks related to software and infrastructures.
Today, thanks to the enormous amount of cyber threats that exist, Vulnerability Tests on computer systems are widely spread all over the world and are carried out at any level: on networks, on devices (including Internet of Things devices) and, of course, on software applications and websites: most of them, such as S4E:Shelter Assessment Tool, are even freely available for personal use. It can reasonably be said that any company wishing to adopt a modern IT security policy must necessarily provide for the periodic execution of vulnerability tests.
The 4 phases of the Vulnerability Assessment
The Vulnerability Assessment activity can be split into 4 main phases:
- Analysis of the inventory of assets and functionalities of the system being analyzed;
- Assessment of the importance of the identified resources using a standard classification system;
- Research, identification and classification of vulnerabilities (found or potential) for each of the resources identified;
- Preparation of a Gap & Remediation report that documents the actions that must be taken to eliminate or mitigate the vulnerabilities found, or to reduce the risk that potential ones will occur in the near future;
It goes without saying that, in drawing up the report referred to in point 4, it will be necessary to give the hypothesized interventions a variable priority depending on the importance of the resource (point 2) and the criticality, in terms of probability and impact, of the vulnerability found. As you can see, this is a methodology that has many things in common with the methodologies used today for Risk Assessment, standardized in the ISO 31000 family: this is not surprising, given that vulnerabilities are nothing more than a particular type of risk. It is therefore correct to state that the Vulnerability Assessment is an integral part of a more generic Risk Assessment, with a particular focus on aspects related to a specific category of risks connected to information security: cyber attacks. Not surprisingly, it is often merged into the Security Assessment carried out in a general Risk Assessment context.
Research, identification and classification
Looking back at the 4 phases listed above, it is useful to say a few more words on the third, which constitutes the heart of the actual analysis activity: the search, identification and classification of vulnerabilities. It is a series of closely linked activities that require a good level of IT and procedural knowledge.
- Search for computer vulnerabilities
- Analysis of the vulnerabilities found
- Risk classification
- Production of a vulnerability report
In case you use a specific software, such as those made available by OWASP and / or by dedicated web services (such as the Vulnerability Management service of the Qualys Cloud Platform, available as a free trial for 30-60 days or free of charge in the community edition ), these activities will most likely be carried out automatically in a sequential manner, relieving the auditor (or operator) of most of the operational burdens: at the same time, it will be essential to review the product of the automatic procedures in the light of the reference scenario, as the risks associated with each detected vulnerability could be substantially different depending on the type of system and / or service, its exposure, the type of data it is designed to manage, etc: in other words, a context will be required. aware analysis that in all probability cannot be delegated to the software, requiring specific skills and in-depth knowledge of the context of reference.
Penetration Test
A fundamental part of the Vulnerability Assessment is given by the Penetration Test (also known as PenTest), i.e. the operational process with which the security features of the computer system being assessed are tested. This is a multi-stage analysis, in which the tester takes the point of view of a potential attacker by simulating the cyber attack of an attacker using programs and / or software suites specifically designed to perform this purpose.
Here is a non-exhaustive list of some of the most used software for penetration tests:
- Information Gathering: Maltego, FOCA, DNSEnum, DNSMap, TheHarvester;
- Scanning and Service Enumeration: Nmap, Hping, P0f, ARPing, DirBuster, Metasploit;
- Vulnerability Discovery: NeXpose, OpenVAS, WPScan, BurpSuite, SqlMap, Metasploit, Nikto, Beef, W3af scanner;
- Exploitation: Ettercap, Bettercap, SSLStrip, AirCrack, Metasploit, BurpSuite;
- Escalation Privileges: Metasploit, John the Ripper, Ophcrack.
As you can see, each software is specialized to simulate a very specific type of attack: for this reason it is important to know how to choose the right software according to what you intend to test, or the characteristics of the system being analyzed; once again, therefore, the importance of the human factor emerges, that is the added value given by the knowledge of the reference context and the risk assessment carried out for that specific scenario.
Regardless of the type of attack, each test aims to highlight the weaknesses of the platform by providing the greatest number of information on the vulnerabilities that have allowed unauthorized access, providing an estimate of the defense capabilities and the level of penetration achieved. . Both external and internal vulnerabilities in the system are scanned.
What is the PenTest for?
At this point it may be useful to clear the field of a frequent misunderstanding that generates the Penetration Test in the more general context of the Vulnerability Assessment of which it usually forms part: the belief that relying on it to speed up the search for one's vulnerabilities can be an advantageous choice or in some way viable: unfortunately, without fear of exaggerating, we can say that thinking this way means making a serious error of evaluation. The PenTest should rather be understood as a means that allows you to discover an unexpected situation, an unexpected "flaw" that can be exploited by a potential particularly ingenious external attacker, perhaps by exploiting a recent or little-known vulnerability: it is not the correct way to verify the maintenance of a system in terms of IT security, as there is no guarantee that the tests carried out are exhaustive or test the infrastructure in all its weaknesses: for example, they could be greatly ineffective in discovering problems related to the methods of antivirus scanning of attachments received via e-mail or other channels (SFTP, FTP, upload, etc), or updating operating system components that cannot be exploited from the outside.
In more general terms, it is correct to state that the Penetration Test cannot be considered a protection tool and certainly does not allow you to create an effective mapping of your vulnerabilities. This obviously does not mean that it is not an important resource for measuring the strength of our system: the point is that it fulfills a different and specific function, that is to help us discover new and unexpected vulnerabilities to add to the existing mapping and to manage and evaluate. like any other unexpected incident, or by means of risk analysis tools.
The proof of what we say is given by the fact that in an ideal security scenario, i.e. when all the vulnerabilities have been corrected appropriately, the Penetration Test will have no effect, as none of its simulated attacks will be able to take place. On the contrary, it will tend to be more effective (and therefore more "alarming") in all cases in which the necessary countermeasures have not been taken to reduce the risk of exposure to a possible cyber attack: in the next paragraphs we will dedicate ourselves to deepen two methodologies that play a fundamental role for the correct implementation of these countermeasures, known as Patch Management and Change Management.
Patch Management
Before being able to give a correct definition of patch management, it is advisable to take a step back and understand what is meant by the term patch. It is a word of Anglo-Saxon origin, which can be translated into Italian as "patch", which in the IT field indicates a particular type of software (or script) that has the task of correcting, updating or improving the functionality of an existing program: a synonym, or rather a particular type of patch, is the fix (also called bugfix).
The periodic updates that many commonly used application programs download from the web, including mobile apps, are a perfect example of a patch. The presence of the internet and devices permanently connected to the network has allowed software producers to carry out this activity almost automatically and almost imperceptibly by the end user, but this has not always been the case: until not many years ago, almost all of the patch was distributed exclusively through offline channels, leaving the user (or system administrator) with the task and responsibility of dealing with this delicate but very important activity, which is still called patching (sometimes Italianized in "patch").
Patching, that is the actual application and installation of patches, is an operation that today - as we have said - often occurs in a relatively automated and transparent way, but in some cases it may require particular attention: an effective example is given from updating the operating system of a mobile device, which in most cases will first involve a temporary block of the device (i.e. a certain period of time in which it cannot be used) and then a restart. It is therefore a patch that is applied "cold", that is, interrupting the execution of certain processes and services, unlike "hot" patches conducted in the background by special tools such as the iOS App Store or the Play Store of Android.
In a business context or, more generally, within an organization, it is clear that the patching activity cannot be entrusted to the good will of the individual user or to the unquestionable judgment of the system administrator. On the contrary, it is essential to have a specific procedure that provides for the periodic patching of all devices and software through a standardized process to be repeated at regular intervals, possibly based on notifications from official update channels and including an unalterable report confirming the 'operation took place: this we have just given is nothing more than the correct definition of Patch Management.
In all cases in which the patch management process is not formalized, not properly optimized or does not cover all applications at risk, the chances of having vulnerabilities - and therefore of undergoing a cyber attack - increase. This statement allows us to learn two fundamental lessons:
- Patch management must be based on risk, as it is necessary to establish which applications are most exposed in the usual terms of probability and impact.
- Patch management must be repeated every time our infrastructure is subject to change, at least in terms of risk assessment.
The change mentioned in the second point may be due to the introduction of new software, to the expansion of the network thanks to new peripherals, to the addition of an endpoint to one of the web services, but also to a "simple" system update. . This means that, in addition to Patch Management, we need a further standardized process that aims to update our Vulnerability Assessment every time the system changes: this function is performed by the set of methodologies known as Change Management.
Change Management
This is not the first time we have talked about Change Management: just a few days ago we published some insights on the subject, to retrieve which we refer to the article Change Management: what it is, how it works, how to deal with it. Here, for reasons of space, we will limit ourselves to repeating the most convincing definition of this important process:
A complex of structured activities aimed at building a transition path which, starting from the current situation (as-is), sets a goal (to-be) through a series of methodological choices (how-to).
In the article above we have highlighted how changes can take place as a result of two main eventualities:
- a proactive choice, in which the change initiative is taken following the decision of a stakeholder (eg management);
- a response to an event, in which the change initiative is determined by third-party circumstances (eg a regulatory provision);
In both cases, the change can be a response to a risk (understood as an incident, or an undesirable situation that should be remedied) or an attempt to exploit an opportunity (for example the advantages associated with a technological discovery); once again, therefore, risk analysis plays a fundamental role, to the point that all the main Change Management models that are most successful today (8-Step Model, ADKAR, etc.) are based on risk.
Maintaining the focus on risk analysis allows us to clearly understand the close relationship between Change Management and Patch Management in a Vulnerability Assessment context: having a risk-based Change Management means evaluating the impact, in terms of security , of any addition or modification made on your systems, which will therefore allow you to keep the Patch Management process constantly updated and optimized. After this process comes the Penetration Test, which allows you to protect yourself from threats that are not yet sufficiently known in compliance with the continuous improvement cycle at the basis of ISO 27001 and reaffirmed by the ENISA and AgID guidelines.
Conclusion
We've reached the end of our in-depth study on Vulnerability Assessment and on the processes that allow its correct implementation (Change Management, Patch Management and Penetration Test): we hope that the information we have shared will be of help to all interested parties, such as IT security specialist, system administrators and anyone else who work in the field of information security or is interested enough in understanding how these processes actually work.
