PenTesting And Vuln Management
by dasseclab
The Information Security world, like most technical fields, is full of its own unique lexicon – jargon, acronyms/backronyms and marketing gimmicks. However, I think infosec is unique in that its vocabulary is often misappropriated by non-technical folks and reasons why folks like Akamai wrote a post detailing the difference between vulnerability assessments & management and, as it is most inaccurately described, Penetration Testing. So, why is it these terms are often confused?
Of all of the terms to be misappropriate, I can’t say there is one pair more than vulnerability assessment and penetration test (granted, this is anecdotal observation). Often times, when I worked in SecOps, we would get client calls informing us that they would be running a ‘penetration test’; many times when we’d get that, it turns out that they were only getting their network scanned by Nessus. But what is it that makes these terms so easy to misuse? A thorough penetration test will include a brief vulnerability assessment as a part of its Discovery phase. But both are equally important components of a comprehensive vulnerability management program. One could also argue that everything might be lumped under ‘penetration test’ because it sounds cooler. It’s like a stress-test exercise – let’s push our defensive strategies, network controls and system hardening to the limit but without appropriate stress applied, it can leave an organization with bad data and an incomplete picture, possibly skewing the accurate portrayal of its defenses.
The Basics
The Akamai article laid out differences between the three terms, in hopes of keeping them from being utilized improperly (good luck, I’m right there with you!). For the sake of convenience, we’ll ignore scope and white/grey/black-hat associations. Vulnerability Assessments are performed against target systems to look for potential holes in their armor or ways to get in bypassing their defenses – open ports, improper configurations or expired software. This is just looking for stuff now. Once the vulnerabilities have been cataloged and report finalized, it then falls to clients or their outsourced firm, to analyze the vulnerabilities and enact a remediation strategy for said vulnerabilities. Common software to perform vulnerability assessments are nmap, Nessus, NetStumbler or Kismet. Penetration Testing goes the next logical step – actually acting on information discovered (usually as a part of an existing vulnerability assessment or the tester’s own assessment and reconnaissance). Once it finds the potential holes, the tester starts using active exploits to test whether a vulnerability is true or false positive. Perhaps the most common software among penetration testing is Metasploit.
These two pieces make up the concept of Vulnerability Management. Vulnerability management is the structural concept that is used to identify and manage risk against technical assets. Both Vulnerability Assessments and Penetration Tests are significant portions of a vulnerability management program but they are not the be-all-end-all of the program.
Designing The Vulnerability Management Program
Any company with any technical resources, particularly assets they own and manage, should have their own vulnerability management program. The program should scale with the company and roles, responsibilities and expectations may not determine the need for a full on Information Security team; instead, they can be run by members of the internal IT staff with expertise contracted out to to individuals or security consultants.
As noted earlier, the management program contains vulnerability assessments and penetration tests, but what are the other components that should be incorporated into the vulnerability management program? First, we have to determine scope of what we are managing. I denote this as Asset Risk. It’s nice to think of a server room or data center as these rooms full of machines with an egalitarian view that they are all equally important to the company – which is not always the case. They all play a role in the success of the company, yes; however, which would you rather have offline: the Intranet Webserver or the Credit Card Processor? Determining the asset risk highlights which environments and server clusters do which business activity and rate them against the impact of connection loss or data breach to the company. This also determines the scope – the internal corporate systems which hold HR, payroll and benefits data are subject to HIPPA compliance (in the US, local laws may vary but are assuredly more strict than the US), while the aforementioned credit processing machines are PCI-DSS controlled. Each compliance standard could have its own requirements and should not necessarily be treated as a one-size-fits-all solution.
Once the asset risk is determined and properly scoped, then comes the “choice” between vulnerability assessments and penetration tests. In my personal opinion, vulnerability assessments should be run with frequent iterations as a means of catching low-hanging fruit and reducing delay in getting vulnerabilities patched. Penetration Tests should be run at least annually, if not semi-annually or even quarterly (pending above compliance controls, of course). All classes of asset risk should be run through both vulnerability assessments and penetration tests at some point of the calendar year.
Next comes the Technical Risk phase. This takes the findings of the vulnerability assessment or penetration test and details what was found or exploited or if there were any potentials for false positives. This phase should be worked in conjunction with the team who performed the assessment or test, internal Security or Technology staff and appropriate (read: accountable) business leaders so that everyone understands the findings of the reports and technical risk can accurately be determined.
The final stage is Remediation. What’s the point of finding all of these vulnerabilities if you’re not going to fix them? This portion of the program is the one I have seen most neglected – usually compliance controls only indicate running penetration tests but have yet to keep up with remediation mandates beyond large, critical holes that will deny compliance. Remediation is the stage where plans are enacted to correct vulnerabilities determined to be of technical risk. My personal idea is that using Agile (or similar methodology) to assign values to remediation items based upon impact and complexity is a fine method to clean up vulnerabilities between assessments/tests. When vulnerabilities are said to be removed, an immediate follow-up assessment should be run to demonstrate the remediation and should concur with future assessments and tests.
Crowd Sourcing Vulnerability Assessments & Penetration Tests
The tech world seems interested in crowd-sourcing lots of things – success of Kickstarter, GoFundMe, and the like – show that people will often put up where some traditional funding models would not. This has also crossed over to vulnerability management. In The Before Times, if a vulnerability were discovered, many times the person who discovered it would contact someone at the offending product, hash it out and (hopefully) it would be fixed in a subsequent release. Let’s ignore responsible disclosure ethics and issue for now. Now, many tech companies are accepting exploits from users, students and independent researchers against their products and platforms, even going so far as to offer up open Bug Bounties. It works on a sliding scale where the most critical of bugs in production code will net the person who finds it some serious cash. While the vulnerability disclosure process is usually handled in a more private matter, anyone can attempt to find a bug for a bounty.
To me, this is a good idea, whether there is an official Bug Bounty Program in place or it is just accepting user submissions for fixing flaws in code. The only problem I see, thanks to my cynicism, is that this usually isn’t going to benefit the New Kids, who, honestly, are coding at all hours to get a product up and running and could really use a second set of eyes. It is a program that benefits the Popular Kids – Google, Facebook, Etsy, Twitter – that have large numbers of users and significant cultural impacts.
Whether incorporating a Bug Bounty Program or other crowd-sourcing vulnerability identification, it is important to maintain remediation strategies that coincide with the internal vulnerability management program. To properly remediate the vulnerabilities exposed via the bounty/crowd, vulnerable code should be assessed and determined in which environments may be affected. Once the environments are determined, the vulnerabilities can then be addressed according to out vulnerability assessment model and carried through the remediation stages and cataloged for future testing.
tags: