Unauthenticated vs. authenticated security testing

You've heard the common response to many information security questions: It all depends. This is especially true when it comes to the

Desktop management tips from SearchEnterpriseDesktop.com Sign up for our additional editions of SearchEnterpriseDesktop.com's Desktop Management Adviser to learn more about desktop management, security and virtualization.

question of whether or not to perform your security testing as an untrusted outsider or a trusted user.

So let me go ahead and answer this: Sometimes you need to look at security flaws from both perspectives and other times you don't. It really does depend on the situation. I know such a generality is not good enough in most situations, especially when business risks and compliance are on the line.

So, let's dive in a little further and outline the things you really need to know about both types of security testing, and I'll throw in my opinion on what really needs to be done.

Testing security from the outside

Let's start with unauthenticated testing -- looking at your Windows environment from a true outsider's perspective. No user IDs and no passwords. It's the systems that are accessible from the outside through the eyes of a malicious attacker, or on the inside through the eyes of someone who has gained physical access but doesn't have the ability to log on.

There are several benefits associated with unauthenticated or "logged-out" testing:

1. It's easier.
2. It requires fewer testing tools.
3. It requires fewer internal staff resources.
4. You can still exploit a vulnerability to gain a remote command prompt, etc.
5. It can often be done without time constraints.

All in all, unauthenticated testing from an "external" point of view tends to be very focused, quickly resulting in a finite set of results with little cost to your organization.

But is unauthenticated testing enough?

There's a dark secret with unauthenticated testing. No matter what you're looking at, be it operating systems, specific applications, wireless communications and so on, you won't find some vulnerabilities unless you're testing as a logged-in user. I typically find the most detrimental vulnerabilities inside the network as a trusted user -- and a regular user at that.

No special administrative privileges are needed. You can authenticate as an admin, but I'm not confident that that buys you much of anything. Using automated tools and manual techniques, you uncover what an otherwise run-of-the-mill insider (at the local and/or domain level) can do to your systems. You'll then see the rest of the story. This next level of testing is something that's often taken for granted or overlooked altogether, but it needs to be done.

Testing security as a trusted user

Given its benefits, authenticated testing is not so simple. Here are some of the downsides to authenticated testing that most people have to learn the hard way:

1. It's more difficult and often requires more advanced manual analysis and hacking techniques.
2. It requires more testing tools.
3. It can easily double or triple the amount of time it takes to test all key areas for vulnerabilities.
4. It often requires getting other people (admins, developers and so on) involved to set up test accounts and monitor/manage the systems.
5. You can typically exploit more vulnerabilities, but at the same time that can put data integrity at risk, depending on the systems you're testing and the tools you're using.
6. Given that it can use up more system resources (again, depending on the systems and tools involved), it may require certain time constraints so that testing is only done during off hours.

These pros and cons of unauthenticated and authenticated testing highlight the need to define -- with clarity -- what it is you're trying to accomplish with your security testing. Do you only need to find out what an outsider can do? If so, then unauthenticated testing may be the way to go. On the flip side, have you thought about what a trusted user or someone who gains trusted user access can get into? If not, you may very well need to perform authenticated testing. It all depends.

Ultimately, I recommend doing both types of testing. Until you test your systems from every possible angle, you simply cannot say with reasonable certainty just where things stand with security. You don't need perfection, and you certainly don't need to test every single system in your Windows environment right off the bat. Start with a small cross section of systems and grow your scope from there as your refine your processes and get to know your testing tools better. You'll find that the greatest system weaknesses are found from both outside your network as well as right there in your own backyard.

About the author: Kevin Beaver is an information security consultant, keynote speaker and expert witness with Atlanta-based Principle Logic LLC where he specializes in performing independent security assessments. Kevin has authored/co-authored seven books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security On Wheels information security audio books and blog, which provide security learning for IT professionals on the go. Kevin can be reached at kbeaver@principlelogic.com.