Comparing Two Penetration Testing Methodologies. Penetration Testing versus Vulnerability Assessment - Dissertation Example

? Comparing Two Penetration Testing Methodologies and Their Associated Tools By of Learning: Date: Comparing Two Penetration Testing Methodologies and Their Associated Tools Introduction Penetration Testing, which is commonly termed to as PenTest, refers to a process that is normally followed during the auditing or assessment of hardcore security. This methodology consists of a set of practices, rules, methods and procedures which are normally followed and later implemented in the process of auditing programs on any information security in an operating system environment. Penetration testing methodology explains the roadmap by defining the practical ideas and practices that have been proven and have to be applied with great care so as to ensure that the security system is assessed correctly. This penetration testing process can be conducted either independently or as an IT security part of risk management included in regular lifecycle development such as Microsoft SDLC. It is important to consider that a product’s security depends on both the IT environment related factors and the specific security practices. This includes appropriate security requirements implementation, risk analysis performance, modeling threat, reviews on code, and security measurements that are operational. PenTest is regarded as the final and the most aggressive means of security assessment practiced by professionals who are best qualified either without or with prior information on the system being examined. This process can be used in the assessment of all the infrastructure components of IT including network devices, applications, communication medium, operating systems, human psychology as well as physical security. The penetration testing output normally includes a report that is usually divided into sections that are filled with information on the weaknesses identified in system’s current state and the section is then followed by the appropriate counter measures and the possible recommendations. This means that penetration testing methodological process offers benefits that are extensive to the pentester ensuring a better understanding and enabling a critical analysis of the integrity of the existing defenses in every testing stage (McGraw, 1999, p. 45) Penetration Testing versus Vulnerability Assessment Since the start of the rapid growth of the IT security industry, there has been an increase in the intensive diversity numbers when it comes to understanding as well as practicing the most suitable security assessment processes and terminologies. That trend has not left out non-commercial organizations and companies who in most cases confuse or misinterpret the process and regard the process as contradicting specific security assessment types. Vulnerability assessment is regarded as the process through which both the external and the internal security controls are assessed through the identification of the threats that may result in serous exposure of the assets of a given organization. This infrastructure process technically evaluates the points indicating existing defenses risks and goes ahead to recommend as well as prioritize the possible strategies that can be applicable for remediation. A vulnerability assessment carried out internally offers a securing assurance for the internal systems while the assessment conducted externally demonstrates the perimeter defenses security. In both this testing, each network asset undergoes a rigorous testing that is normally against attack vectors that are multiple in an effort to identify threats that are unattended to and try to justify the reactive measures. Depending on the assessment type, unique sets of tools, processes and techniques used in the testing are followed in order to identify and detect information assets vulnerability in a fashion that is automated. This is easily accomplished through the use of a vulnerability management podium that is integrated enabling it to manage vulnerabilities database that is up to date and is in a position to take tests on different network devices types while at the same time keeping the management changes and configuration integrity. This is where penetration testing steps in as it does more than just the identification of hooks and vulnerabilities by including process of privilege escalation, exploitation, and keeping access to the system being targeted (Redmil, 2004, p. 7) Vulnerability assessment also offers a view of the existing flaws in abroad manner without taking into consideration the flaws impact on the system. Penetration testing stands out as being more intrusive compared to vulnerability assessment and the process is applied aggressively in all technical methods used in the exploitation of the production environment. Vulnerability assessment is preferred when it comes to the careful identification process and the quantification of vulnerabilities in a manner that is non-invasive. The scenario above paints the true picture of this industry’s perception with regards to both types of assessment. This may be confusing and can result in an overlap of processes and terms being interchanged. This is definitely not right. A consultant that is qualified normally considers working with the best assessment type required by the client and does not mislead them on the choice of the type of assessment. This puts the duty of examining the core details to the contracting party and expects the party to choose a program for security assessment before settling on a final decision. Types of penetrating Testing Although there exist several penetration testing types, the main approaches that are generally and widely used in the industry are the white-box and the black-box. Black-box Testing The black-box testing is at times referred to as external testing. When this approach is being applied, the auditor conducting the security operation assesses the infrastructure of the network under consideration from a location that has to be remote and has to take into consideration all the internal technologies under deployment by the organization. Through applying several techniques that are real hackers and by carefully observing test phases that are well organized, both unknown and known vulnerabilities tests may be easily revealed. The auditor has to classify and also understand the possible vulnerabilities with reference to their risks levels, that is; low, medium, and high. The identified risks can be generally measured in accordance to the threat they cause through the financial as well as vulnerability loss that may have taken place as a result of a successful penetration. A penetration tester that is ideal would most likely undermine any information possibility that may lead to the target being compromised. On completion of the test process, a report has to be generated including all the information that is necessary on the security assessment that is being targeted, identified risks translation and categorization into a business context (Graff and Wyk, 2003, p. 78) Techniques and Types of Black Box Testing The black box approach views a system as being a ‘black-box’ thus does not overtly make use of internal structure knowledge or codes. This means that the individual carrying out the testing does not have to be aware of the applications or the internal working of the system. Black-box testing mainly focuses on the system functionality as a whole. Behavioral testing forms part of the black-box approach though slightly different as it makes use of some of the internal code and knowledge though this move is normally discouraged. Both the black-box and white-box testing methods are associated with several disadvantages and advantages. It is evident that there exists some bugs that can only be applied by white box and not black box. Most of the applications make use of the black box approach. This takes place throughout the development of the software and its testing cycle. That means that the process involves; integration, unit, acceptance, system and stages of regression testing. Tools associated with black-box testing are mostly playback and record tools. Such tools are utilized in regression testing in an effort to determine any creation for new build in working application and functionality conducted previously. Such playback and record tools record cases on test in some scripts forms such as VB, TSL script, Perl and Java script. Black box testing makes use of several methods including error guessing, boundary value analysis and BVA techniques. In error guessing, the testing is based purely on previous judgment and experience. This means that the method is a form of art that depends on guessing in order to locate possible locations where errors may be hidden. This technique is simple thus does not make use of specific tools. It involves having the test cases written down which covers all the paths in application. Boundary value analysis method mostly concentrates on failures on the boundaries. This is because most systems often experience failures on their boundaries. This renders this approach relevant in many applications. The boundary value analysis is a technique used in functional test applied in the testing of boundary values that are extreme. These boundary values include; minimum, maximum, within the boundaries, error values, and typical values. This type of testing is most efficient in cases where the values being used in the boundary testing vary with the fixed values. Another black-testing method is the equivalence partitioning approach which divides the domain inputs of any given program into data classes where the tests cases can be easily derived. The comparison black-box testing involves having different software versions that are independently used in the comparison to the rest of the testing (Hetzel, 1998, p. 45) White-box Testing The white-box testing approach is also commonly referred to as internal testing. The individual conduction this type of penetration testing has to be vast with all the underlying and internal technologies utilized by the environment being targeted. This approach has been appreciated as to be bringing additional value in an organization in comparison with the black-box testing approach. This follows its ability to eliminate all the internal issues on security found at the infrastructure environment being targeted by the process hence making the environment tightened and inaccessible by any malicious adversary infiltrating from outside. The steps involved in the process of white-box testing are somehow similar to that used in black-box testing. However, the process in white-box testing excludes some of the process used in black-box approach like information gathering, target scoping and phases identification. More so, the white-box testing process is easily integrated into lifecycle developments that are regular so as to do away with any arising security issues in its early stages before being exploited and disclosed by external intruders. The cost required and time used in the identification of security vulnerabilities is less compared to those used in black-box testing. The two penetration testing approaches can be combined to come up with an insight that is more powerful in both external and internal security view points. Such a combination is referred to as the grey-box testing. The main aim of using gray-box testing is to achieve the advantages of both the approaches in one testing. However, this combination expects the specialist carrying out the process and has less knowledge about the internal system to settle on the most suitable ways of assessing the overall security situation. The external testing process being used by the gray-box testing is comparable to that of the black box but results in better choices when it comes to tests and decisions making as the specialists are aware and well informed about the technology underlying the process (Kaner and Hung, 1999, p. 56) Associated Tools Some of the tools that are closely associated with white-box testing include source code analysis, program understanding tools, profiling, instrumentation and coverage analysis. The process of source code analysis involves source code checking for any problems in coding that are based on a set of patterns that are fixed or rules indicating security vulnerabilities possibility. Tools used in static analysis operate in such away that they scan the codes from the source thus detecting errors automatically. The errors normally go through compilers hence become problems that are latent. The static analysis strength relies on the patterns of the fixed sets or the rules utilized by the tools in question. This means that in most cases, such static analysis fails to locate all the issues concerning security. The output of this tool still depends on human evaluation. In the case of white box testing, the source code results offer important insight into the situation of the security concerns and assist in the development of the test case. The process of white box testing is expected to verify that the uncovered potential vulnerabilities by static analysis tool do not in any way result in security violations. Some of the static tools offer control-flow and data-flow support analysis that are important during the development of test case. Generally, testers used in white box approach are required to access the same documentation, tools and environment as the functional as well as the developer’s testers. More so, tools that are used to assist in understanding the programs used like code navigation, software visualization, disassembly and debugging tools, enhance productivity greatly in the testing process. In coverage analysis, the tools used for code coverage take measurements on the thoroughness of programs on tests exercise. This includes several coverage measures such as branch coverage, statement coverage, and multiple-condition coverage. The coverage tools are used to modify the codes so as to enable the recording of executed statements. The modification process occurs either to the executable generated by the compiler or to the source code. There exists different freeware and commercial coverage tools that are readily available. The selection of the coverage tool to be used has to be based on coverage measurement type that has been selected, the source code language, the program size and the integration easiness into the building process. Profiling tools enable the users to understand where and how the software being tested spends a lot of time and the calls function sequence. Such information indicates the software pieces that are slower and those that are over utilized. Looking from the perspective of security testing, the performance knowledge assists in the uncovering of the vulnerable areas which happen not to be apparent in the static analysis process. The call graph produced using the profiling tool is important in the understanding of programs. Some types of profiling tools are able to detect leaks or access errors in memory. The two are possible security violation sources. Generally, either the team for functional testing or that of development should readily access the tools used in profiling. The individuals carrying out the testing should also make use of similar tools in order to understand the behavior dynamics of the software being tested. Instrumentation process involves the addition of codes to the blocks being applied. The added codes generate events which can be easily logged in several event sinks. Such events can be utilized in the capturing of specific matrix applications, code tracing, and profiling (Marciniak, 1994, p. 82) Comparison between White-box and Black-box Testing There is no single type of testing that can offer information enough to quantify a systems quality. This means that multiple testing types have to be undertaken in order to completely determine the quality of the software in application. White-box and black-box testing are a representation of a wide category of such test types. Neither of the two can separately be used to accurately show a system’s quality. The box used while referring to either white or black box represents the system being tested while the color, either white or black refers to the visibility which the tester has to pass through during the systems inner workings. In the testing of black box, the tester lacks visibility into the systems inner workings. In such a case, the tester views the interfaces that are only exposed by the system. Contrary, when it comes to penetration testing using the white box, the tester is provided with complete visibility into the way the workings of the system. This can be demonstrated using a vending machine; while the black box will entail inserting coins into the vending machine and its verification being the desired product coming out and the correct change given out, the testing involving white box on the other hand will include the process of opening the panel at the back of the machine and triggering manually the switch responsible for dropping the desired product. Black box penetration testing, commonly referred to as behavioral or functional testing, provides several benefits. The benefits include; testing using black box validates whether the system under testing conforms to the specifications of its software. During implementation, penetration testing using black box brings forth a number of inputs into a system and goes ahead to make a comparison between the outputs to a test specification that is pre-defined. Black box testing examines the individual components of a system and goes ahead to draw integrations between these components. Such tests by black box are independent of architecture as they do not in any way concern themselves with the process by which the output are produced but with the output in question if it will produce an output that is expected and one that is desired. Now that black box penetration testing does not require any knowledge about the system being tested, the testing process does not require a software engineer to come up with tests (Marick, 1994, p. 102) White box penetration testing, at times called structural testing involves the system’s individual components thus calls for the need of implicit knowledge about the inner workings of the system being testing. During implementation process, white box penetration testing comes up with a particular input set to the system’s individual functions and goes ahead to make comparisons with the outputs of the results being expected during the testing. Testing during white box penetration is not normally done using user interface but instead makes use of debugging features of the particular environment being developed. Black box penetration testing is normally conducted by analysts from QA who remain concerned with the experience of the end-user predictability. The job of such analysts is to ensure that the applications are to the requirements and expectations of the customers and the system being tested performs what it has been designed to do. One of the main concerns about black box penetration testing is that it does not guarantee the testing of all the code lines. Following this, the black box is architecture independent; its testing process does not determine the code’s efficiency. Moreover, testing using black box does not locate errors like memory leaks, and errors that are not openly and promptly exposed by the tested applications. Contrary to this, white box penetration testing in any infinite time, allows the testing of all code clues and lines now that the relative efficiency of the codes can be easily ascertained. White box is therefore performed by developers who happen to be more expensive compared to QA analysts. White box penetration testing has however proved to be insufficient, despite this, in situations where components being tested have been isolated, such components may not necessarily show integration errors in relation to other components. Associated Tools Rational Software has been the major producer for both automated white box and black box penetration testing for many years. Regression testing tools produced by Rational functional are used to capture black box test results and present the results in a script format. Once the results have been captured, the scripts are in a position to be executed on future buildings of any given application so as to verify that the produced functionality can in no way disabled the earlier functionality. In addition, Rational provides white box penetration testing tools which are applicable in detecting memory leak and errors that are run-time. The tools also record the specific time taken by the application while testing a given code blocks in an effort to identify code bottlenecks that are inefficient. The tools point out the application areas which have already been executed as well as those yet to be executed. The availability of these tools for a long time has ensured that the tools used in black box testing existed exclusively on the analysts machines of the QA while the tools used for white box testing have for a long time been purchased mainly by developers. The above trend is mainly because QA analysts have in the past lacked a debugging and coding working environment. Even if such working environments were provided to the analysts, most of them would not be in a position to understand the output information of such tools. Rational has it that there exists an artificial barrier and the work of QA can be made better through the use of white box penetrating tools which do not need access to a development environment or source codes. Following this situation, Rational makes use of Object Code Insertion (OCI) technology that is patent to enable executable files applications. This process does not require any source coding and also ensures that Purify Quantity, Rational tools and PureCoverage carry out white box penetration testing on controls as well as codes that happen to be third parties as the source code may not be readily available in some cases. Once the Rational Test Studio was introduced, the process of testing using white box was integrated together with black box penetration testing. Since this innovation, QA analysts become able to carry out white box testing just the way they did with the black box (Viega and McGraw, 2002, p. 92) The OCI technology used by Rational eliminated the need to have source code or a development working environment. This allowed the QA analysts to gain visibility inside the black box. While the QA analysts go on with the process of running the tests on the functionality of the black box, other tests can also take place in the white box including code bottlenecks, memory leaks and code coverage measurements. The Rational advancements tools have enabled technological marriage between the black box and white box roles when it comes to testing. This has enabled the testing professionals to share both their information base and detection tools in a more accurate and quick way thus ascertaining the quality of a given software application using either black box testing, white box testing or both applications. Tester’s performances that have been traditionally linked to black box testing can be used to leverage similar scripts so as to obtain information from the testing results that was normally considered as being available only to the testers used in white box. This move has helped the QA analysts to have the chance to have the load light enough for the development team using minimum expense. Any software can have all the codes tested in the event that it is provided with all the time in the world. The problem is that there exists no software team that has such a time to carry out the testing. This can however be achieved by having white box penetration testing reduced to locating crashes in the applications and memory leaks through the base of the codes. By doing this, the time required to conduct white box testing can be easily managed. Through having a common set of tools on the desktops of the QA analysts and developers, Rational has been able to bring the testing of white box and black box closer together as well as having the QA analysts and the developers work closer together. Such a unified team is better placed to achieve greater benefits. Differences between White box and Black box Testing The outstanding difference in the testing processes involving white box and black box is seen in their respective areas of focus. Black box penetration testing has its focus mainly on results in that any action that produces desired results renders the actual process leading to such results as being irrelevant. White box penetration testing has its focus on the details leading to the results. The process concerns itself with the system’s internal workings and does not stop until all the avenues involved in the process get tested and all the application parts have been proved to have taken part in the entire testing process to its completion. Black box penetration has several advantages over white box penetration testing including; black box has been known for its easiness when used in any testing process now that its testers don’t need to involve themselves with the application’s inner workings. This makes it easier to come up with test cases through just operating the given application, the same way it could be done by an end user. Black box testing is also quicker in its development of test cases as its testers concentrate mostly with the application’s GUI thus don’t use much time in the identification of the entire internal paths followed through in a given process. These testers have to involve themselves only with the specific paths taken by the GUI that the user needs. Black box are simple compared to white box despite the highly and large systems or applications that are complex, the black box provides a simple means of testing that focuses on both the inputs that are valid and those that are invalid so as to make sure that the user receives the right outputs. Despite the several advantages associated with black box testing, the black box testing system has led to a number of setbacks leading to most users to question how viable the approach used by black box is. Some of the drawbacks witnessed while using black box approach include the difficulties experienced during the maintenance of scripts. While the testing approach that makes use of images remains useful in this process, the constantly changing user interface during the process may lead to the input also to change. This makes the maintenance of the script very difficult now that the tools used in black box testing depend on the input method that is known. Black-box testing is also fragile when it comes to GUI interaction. Such an interaction results to the test scripts being fragile. This follows the fact that the GUI used in black box penetrating testing cannot be consistently rendered on different machines or applications from time to time. This can only happen if the application tool is in a position to accommodate the different rendering of the GUI. In such a situation, it is most likely that the scripts used for testing will not be able to properly execute on a basis that is consistent. In addition to the above, black box testing lacks introspection; this follows its inability to have access inside a system or application thus cannot completely examine the system or the application (McGraw and Potter, 2004, p. 83) White box penetration testing has also several advantages to its name. They include; the ability to access the inside of a system or application giving it an introspection advantage. This allows the tester to programmatically identify objects. This is crucial in the process of changing frequency witnessed in the GUI as it permits testing to continue. In some cases, the tester has been seen to reduce the tests scripts fragility on condition that the objects name remains unchanged. White box testing is also stable in its approach. Serving as introspection by product, white box penetration testing has proved to offer better stability compared to black box testing and allows the test cases to be reused in case the object making up the application remains unchanged. White box testing is believed to be more thorough when it comes to events where it is important that all the paths taken during the process of testing have to be thoroughly examined so that any possible interaction coming from inside the application has been examined. This makes white box penetration testing the most viable approach is such a situation. In such case, this testing process provides the testers the capability to be thorough in relation to the extent at which they can test a given application. Despite the above mentioned benefits, white box testing is also associated with several disadvantages. The drawbacks include; complexity in its approach as its ability to access every part constituting an application implies that the tester has to be equipped with programmatic knowledge on the application being tested in order to work properly with it. Such a level of complexity needs an individual who is highly skilled to be able to properly develop the test case. White box testing is also fragile with reference to the introspection process it is expected to overcome the tests script’s breaking issue as the object’s names during the process of developing the product or the new addition paths taken by the application. White box testing process needs its test scripts to be tightly tied to the code underlying an application. This implies that any changes made to the codes will in most cases result in the breaking of the test scripts. This calls for high maintenance degree on the scripts during the testing process. The other drawback is normally witnessed in the integration process now that the testing process is expected to achieve a certain degree level of introspection, the approach has to be integrated tightly together with the application under test. This leads to a number of issues including; for the codes to be tightly integrated, they have to install tools related to white box approach on the system running the application. During such as a process, the elimination of the testing tool normally poses a major problem in its operation or performance (EC-Council, 2010, p. 78) Bibliography Beizer, B., 1999. Software Testing Technique. Nostrand Reinhold: New York EC-Council, 2010. Penetration testing: Procedures & Methodologies. Course Technology: New York Graff, M & Wyk, K., 2003. Secure Coding: Principles and Practices. O’Reilly: California Hetzel, W., 1998. The Complete Guide to Software Testing. Information Science: Wellesley Kaner, C & Hung, N., 1999. Testing Computer Software. John Wiley & Sons: New York Marciniak, J., 1994. Encyclopedia of Software Engineering. John Wiley & Sons: New York Marick, B., 1994. The Craft of Software Testing. Prentice Hall: New Jersey. McGraw, G & Potter, B., 2004. “ Software Security Testing.” IEEE Security and Privacy, Vol. 2: 81-85 Redmil, F., 2004. “Exploring Risk-Based Testing and Its Implications.” Software Testing, Verification and Reliability, Vol. 14:3-15 Viega, J & McGraw, G., 2002. Building Secure Software. Addison Wesley: Boston Read More