Paul Melson is information security officer at Priority Health, an insurance company in Grand Rapids, MI. he has been in IT for 13 years, focusing exclusively on security for the last seven. During his career Paul has also consulted on matters of incident response and compliance for government, financial, higher education and manufacturing industries.
STP: What’s the difference between penetration and vulnerability testing?
Paul Melson: Vulnerability testing is a subset of penetration testing, in which the tester attempts to identify the presence of vulnerabilities–typically publicly known vulnerabilities–in a system. Penetration takes this to the next level in several ways. The main difference is that penetration testers attempt to exploit vulnerabilities that they find and attempt to escalate privileges as far as they can go. This serves to simulate a targeted attack by an intelligent hacker and provide the client with a realistic understanding of the risk each vulnerability poses. Many penetration testers will also attempt to identify and exploit previously unknown [industry lingo: “zero day” or “0-day”] vulnerabilities.
What tools do you use?
Different testers use different tools, and there is some controversy about the use of automated scanners among pen testers. I believe based on my experience both as a consultant and a client that the use of network and Web scanning tools is prevalent even among pen testers. But there are those pen testers that vehemently deny that they use scanners. And to their point, a skilled tester will always do better than a scanner.
In many cases, a pen tester will write a custom tool to work on a tricky or new vulnerability and these tools get re used in later tests as well. Exploit frameworks and fuzzers are also frequently used in finding and exploiting zero day vulnerabilities.
But I think the one that would maybe surprise a few folks is that password guessers/crackers are still widely used. And they’re still widely used because they still work.
What are some common vulnerabilities?
Default or weak passwords, SQL injection, cross site scripting. And of course the first two are heavily used by the botnet/malware distributors to compromise a Web site and use it to attack Web browsers. There’s still a lot of work for developers, especially Web application developers, to do around input handling.
How we do we decide how much time and effort to invest in security?
Risk assessment, vulnerability scoring, threat modeling whatever you do and whatever you call it, at the end of the day you have to have a system to prioritize where you focus security resources.
Can you tell us a little more about that threat modeling thing?
Threat modeling is the current ideal way to prioritize security spend. I should first explain what the progression is, because in the real world you can’t always opt to do threat modeling.
Risk assessment prioritizes security spend based on the value of the assets you are trying to protect. This is the old school, but sometimes it’s all you have to go on.
Vulnerability scoring prioritizes security spend against known vulnerabilities/deficiencies by quantifying how likely a vulnerable or deficient system is to be attacked, the relative difficulty of a successful attack, and the consequence of a successful attack. Or, put more simply, a system’s Vulnerability Score (or Risk Score) is the product of its Likelihood, Exploitability, and Impact.
Threat modeling takes this goal to an additional level by analyzing a system, its environment, the transactional processes that it runs, and [develops] a detailed list of all of the potential threats against that system. Ideally this happens in the design stages of a project and the designers can plan to address each of the identified threats before work begins.
Peter Torr at Microsoft wrote a blog post about ‘Guerilla Threat Modeling’ that is probably the single best short piece on threat modeling.
How, exactly, can we ‘insert security throughout the life cycle’? What does that even mean?
First, I think it means making security a concern that is addressed at every step of design/build/maintain process.
As far as how to bake this in to the process, I wish I had an easy answer. In its simplest form, someone comes to the discussion asking, “What are our security risks and how do we address them?” Some good ideas that are practical include requiring security testing of systems before they can be put into production, using standards for commodity functions like authentication and logging, and using some tried and true security concepts like “least privilege” and “defense in depth” at the design phase. As much as security industry pundits have trashed it, defense in depth–building, documenting, and using mitigating controls at strategic points throughout a system–still works very well.
When are we finally going to have this ‘security’ testing thing locked down into a checklist and standardized?
There is already some excellent work out there in the area of codifying and standardizing Web security testing. OWASP has developed an excellent set of guides on secure development, code review, and security testing. I also believe that we won’t be “done” any time soon. Fifteen years ago nobody was doing code review and looking at buffer overflows. Ten years ago nobody was looking at input checking and SQL injection. Security testing will continue to evolve and progress for the foreseeable future. And now that there’s real money to be made on both the defensive and offensive sides of Web security, you can rest assured that new classes of vulnerabilities are right around the corner. ?
About the Author
Matt Heusser A consulting software tester and software process naturalist, Matt has spent the past 12 years or so developing, testing, and leading in dev/testing of computer software. Beyond the work itself, Matt has had notable roles as a part-time instructor in Information Systems at Calvin College, a contributing editor to Software Test & Performance Magazine, the lead organizer for the 2008 Workshop On Technical Debt, and most recently as Senior Editor for the “How To Reduce The Cost Of Software Testing” book project.