Friday, June 1, 2012

Practical Security Infrastructure Testing

When building and deploying new security infrastructure, the moment eventually arrives where you have to connect your new system to the Internet.  This is the moment of truth, where you expose your carefully crafted infrastructure to hackers, crackers, phishers and script kiddies who are always to exploit someone else’ mistakes.

Before you get to this point, you want to have tested the security of you deployment very carefully, and this often gets overlooked in project planning.  Many a project has stalled because the business would not approve connecting an untested build to the Internet, and it was not possible to perform effective testing without having the infrastructure connected to the Internet.  Consideration should be given to security testing as early as possible in the design phase of the project: who will do the testing, and what sort of access and connectivity will they need?  How can that access and connectivity be provisioned without exposing the new deployment to the Internet at large?

TL Consulting (www.tlconsulting.com.au) recommends that the first phase of security testing be conducted in house, using static testing techniques to ensure that the design and configuration of the new infrastructure complies with the organisation’s security policy, and to establish a working baseline.  This work can be started very early in the project, and should ideally be commenced before the detailed design is signed off and before equipment is purchased.  Regular review phases will ensure that there is no unapproved “drift” from the baseline.

TL Consulting also recommends that the second phase of security infrastructure testing should be white box style internal testing, conducted from within the network where the new infrastructure resides.  In this phase the testers should be given access to the systems either as trusted users, or as attackers who have already breached the defences.  The goal in this phase is to uncover vulnerabilities that could be exploited, and to understand the extent of the damage that a successful attack could cause.

External testing should initially be mimicked using a harness to emulate access from the Internet.  This type of harness can often be provisioned using a low-end router to provide connectivity for the testers to the “outside” of the infrastructure.  Testing in this phase should include a mix of positive and negative testing, to ensure that traffic and transactions that should pass and succeed do so, and that all other traffic is blocked, and that appropriate logging is in place.

Formal penetration testing should always be performed by a third party.  A third party is more likely to spot deficiencies that the people who have worked on building the infrastructure.  If a third party is engaged to perform internal testing, that work should be completed and the results analysed – and any defects remediated – before external testing proceeds.  Both internal and external testing should be re-executed on a regular basis, in line with the organisation’s security policy.

Learn more about Test Data Management.

How to Use Web Testing Scorecard

Web testing scorecards will concentrate mainly on the GUI (Graphic user interface), GUI is used by websites to enable the users to browse easily within the pages of website. The website’s GUI functionality has great impact on the amount of traffic generated by a website.

GUI is created to provide effective control to the users on computers. In this case, control means the flexibility with which the Graphical User Interface reacts to the commands of users. Developing the website’s GUI quality will be the first thing that a web test scorecard will attempt to achieve. Logically the goal will be to give users the required graphic interface functionality by making use of the most appropriate web technology that is available.

The homepage will get the initial attention naturally, while testing a design of the website. The questions that you may ask here are: how the homepage is found by a visitor? Is easy navigation with the pages of website is allowed by the homepage menus? Does the design of the homepage and building inspire more visitors? Being biased, owner of a website or developer will tend to provide desired answers but there is a good and more precise way of measuring the functionality of homepage and that is, to ask the users about their opinion.

A web testing will decide the efficiency of GUI by measuring the flexibility and speed with which users browse from the homepage to other pages of website and back and to link with important links. A good GUI pattern will often give obviously located navigation points in every page and graphic buttons that give graphic recognition, which informs searchers they are still within the domain of a website.

The creation of the site should give straight forward links to embedded pages within the website. A well planned GUI will not fall short of links that will make the searchers to come back to the homepage, otherwise, they will be clenched in the page and will not have any opportunity to come to other pages of the site. Every page should have links to other sections and pages, which is even better.

Interface speed is another web testing that is good for measuring the functionality of website. Users are believed to give only 10 seconds of waiting time to enter websites before going somewhere else. This means, website interface should be assembled with access speed of majority users. Searchers on internet usually use dial-up connections. So it has to be aligned by considering that speed.  

Perspective - Investment in Performance Testing

Ideally in a real world Project or Testing Lifecycle, it is essential that Performance Testing is considered an Investment priority, this is valuable from a business and IT perspective. Preferably to ensure the Application, System or Environment under test is:

1. Fit for purpose – Meets agreed business SLA’s/Performance level requirements.

2. Responsive – Performance responsiveness is crucial under various user/load scenarios.

3. Scalable – Meets current and future capacity requirements to scale up or scale out.

4. Stable – Meets Performance level requirements under load.

5. Confidence – Business and IT Stakeholders need to be confident the system will perform to expected requirements and SLA’s.

Further to the above, another critical success factor in ascertaining whether you should invest in performance testing is evaluating your Return on Investment (ROI). Some of the elements that can provide justification for this include:

1. Application Tuning – Find and fix architectural defects and Performance Bottlenecks.

2. Environment/Infrastructure Tuning – Improved efficiency of existing hardware.

3. Capacity Planning – Identifying the size and scale for future capacity requirements.

All of the above principles and concepts are considered ‘best practice’ and are advised to be applied in a traditional Performance Testing Model. Clearly time and budget are constraints, but if the investment is available it is certainly worth the while to ensure stability and sustainability to IT Projects longer term. 

From our experience, there are a number of areas within a Performance Testing practice or function we can provide a significant value proposition, these include:

1. Senior Management Expertise – Strong Non-Functional Test Strategy & Management

2. NFT SME Capability – Providing resources that enhance delivery and provide subject matter expertise (SME) in Performance Testing and tooling.

3. Performance Engineering – Optimised approach towards Architectural test analysis, Performance tuning with a focus on customer experience.

4. Static Testing of Non Functional Requirements

5. Non-functional requirements analysis and traceability


Read more about Test Environment Management by visiting one of the best Australian based IT Professional company http://www.tlconsulting.com.au/