
A real-world example
We had an important database server running on MySQL. After a few months, a high-risk vulnerability was discovered on the MySQL version that we were running and as a part of the compliance program, we had to mitigate the risk, which is mostly done through the monthly patching activity via Spacewalk.
However, it was a very important database server, and any case of stopping the MySQL would lead to a big impact on the business and thus approval was not being granted.
We checked if a virtual patch was available for the specific MySQL vulnerability for which we wanted the upgrade, and it was available in Deep Security, so we decided to install the Deep Security agent in the database server with the IPS module enabled and thus mitigate the risk associated with the vulnerability, thereby upgrading the MySQL server after a few weeks when we got the go-ahead from the business.
Although it's very important to patch the vulnerabilities according to the risk involved in time, there will always be use cases, where the decision might not be in your hands. In such cases, we need to be prepared for what the alternative ways would be to mitigate the risk in case patching might not be possible.
In the following image, we can see the IPS Rules, as well as the virtual patch, that are available against certain vulnerabilities:
