It requires a great deal of efforts to harness a good level of security. To obtain good security statistics one has to follow a proper approach to the testing. Like for any other kind of software testing one need to decide for security system also that who will carry out the testing and what approach has to be followed. Carrying out the security testing at the white box level is not at all easy as it is very complex and detailed.
APPROACHES FOR SECURITY TESTING AT WHITE BOX LEVEL
Basically till now two basic approaches have been identified for the security testing at the white box level and these have been mentioned below:
1. Functional Security Testing
- This approach to testing is usually followed by the standard testing organizations. - It deals with the checking of the features and functionalities of the software system or application for determining that whether or not they are working as stated. - This sounds like a very classic approach to security testing.
2. Risk Based Security Testing
- This is a more traditional approach to security testing and is followed usually by the quality assurance staff.
- This approach is quite difficult as compared to the previous mentioned approach.
- The main problem here is of the expertise of the testers since this approach calls for great skills in testing.
- Firstly to design the security tests which can completely exploit the vulnerabilities are difficult to be designed since for this it is required that the tester thinks like an attacker.
- Secondly, the security tests do not exploit the security of the software system or application directly and this causes a problem to observe the outcomes of a security test.
ABOUT SECURITY TESTING AT WHITE BOX TESTING LEVEL
1. A security test carried out without much precaution and logic can cause the whole security testing go wrong and this in turn can lead the software tester to carry out even more complicated test processes to counteract such a situation.
2. Risk based testing requires more skills than experience.
3. Most of the security testing methodologies or techniques that we use at the white box level are traditional and some of them have become out dated.
4. On the other hand the security exploitation techniques used by the attackers have become sophisticated day by day and the traditional methods used to cope these issues are becoming extinct.
5. Security testing at both the black box level and white box level tend to have a better understanding of the software system or application but different approaches are followed at both the levels.
6. The different approach followed by them is decided on the basis of the access of the source code i.e., whether or not the tester is having access to source code.
7. Security testing at the white box level is concerned with the rigorous analyzation of the source code of the software program as well its design.
8. It basically deals with finding the errors in the security mechanism of the software system.
9. In very rare cases it happens that this approach involves the matching of the patterns and automation of the whole testing process by implementing a static analyzer.
10. One peculiar drawback has been discovered for this kind of testing which is that this kind of testing sometimes may report a bug in some part of the software but actually there exists no such bug.
11. But still security testing at white box level using static analysis methods and techniques proves good for some software systems and applications.
12. Risk based testing calls for a lot of understanding of the whole software system.
13. After all, the product security is very much essential to the reputation of the company.
Tuesday, March 6, 2012
What are different methods and techniques used for security testing at white box level?
Posted by
Sunflower
at
3/06/2012 10:00:00 AM
0
comments
Labels: Application, Approach, Bugs, Defects, Errors, Functional, Levels, Logical, Risk based testing, Security, Security Testing, Software Systems, Software testing, Techniques, Tests, White box testing
![]() | Subscribe by Email |
|
Tuesday, September 14, 2010
Risk Based Testing and the strategy behind risk based testing
Risk analysis is applicable on the level of system, subsystem and individual function or module. Testing is used in software development to reduce risks associated with a system. Risk-based testing (RBT) is a type of software testing that prioritizes the features and functions to be tested based on the risk they represent.
Risk-based testing is a skill. It’s not easy to know the ways that a product might fail, determine how important the failures would be if they occurred, and then develop and execute tests to discover whether the product indeed fails in those ways.
The main input into risk based testing is the business requirements supplied by the customer of a software application or system which outlines all of the features which must be present and explain how they should work, how each process should function and what the software should do.
Test managers prioritize tests to fit in with the project’s schedule and the test resources available.A risk based approach to testing takes a much deeper look at the real underlying needs of the project and what really matters to the end-customer.
Risk based testing is about carefully analysing each requirement and each test to ensure that the most important areas of the system and at the same time, those areas which are more likely to experience a failure receive the most attention from the test team. When risk based testing is deployed, every requirement must be rated for likelihood of failure and the impact of failure.
By analyzing the risk of a failure occuring with a specific component or feature and also the impact of failure if that component or feature failed in a real-life situation, project resources can be more efficiently allocated to focus on testing what really matters in the limited time available.
A risk based testing (RBT) approach can help save time and reduce costs on your testing project. Risk based testing enables the test manager to make an informed choice when allocating test resources on a project.
Posted by
Sunflower
at
9/14/2010 05:32:00 PM
1 comments
Labels: Approach, Development, Failure, Impact, Process, Product, Quality, RBT, Risk Analysis, Risk based testing, Risks, Software, Test Strategy, Tests
![]() | Subscribe by Email |
|