Database security testing terms: Setting the record straight

There are differences among three commonly used database security testing terms. IT security specialist Kevin Beaver shares the characteristics that set apart security audits, penetration tests and vulnerability assessments.

Something has been bugging me in the field of information security for quite a while. It has to do with how we

often use these security testing terms: security audit, penetration test and vulnerability assessment interchangeably. Call me anal retentive, too logical or just a normal guy working in the field of IT. It still bugs me. Information security has its foundations in math and logic so it is what it is.

Much of the confusion stems from how people look at IT and information security as a whole. Some see it as purely a technical drill, while others look at things from an IT governance perspective. So, to set the record straight, here are the differences between security audits, penetration tests, and vulnerability assessments:

Security audits
A security audit determines what you say you're doing (via policy) or must be doing (via regulatory requirements) versus what's actually being done. Here are some characteristics of a typical security audit:

  • Very structured and methodical often with a very defined scope
  • Focus is on whether controls exist or not
  • Not very technical – often based on checklists
  • Typically reference law/regulation statutes or security framework sections
  • May or may not use security testing tools and scanners
  • Usually performed while logged in the systems being analyzed – typically as an administrator or equivalent
  • Often involves business process and policy reviews

Penetration tests
A penetration test looks through the eyes of a malicious attacker to determine which vulnerabilities – typically in externally-facing systems – can be exploited and what level of access can be gained. Here are some characteristics of a typical penetration test:

  • Tightly defined scope such as Web applications and database servers
  • Less structured – more of a free for all – at least during the system reconnaissance and enumeration phases
  • Can require highly technical skills
  • A relatively small toolset is needed
  • Typically requires manual analysis and exploitation
  • May incorporate social engineering testing
  • Can be time sensitive
  • Serves as a good starting point for more in-depth vulnerability testing
  • Doesn't provide the whole security picture – especially for systems that are only accessible via the internal network

Vulnerability assessments
A vulnerability assessment roots out security vulnerabilities in both external and internal systems. Here are some characteristics of a typical vulnerability assessment:

  • More in-depth and structured than a penetration test. Incorporates entire networks and sets of databases and applications into the scope
  • May or may not include exploitation of vulnerabilities once they're found
  • A large toolset is needed to discover a maximum number of vulnerabilities
  • Often confused with a basic automated scan (which typically only provides minimal value)

So, what about the often used term ethical hacking? Well, it sort of encompasses both penetration tests and vulnerability assessments. To me, it's

More on SQL Server Security:
  • SQL Server patch pros and cons
  • Protecting your database: Who's looking at your sensitive data?
  • Guide: SQL Server encryption
  • the best of both worlds. For fear of sounding too goofy, I usually just refer to my ethical hacking work as "security testing" in general.

    There's no wrong way of analyzing database security – just wrong ways of classifying how you're doing it. That said, using the tools and techniques of a malicious attacker via ethical hacking will undoubtedly uncover many more flaws in your database environment than a high-level security audit ever will. It's the only true way to see where you're security is weak.

    Everyone has an opinion about defining the different types of database security analysis, in the same way everyone has differing views on information risk. In the end, all three types have essentially the same goal: to enhance information security within the business. It all depends on how you look at it and what you want to get out of it. The technicalities could be argued all day long. That's okay. We can all get along as long as our systems are secure, right? Just know the differences among the terms for database security testing because technically they do exist. Doing so will help you talk the talk and ensure you're getting what you really want and what your business needs.


    ABOUT THE AUTHOR:   
    Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic, LLC. He has more than 18 years of experience in IT and specializes in performing information security assessments revolving around compliance and IT governance. Kevin has authored/co-authored six books on information security including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley) as well as The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). He also created the Security On Wheels audiobook series. Kevin can be reached at kbeaver ~at~ principlelogic.com.
    Copyright 2007 TechTarget


    This was first published in October 2007

    Dig deeper on SQL Server Security

    Pro+

    Features

    Enjoy the benefits of Pro+ membership, learn more and join.

    0 comments

    Oldest 

    Forgot Password?

    No problem! Submit your e-mail address below. We'll send you an email containing your password.

    Your password has been sent to:

    SearchBusinessAnalytics

    SearchDataCenter

    SearchDataManagement

    SearchAWS

    SearchOracle

    SearchContentManagement

    SearchWindowsServer

    Close