Vulnerability Management

This chapter is about vulnerability management. In order to build a strong security program and lower your company’s risk, you must patch security vulnerabilities. If you stay up with the latest threats, you will understand that it’s not easy to keep up with patching all those thousands of vulnerabilities. We’ll be discussing practical strategies to prioritize vulnerability patching.

In this chapter, we’re going to cover the following main topics:

• What are software vulnerabilities?
• Prioritizing your remediations
• Securing your code

What are software vulnerabilities?

A software vulnerability is a flaw or weakness in a software program that can be exploited by hackers to compromise the system’s security. Software vulnerabilities can be introduced in several ways, such as the following:

• A developer not trained on the Open Worldwide Application Security Project (OWASP) Top 10
• An old vulnerability that has been patched is mistakenly reintroduced in the code
• Sometimes, hackers discover how to exploit the code after it has been published

When I was at RedSeal, I voluntarily created a Threat Response team. What we did was review the latest vulnerabilities, decide on the most severe, and write up a blog post about how our customers could use RedSeal to quickly discover, act, and patch the vulnerability. One thing you will realize once you begin taking notice of the latest vulnerabilities over a period of time is the same vulnerabilities come up again and again. Even though it seems like thousands...

Prioritizing your remediations

Vulnerability prioritization is the only way to properly deal with the enormous number of vulnerabilities that are published on a daily basis. Just because a CVE is rated as a 10 doesn’t necessarily mean that it is the highest priority to remediate at your company. I know this seems counter-intuitive, but there are several factors you need to take into account when prioritizing vulnerabilities:

• CISA’s KEV Catalog
• CVSS metrics:
  • Attack Vector
  • Attack Complexity
  • Privileges Required
• CVE score

CISA’s KEV Catalog

CISA created a known exploited vulnerability catalog that is invaluable when deciding which vulnerabilities to patch and by when. Essentially, when it’s discovered that hackers are exploiting a specific vulnerability, CISA will add it to the catalog with a due date. As you can see in Figure 8.3, CISA has the CVE ID, vendor, description, action to take, and due date. The due date is critical and needs...

Securing your code

If your company develops code, then you need to scan the code for vulnerabilities and test the code prior to release. With continuous integration, delivery, and deployment, also known as CI/CD, you must automate the code. First, Infrastructure as Code (IaC) must be used to provide consistency. In addition, scanning and testing your code as part of your secure development life cycle is mandatory. There are several tools that you will want to use as part of this testing: static application security testing (SAST), dynamic application security testing (DAST), interactive application security testing (IAST), and vulnerability scanning of your code. You will need to do this to ensure your code doesn’t have vulnerabilities in it.

IaC

IaC leverages DevOps methodologies and version control, employing a descriptive model to manage and provision infrastructure components such as networks, virtual machines (VMs), load balancers, and connection topologies. This...

Summary

In summary, unpatched vulnerabilities can lead to multi-million dollar losses. Of course, having that one vulnerability on an external web server that lets the hacker in is a major concern. Also, consider the cost of a vulnerability that is not immediately found prior to the release of the code is going to cost your company a lot more in having to deal with fixing it after the fact, and it will also cause friction for your customers.

In the next chapter, we will be covering asset inventory. You have to know what assets you have in order to protect them.