Take the account into account

“Which account do I have to use for my test?”.  Maybe, this question is very trivial but in fact it isn’t.  The context in which a test is performed and a specific type of account is used, can impact the results of a test, even in such a way, that it could show false positive results.

Example
In context of a workstation migration (e.g. WinXP -> Win7), tester John BugFinder is asked to do regression testing for an application called “Tax Predictor”. He is the business key user. His Windows account “jbugfinder” is added in Active Directory (AD) to the appropriate security groups. The current WinXP workstation is locked down (meaning no (local) admin rights are available for the user).

So, let us now answer the question: “Which account does John Bugfinder need to use for his test?”. Firstly, there is not one sole answer to this question as there are several options as described below:

• John performs the test with his WinXP account
  This seems to be the easiest and surest solution, as he has already all required rights and accesses. Moreover, he should have access to his mailbox as well.
  However, the risk on a corrupt roaming profile is the biggest drawback of this option. The folder structure of user profiles in WinXP and Win7 is quite different.   So, if John works simultaneously on both workstations his profile can become corrupt or overwritten when he logs off.
• John performs the test with a general test account
  To avoid the drawback of previous option, a general test account could be set up (e.g. WinTest01). This is safer in terms of roaming profile but it requires more work to mimic his WinXP profile because the account must be added to all security groups in AD.
  Another complexity with this option could be the setup of access to functional mailboxes. This must be configured as well for the general test account.
  From security and governance point of view, working with general test accounts is not recommended since there is no traceability. As workaround, it is possible to note down on daily basis which actual user is using the WinTest01 account.
  Besides this administration of following up the account, if other applications need to be tested, the general test account must be added to the corresponding security groups in AD.
  By doing this, a kind of “super account” is created with access to all applications which is no longer representative. So, the risk exists that on level of AD groups there are conflicts which could lead to unexpected results.
  To mitigate this risk, it is better to split up general test accounts according to the applications that need to be tested.
• The test is performed with a (local) admin account
  In case of time pressure to setup an account in AD, test execution can be done with an administrator account. In AD, these accounts are often member of the overall admin group having access to all applications.
  Maybe, this seems a pragmatic and workable approach but here again there are some points of attention.
  Especially, the fact that a (local) admin on the Win7 workstation influences the expected behavior compared with the locked-down situation on the WinXP. The User Account Control (further: UAC) feature of Win7 is here an example. It aims to improve the security of Windows by limiting application software to standard user privileges until an administrator authorizes an increase or elevation. So unknown programs will be blocked from execution. Sometimes group policies –which normally come with the login script on your workstation- are not applied for (local) administrators. By consequence, it is possible that UAC is disabled for administrators.
  This option may result in drawing the wrong conclusions, therefore it is not representative. An intake or sanity test with the local admin account could do the trick since this can show whether the account is viable for continuing the tests.

Conclusion
Whatever the option is chosen, it is crystal clear that you have to take the account into account. The way test accounts are set up, can impact the outcome of the tests and effect the test results.  As the setup of accounts is time-consuming, this item must definitely be on your checklist during the preparation of a test environment.

How to test … a (reverse) proxy? (part 1)

In this post, we focus on testing the configuration (further: config) of (reverse) proxies.  Because a (reverse) proxy has several functions, this article will focus on three specific goals it can fulfill: as a security provider (1), as a network performance enhancer (2) and as a “de-personalization device” (3).

Just like testing a  firewall, first look into the design of the infrastructural landscape. Due to its great number of features consult a designer and/or architect to know the details of the configuration (e.g. the caching is enabled, encryption and SSL acceleration, load balancing capabilities, …).

This article is based on the case where the (reverse) proxy server operates as a web proxy.

(1) A forward proxy can provide security by blocking websites when internal users (so: from the internal company’s network) want to access these websites.  Therefore, it is imperative to know which websites are blacklisted in the proxy.  Testing this functionality can easily be done by surfing towards blacklisted sites.  In this case, the proxy can provide the end-user a message why the website is blocked.  When this error handling is in place, a tester should try to test each type of message.  For example http://www.playboy.com can be blocked due to the “Adult entertainment”; http://www.twitter.com and http://www.facebook.com can result in an “access denied due to social media” , ….

Click to enlarge

Pages: 1 2