Vulnerability Assessment: A Guide
Table of Contents
The complexity of technology is ever-increasing and the number of breaches (and the cost of dealing with them) is growing right along with it. Governments are cracking down and turning cybersecurity from nice to have to absolutely mandatory. In response, organizations across industries are taking a more serious look at their security posture and, with that, the need to perform thorough vulnerability assessments.
What is a vulnerability assessment?
A vulnerability assessment is a process of defining, identifying, classifying, and prioritizing vulnerabilities in your organization’s applications, systems, and network for the purpose of understanding your risks and formulating a strategy to improve your security.
At the core of vulnerability assessment is a reliance on automated testing tools that seek out known and potential vulnerabilities and bring them to the attention of security professionals and developers who can investigate and remediate as needed.
Why is it important?
As recent major attacks like Log4j and SolarWinds have shown, the costs of a vulnerability can be very high. To stay secure, constant vigilance is needed, meaning good security practices require vulnerability assessment to be a repeated process, in some ways even daily, rather than a one and done.
What are the main types of vulnerability assessments
As noted above, a vulnerability assessment should be carried out for all the elements of an organization’s infrastructure and assets. Attackers know that they have multiple routes of entry into an organization, so it is important to take a comprehensive approach that denies them access across the board. This requires the following types of assessment:
- Host assessment – Take a hard look at hardware. Are your server, workstation, and laptop operating systems up to date with the latest security patches? Are your servers correctly configured with open ports properly protected with firewalls?
- Networks and wireless assessment – Reports of the demise of the perimeter have been greatly exaggerated. Are you defining policies and implementing practices that will keep intruders from roaming freely around your network?
- Database assessment – How we store our data matters. Is it configured correctly to keep prying eyes out? Mistakes in your AWS S3 or MongoDB configs can leave your precious info exposed, so you had better be sure that you are tracking all of your databases and confirming that they are being secured.
- Application scans – Whether front facing or on the back end, applications are the gateway to your organization’s data, so you should use technologies for testing your proprietary code such as Static Application Security Testing (SAST), while Software Composition Analysis detects open source components with known vulnerabilities.
What is the vulnerability assessment process? How does it work?
The vulnerability assessment process can be broken down into four steps: identifying vulnerabilities, analyzing vulnerabilities, assessing actual risk, and remediation.
- Identifying vulnerabilities — The first step is to use both manual processes and automated scanning tools to find all of the potential problems you are facing. The outcome of this step is a list of all vulnerabilities.
- Analyzing vulnerabilities — Now that you have a list, it’s time to dive deeper into each vulnerability. What is the root cause of a particular vulnerability and which components of your infrastructure are responsible for it? This step should leave you with a good map of your systems and what remediation will be necessary.
- Assessing risk — You can’t realistically fix everything at once. Assessing risk means considering how easily a particular vulnerability could be exploited, how costly an attack would be, and how critical the data, systems, and business functions affected by it are to your organization. Once you have completed this step you will have a prioritized list of vulnerabilities which brings us to…
- Remediation — Finally it’s time to go down that prioritized list and close the holes in your security. This step will likely require the efforts of both security and devops teams and may include updates to software, changes to configurations, and the development and implementation of vulnerability patches.
Five vulnerability assessment misconceptions from the experts at Mend.io
Even if your teams are already running tests for vulnerabilities, they may be falling prey to a number of common misconceptions that can lead to costly mistakes.
We asked our vulnerability experts here at Mend.io about the worst misconceptions that they have seen, so that you can avoid them.
1. Vulnerabilities are written with malicious intent
Despite the long-held belief among many security professionals, developers do not go out of their way to write vulnerabilities into their code. With very few exceptions, security vulnerabilities are simply bugs and mistakes by developers. Of course, malicious actors don’t care about developers’ intentions; they’re banking on them making mistakes and you not catching them. Cybercriminals may be a minority numerically, but their impact can be huge. It only takes one successful attack like SolarWinds or Log4Shell to cause havoc across multiple organizations.
Application security testing tools seek out these potential errors, flagging them for review before the software makes its way out to deployment.
2. It’s security or DevOps job to handle vulnerability assessments
Back in the day when new software was released once a quarter or so, it was perhaps more reasonable to expect that the security or ops teams alone could carry out vulnerability assessments. Developers just had to care about whether or not the product was working and out on time.
Those days are long gone. The concept of shifting security left has now gained traction and developers have the means to keep code secure themselves, meaning they can integrate automated vulnerability assessment tools into their coding environment to catch vulnerabilities early while they are still easy to fix. However, they need to do it at an unprecedented scale and speed. This can be challenging, when some may lack the familiarity and expertise needed to deal with the remediation of the vulnerabilities.
3. You can shortcut security
It can be tempting to run a vulnerability assessment only on what you believe to be the most critical servers or layers of your network and call it a day. However, by leaving possible entry points into your environment open, you run the risk of being caught exposed. That said, prioritization does play an important role in planning what vulnerabilities to remediate. Do start with the systems that are the most critical to your business. Then work from there. Just make sure that everything gets some love and attention.
4. Your vulnerability assessment showed up clean, so you’re in the clear
Sometimes the results of your vulnerability assessment scans will show up cleaner than expected. Take care! You may discover that your data is simply inaccurate. Check and see if it is consistent with past results. More likely is that other vulnerabilities are hidden in the indirect dependencies that you simply can’t see.
Also remember that your vulnerability assessment only gives you a snapshot of where you stand at a specific point in time. New vulnerabilities emerge all the time, so you need to beware of them. Moreover, changes are always being made to databases or applications as they move through the SDLC.
That’s why you should run security testing continuously along with your assessments, adjusting as needed according to your findings.
5. Running a vulnerability assessment is the same as penetration testing
Vulnerability assessments and pentesting are not the same thing. Instead, they are a part of the same larger process in that the vulnerability assessment is the part that identifies potential weaknesses in your environment, whereas the pentest actually has someone poking around to see what will break.
In short, one step comes after the other, not in place of it. You need them both. An ethical hacker will run a proper vulnerability assessment to generate a to-do list of weaknesses that they should test out. Hopefully, they will use it as a starting point and have their own set of tests that can identify ways to break in, helping your team to remedy situations before someone not on your payroll decides to give it a try for themselves.
Although they complement each other, vulnerability assessment is generally less expensive than pentesting and should be done much more frequently. You can maximize your security spending by identifying and remediating all low hanging fruit through vulnerability assessment, leaving pentesting to take care of business logic flaws that may be missed by automated tools.
Some AppSec vulnerability assessment tools
The application layer is just one of many that need to be considered for your vulnerability assessment, but it’s a big one that takes a lot of effort and care to make secure.
For open source code
Open source code typically accounts for 60 to 90 percent of all code used in modern software products. If all code is equally likely to contain vulnerabilities, your open source components are naturally going to be the source of most of your vulnerabilities. Likewise, nearly all open source licenses require public disclosure that a particular open source component is being used, meaning malicious actors have insight into a large part of your codebase.
So, performing vulnerability assessments on open source software is vital and the best tool for the job is Software Composition Analysis (SCA). When choosing an SCA, go for one with a low false positive rate and robust open source license tracking like Mend SCA.
For custom code
Even the best developers make mistakes sometimes. Custom code may be a smaller percentage of modern software but it still needs to be checked for vulnerabilities. Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) are two important and complementary tools for vulnerability assessments. SAST uses whitebox testing that integrates more readily into your continuous integration/continuous development (CI/CD) pipeline and can find security vulnerabilities even before code is fully functional. DAST, on the other hand, uses blackbox testing to check already built code for security issues.
For cloud
The SCA tool you pick should support cloud applications just as it does your on-prem code and be able to scan your containers and Docker images and find vulnerabilities in your cloud applications. Another concern for cloud-based application security is dependency management. Cloud applications rely on a lot of microservices which each have many dependencies which can become outdated and missing important security patches. You can easily scan your repositories for outdated packages with a dependency management tool like Renovate, while Mend SCA protects cloud-native applications throughout the software development lifecycle.
Best practice for vulnerability assessment on enterprise networks
The scale and pace of enterprise networks make automation and comprehensive solutions a must. We know you’re busy so here are just two very brief pieces of advice to consider.
Get fully covered
Combine SCA and SAST tools to ensure that your entire codebase is comprehensively assessed and protected. Use one unified solution to simplify the process for yourself and for your developers.
Make security easy to adopt
Automate remediation by using tools that integrate seamlessly into your developers’ workflow. Don’t make them have to remember to launch a tool; make sure it’s already in their preferred repository, registry, IDE, package manager, or build tool.
Vulnerability assessment: Make sure all of your bases are covered
Running a vulnerability assessment is the first step towards making your organization more secure but remember that there is still a long road ahead. Now is the time to follow up on the results of your vulnerability assessment, combing through the findings and remediating vulnerabilities along the way.
Security expert celeb Bruce Schneider is famous for saying once that, “Security is a process, not a product,” underlying the fact that it is not enough to have products that can perform scans of your apps, networks, and systems. What is needed is for everyone in an organization to ensure that they are updating to the latest versions of the software that they are using and following other security best practices to stay a step ahead of the attackers.
Just remember that good security is practiced on an ongoing basis, not just at quarterly security reviews.
