The risk-based approach to vulnerability patching: How to do it right
As businesses continue to produce and switch over to digital products, we see more cyberattacks and software flaws exploited for nefarious purposes. The number of small flaws in software that cause major issues can quickly get out of hand. Machine learning has produced a process known as risk-based vulnerability patching to help avoid this issue.
This article will discuss what a risk-based approach is, the patching processes, solutions to negate the risk of each issue, and a management plan for every part of the process. Sections will be broken down by the type of software and each part of the risk management process.
What is a risk-based approach?
The risk-based approach of having algorithms determine and rank the risk value of each software flaw allows companies to attack each problem by total damages. However, this approach can create hyper-focused attention resulting in other issues being neglected.
The problems are as follows:
- The lack of data -- Machine learning requires one major thing to work successfully: data. If data is missing or incorrect or losses are more than just financial or quantifiable, then the risk-based approach isn’t the best choice. There are also PR or even HR considerations that should be made. The classic CS quote may best sum up this issue -- "Garbage in, garbage out."
- Opinions -- Stakeholders sometimes want a say in where time and money should be spent, and people’s opinions are not quantifiable for the most part. Public judgment may be a major player in decision-making when patching, and those need to be considered.
Patching network vulnerabilities
Networks are the veins of any major business in the 21st century, and a hole in this system can lead to leaked information going places it is not supposed to or a virus or malware infection. Here’s a recommended process for patching network vulnerabilities.
Evaluate
After identifying a flaw in a network’s software, it’s important to determine how much risk this opening could cause. Can the flaw lead to the installation of spyware or other malware designed to scrape information? Does it allow access to databases of customer information or communication channels that could leave an opening for phishing attempts? Phishing attacks have increased by 61 percent compared to last year, so properly evaluating network vulnerabilities is critical to protecting your business.
Evaluations can be determined using a risk-based machine learning program valuing each flaw based on several variables, hardware or software-based.
Test
When testing a patch on a network, it’s important to create a non-production environment to host your critical assets on. An alternative would be testing on noncritical production devices with a given test audience. Make sure connections are safe and secure to reduce the chances of exploitation of the issue.
If outsourced, an external audit report like an SSAE 18 SOC Report or a standards-based questionnaire will most likely validate the vendor’s patching process as well as create an understanding of the process.
Approve
Once you have crafted a solid solution, create a short and easy-to-explain presentation covering:
- The issue
- The risk
- The solution
- How you plan to avoid these situations in the future
This will help build confidence in the development team’s capabilities to solve issues on the fly and serves as a reminder to team members and leadership how an issue was fixed for future reference.
Deploy
After confirmation by leadership and internal team members, release the patch solution. Track and record the solution in your task management system, and perhaps store the solution code in a separate file and share it with the appropriate individuals who could benefit from it as a learning experience.
Verify
After integration, test the strength of the patch by running a stress or penetration test. You can use tools like Solarwinds to conduct network traffic tests and verify they work well.
SEE ALSO: Taking the risk-based approach to vulnerability patching
Patching vulnerabilities in applications
Applications, whether internet, phone, or computer-based, can all have vulnerability issues, and these are typically customer-facing. That sets them apart from other types of software because you will have to admit that a flaw has been found at some point. You can patch app vulnerabilities using the following steps.
Evaluate
Applications, unlike networks, can lead to data mining or the loss of personal account information. Simple problems like displaying the wrong info or a design issue can also occur.
Collecting information on specific vulnerabilities can sometimes be easier to solve because users can submit screenshots or recordings of the problems they experience, making it easier to identify the problem. Ensure this task is tracked through your team’s task management software.
Test
After creating a patch, integrate it into a sandbox version of your software to confirm it works and doesn’t cause more small holes to fill. Using a sandbox mitigates this risk and is usually an oversight by smaller, less experienced development teams due to not wanting to spend the extra time it takes to set it all up.
Approve
After internal confirmation of the patch and updating the task management, release the patch. Unlike a network situation which is almost entirely internal to a company, an application is client-facing. This is where the two will separate in processes. Verify that the patch works and release it, but do not let your clients know unless it was a major flaw and important to fix immediately. If this issue was minor, wait until you have fixed a few more.
Update
After multiple issues have been patched, create a public release to your clients about the application update and patches that were made. You don’t want to send an update about each fix because if you send an email update out as most companies do, you will increase the spam rate of your emails. This can inevitably become a major problem in the future when notifying users.
API vulnerability patching
APIs combine the worlds and workflows of both networks and applications. Like applications, clients use them as products, but like networks, major changes are internal until large updates are publicly released. Here’s how you can patch vulnerabilities found in APIs.
Evaluate
Evaluation of API or OS vulnerabilities can usually be found in the authentication and tokenization of the services. And increasingly, they have been the subject of cyberattacks due to the data they typically deal with, such as a Stripe API for payment processing.
Test
When testing an API, a dynamic application security test (DAST) should be run in a sandbox with a testing application and integration. If you are using an API, do a software composition analysis (SCA) before integrating to verify its authenticity and safety. It may even be beneficial to run a third-party SCA on your API to see what will appear to users of your product.
Approve
The approval process of your product will vary depending on whether your API is internal or external. With internal verification, the team is aware of the update, and leadership has acknowledged completion. If your API is external to your business, verify and log updates and inform leadership, but wait for the release.
Update
With external APIs like other commercial applications, package multiple patches into a larger update or release to reduce smaller, more frequent communications.
Verify
Finally, verify your improvements by possibly integrating a communication system directly into your software. Having a way for users to reach out to support about an issue they are noticing will reduce the time it takes to fix a problem. It can also help improve customer satisfaction by allowing open communication lines between your business and clients.
Photo Credit: Olivier Le Moal / Shutterstock
Lee Li is a project manager and B2B copywriter with a decade of experience in the Chinese fintech startup space as a PM for TaoBao, MeitTuan, and DouYin (now TikTok).