Vulnerability Management: A risk exercise for all

Vulnerability management might not be everyone’s favorite topic regarding cybersecurity. In my experience, it has often been viewed as the least exciting part of the cybersecurity program. However, vulnerability (vuln) management is one of the most critical parts of your security program. Let’s think of some of the areas that fall under its purview:

• “Patch Tuesday” is when many major vendors release patches to their operating systems and software. Patch Tuesday typically applies to COTS (commercial off-the-shelf) software, where the end user is responsible for downloading and installing the patch or the latest version of the software to remediate any vulnerabilities or performance improvements.
• “Hotfixes” are temporary patches meant to quickly mitigate a vulnerability while the more permanent patch or upgrade is being developed.
• “Virtual patches” script or code is meant to alter the environment where the vulnerability or application lives to prevent or block the use of the vulnerable code.
• “Misconfigurations” are general variables in the software or environment that allow more access than the organization intended or allow it to be used in unintended ways.

While this is not an all-inclusive list, hopefully, you get the idea. Now you may be asking yourself, where does a company get a list of all these items to try to fix them? That is part of the challenge of the vuln management space. The vuln management, application security team, and others need to monitor when these might be published (ok, some have auto-update agents to bring them to you), research, develop their solutions, or use community-driven solutions. Now you might be thinking that you are ready to go out a “patch” to remediate these vulnerabilities, but you have not yet detected or identified them.

The first stage of vuln management is finding the vulnerabilities in the first place. While many, when you have done this in your home, you installed all the updates your software told you about, it might not be as easy in a corporate environment. You might want to test the patch to ensure that it does not break the functionality of the application being patched. The application might be in an environment where it will not be able to reach out to the update servers directly, and you have to bring the patches to them. And depending on the company or environment, there might be more restrictions you need to consider.

One of the most common ways of finding vulnerabilities and misconfigurations is using scanners designed for this purpose. They scan the application and the internal environment and report the list of vulnerabilities or misconfigurations it sees compared to the list of vulns it has in its database. They will look for known vulnerabilities, known patterns of misconfiguration, and even known patterns of software & environmental secrets. With vuln management, one caveat you need to keep in mind, if the vuln scanner does not have a new vulnerability in its database, it will not be able to detect it. Now there are many different types of vuln scanners: there are those for on-prem infrastructure, cloud infrastructure, virtualized environments, containers (of various kinds), and then you go into application focus vulns using application security scanners with static, dynamics, application libraries, images (bases for containers), code repositories and more. The challenge with this method is that there is limited or no contextualization of the risk or the controls which might already be in place to mitigate that risk.

Following teams are to perform testing closer to their development operations. Many might label this as “shifting left,” I would consider it an opportunity to enable developers to see potential bugs in their code sooner in the development process. The options for this include testing the code with static application security testing (SAST), which can look at the code at the line, unit, or component level. As the code is now at the stage where it will function with other code, Dynamic Application Security Testing (DAST) can then be used to see how the code works together and how that may/may not cause vulnerabilities or misconfigurations. Other opportunities include scanning open source software (OSS) code libraries and code libraries from in-house development. An IDE (integrated development environment) plugin would provide the ability to notify developers that the code they just wrote has s a potential vulnerability or has misconfigurations.

All companies, including those with an on-premise environment, must consider scanning their external cloud posture using Cloud Security Posture Management. To ensure that your modern applications are secure, validate that your API (Application Programmatic Interface) has proper business logic for access controls, content validation, and inter-API access. Finally, use firewalls, proxies, cloud access security brokers, and email attachment scanners to ensure that data might not leave your organization without your knowledge.

So far, we have mainly discussed the process of the identification of vulnerabilities and misconfigurations, the remediation activities related to risk mitigation, patch management, and ensuring that patching the vulnerabilities does not inherently damage the business’s ability to deliver on its business mission. Vulnerability Management is a cross-organizational activity requiring the company to work with information technology and security teams to balance the productivity needed for new or existing features with the need to ensure that the units adequately manage vulnerabilities and misconfigurations. While working with the organization on balancing the potentially overpowering demands of vulnerability management over the production of new features or infrastructure, understanding the full security context of the vulnerabilities and potentially risk sloping them to help with that.