In response to the ever-growing list of breaches that have come to light in recent years, organizations across industries are taking a more serious approach to the need to perform a thorough 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 the risks and formulating a strategy to improve security.
At the core of vulnerability assessment is a reliance on automated testing tools that seek out known and potential vulnerabilities, bringing them to the attention of security professionals and developers who can investigate and remediate when needed.
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.
Testing should cover assets such as:
#1 Applications – Whether front facing or on the back end, applications are the gateway to your organization’s data. Technologies for testing your proprietary code include Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), and Runtime Application Self Protection (RASP), while Software Composition Analysis (SCA) detects open source components with known vulnerabilities.
#2 Databases – 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.
#3 Network – 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?
While there are other areas such as the host servers that need to be inspected, in the era of Infrastructure as a Service (ie. the cloud), these are some of the most pressing areas that are in need of a thorough vulnerability assessment.
Even as teams run their tests for vulnerabilities, there a number of common misperceptions out in the community that can lead to painful and possibly costly mistakes later down the line.
We asked our vulnerability experts here at Mend to give us the worst misconceptions that they have seen out there in the wild in hopes that others can avoid making them when it really counts.
Despite the long-held belief among many a security professional, 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. What makes them different from a regular bug is that instead of just breaking the functionality of the software, it can give a miscreant a way to have a harmful impact on the victim.
We need to remember that developers are people too, and should be allowed to make mistakes without getting their heads bitten off. Hopefully you are using application security testing tools that seek out potential errors, flagging them for review before the software makes its way out to deployment.
While most vulnerabilities are mistakes, in some cases there are intentional actors who play on the good faith of others in the open source developer community. In 2018 we saw a case where hackers took over commit rights for the Event-Stream NPM package that was used as an important dependency for a cryptocurrency wallet called Copay. They then proceeded to inject malicious code for their attack, making off with some ill-gotten Bitcoins.
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 could be on top of carrying out vulnerability assessments. Developers just had to care about whether or not the product was working and out on time.
These days are long gone, and developers are doing it for themselves.
However given the scale of today’s code base, not to mention the ratio of 1 security professional to 10 DevOps to 100 developers, it is all hands on deck. In order to keep up with the challenge of handling all the assessment work needed, developers need to be on the front lines by performing the brunt of the work themselves.
Taking a step back, the approach actually makes a lot of sense given the current state of coding. For starters, many security professionals lack the familiarity and expertise needed to deal with the remediation of the vulnerabilities. But more importantly is the concept of shifting security left where possible, and in this case it is towards the developers who can integrate automated vulnerability assessment tools into their coding environment to catch vulnerabilities early while they are still easy to fix.
All is fair in love and (cyber)war. Hackers looking to probe your network don’t really care about which assets you had on your vulnerability assessment checklist. They are going to poke around until they hit paydirt, so you had better make sure that you perform those checks before they have the chance.
It can be tempting to just run a vulnerability assessment on what you believe to be your 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.
If we are being practical then we acknowledge that prioritization does play an important role in planning out the order of work. We recommend to start with the systems that the most critical to your business and then work from there. Just make sure that everything gets some love and attention.
Sometimes the results of your vulnerability assessment scans will show up cleaner than you initially may have hoped for. Enjoy the moment and then it is time to take a look under the hood to see what is really going on.
In some instances you may discover that our data is simply not accurate. Check and see if it is consistent with past results.
However, what is probably more likely when it comes to the security of your applications is that while the app itself might not turn up any vulnerabilities during a scan, there are probably others hidden in the indirect dependencies that you are simply not seeing.
We need to also remember that our vulnerability assessment is only giving us a snapshot of where we stand at a specific point in time. New vulnerabilities are being discovered all the time by talented security researchers, so we need to stay on top of vulnerability publications. Moreover, changes are always being made to our databases or application as it moves throughout the SDLC.
This is why you should be running security testing continuously along with your assessments, adjusting as needed according to your findings.
So just remember that no matter how good you are, there are always vulnerabilities beneath the surface.
Two sides of the same coin, vulnerability assessments and pentesting are not the same thing. Instead, they are a part of the same process in that the vulnerability assessment is the process that identifies potential weaknesses in your environment, where as 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. A Whitehat hacker will run a proper vulnerability assessment to generate a to do list of weaknesses that he or she should test out. Hopefully they will use it as a starting point and have their own set of tests that they can use to tease out ways to break in, helping your team to remedy the situation before someone not on your payroll decides to give it a try for themselves.
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 which 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.