How to Avoid an Attack - Security Testing as Part of Your Software Testing Process Recent events in the field of information security, which have been publicized extensively in the media - such as the Saudi Hacker, Sony s servers being shut down or alternatively, the establishment of the biometric database, raise questions among the general public as to how information should be protected. And so, another burden has been placed on the narrow shoulders of today s Quality Assurance teams Information Security. This isn t about the securing of information for development companies, a task usually assigned to IT specialists, but rather insuring that the product or services that we re responsible for will be protected from security vulnerabilities. So what are security vulnerabilities? Perhaps one of the best ways to explain security vulnerabilities is to hack into a website, by demonstrating a common technique called SQL Injection. So first let s make ourselves a website This of course is a very basic website, in which we have only one text input field and one button. Clicking the button will check whether the name of the book in the text field appears in the database and if it does it will print out the author s name. Incorrect writing of the code in a website such as this will allow a novice hacker to have access to our entire database, and even shut down the site as well as the physical machine. How does he do it? Let s enter an apostrophe ( ) into the text field and click the button. This will result in an error page:
Why? Because this website is written poorly and using an apostrophe breaks the query with which the database is accessed. A number of trial and error attempts will lead the hacker to the following string: union select password from users;--, which he will then attempt to use in the website: And there you have it the users passwords are now exposed. This of course is only one vulnerability out of the many vulnerabilities that are out there. Motivation Whether it s because of regulations or because of demands made by sensitive customers, the request for a secure product will usually come from the outside. Information that leaks from our products or from using the product in order to penetrate a client s servers, can cause immeasurable damage to a company. Therefore, companies are required to deliver a product that s not only high quality (efficient and simple to use), but also secure. Usually, we ll be required to adhere to certain standards (for example PCI or OWASP Top 10), as well as industry standards. In a world that s moving toward the Cloud and Web Interfaces, this emphasis becomes even sharper, yet even more traditional software is still prone to attack and requires protection.
Why a testing team (or QA team)? In most software companies, the Security Information team, if it exists at all, isn t a large team. Traditionally, the responsibility of security used to fall on the head engineer or on one of the heads of the development team. These teams, aside from general management, weren t able to deal with specifics. In attempts to transfer the responsibility to developers, it s often found that a great deal of supervision over their work is required. A testing team, on the other hand, can be trained precisely for this purpose. Also, attempting to transfer the responsibility to developers isn t really feasible, as even the most talented developers simply cannot be up to date on the hundreds of vulnerabilities that could exist in the code, and it takes only one developer - and one mistake - to jeopardize everything. So what can be done - in a practical sense? 1. Security as a Requirement At first, we would define the requirement to produce a secure product as an integral part of the overall product requirements. The immediate result is simple: vulnerability = bug! And bugs are exactly what the testing team is there to find. 2. Training From my experience, testing teams today aren t all familiar with the topic of security and it s advisable to start the process with a short training session. A prolonged and expensive training process will usually result in profusion and boredom. I recommend a lecture or two that focus on common vulnerabilities (SQL Injection, XXS) using tools, and then independent study thereafter. 3. How do you find them? The existing testing team, as professional as it may be, probably doesn t specialize in security, and may need help if it isn t using the right tools. Just like any bug, there a variety of ways to identify security vulnerabilities. I m happy to say that today there are a number of tools on the market that can assist with this task. Remember everything revolves around using the correct process, and just like any process, there s a need to define appropriate stages and tools. The daily routine of a security tester then becomes simple and structured: 1. Arriving in the morning, and checking the results of the tool s nightly run. 2. Are there new problems? If there are, reading more about them in the tool s attached documentation or even online.
3. If the tester has access to the code, can he check if the problem is real/relevant? In other words, does the software s finding really represent a vulnerability? 4. Opening a bug report in the Bug Management System. Solutions There are several different approaches when it comes to the recommended types of testing. The common solutions on the market today are divided into three groups: Static Code Analysis These tools scan the project s source code and identify potential vulnerabilities within the code. Automatic Penetration Testing These tools attack the application using a variety of techniques and try to identify vulnerabilities. Code Review This involves inviting an external company to carry out a manual inspection of the code. Static Code Analysis Penetration Testing Code Review Preparations No need for special preparations Many preparations are required and a full running environment No need for special preparations Coverage Limitations There are paths that exist only during the running period There are vulnerabilities that are impossible to find during the scan Very limited amount of weak spots due to the amount of work required The chance of missing vulnerabilities during a scan Very small Partial all existing values simply cannot be tested Large it s impossible to manually cover 100% of large-scale software False reports Very few Almost never Almost never Double routes None Many are possible None Process Automatic Automatic Manual Identification of problems in the code The tool will direct the developer to the precise place in the code Complex, and security knowledge is required Complex, and security knowledge is required Lifecycle integration Fully integrated throughout the process Only at the end of the process Only at the end of the process
Ability to test dedicated processes Requires preparation None Completely able Availability Immediate Immediate (following preparation) Requires coordination of external team Price one time testing Relatively expensive Relatively expensive Single testing is less expensive Price regular, continuous testing Inexpensive Inexpensive Very expensive Lifecycle Integrating security testing into the product s lifecycle is worthwhile for the same reasons it would be for any other test - the early identification of problems is more economical that finding them at a later stage. In different companies and in different processes there could be a need for some adaptation, but the basis that I recommend is divided into three parts: Planning Even at the beginning of the planning stage for the product or component, security must be addressed (until the testing team becomes familiar with the topic). The security specialist or head engineer will emphasize the main pointers. The Development Routine At this stage, I recommend integrating an automatic tool to carry out the security testing (static code analysis). This type of tool will be able to identify the security vulnerabilities and direct an unskilled team toward the problems. o o o Running the scan automatically after the nightly build will ensure the early identification of problems and that they re well monitored once corrected. The team will review the scan results, study the results and develop bug reports and along the way learn about the different vulnerability levels. It s recommended to select a tool that s easy to understand and operate, and one which does not require compiling. Before Release
At this stage, I recommend that new teams order an external Code Scan (Penetration Test). If the team has done a good job, the external company will only have to approve that the product is safe, so it won t cause a delay in release. Tool Selection Selecting the right tool is very important, as we re relying on the tool to also bridge the team s information gap. There are a number of points to look out for when choosing a tool: Simple integration as with any new tool, endless and complex tool requirements will lead to frustration and early abandonment. Does the tool require compiling? How hard is it to carry out adaptations? Structured results ask your salesperson to show you a sample report. What are the ways in which the tool presents the results? Are the results understandable to you? Do they provide enough information? Suitability to technologies go into detail in regard to the suitability - does the tool support the relevant development language? Does the tool support the framework used? Are the databases supported? Development environment does the tool integrate with the company s development environments? Does it integrate with the code management tool (SVN, TFS), and with the programmer s tools (Eclipse, Visual Studio)? When working with Waterfall, the emphasis should be on receiving a low amount of false results. With certain scanning tools, scanning a large project may return thousands of false results. Usually with Waterfall there s no time to extend the testing period enough to study all the results. When working with Agile, the emphasis should be on ease of work. Not all testers will be immediately skilled, and when it comes to Agile, the independence of the tester is vital. Support the tool s manufacturer is usually a good source for information and training. Does the transaction include a joint review of the results, and further guidance if necessary? Summary Using simple tools, an unskilled team can obtain good results, as well as produce and maintain a secure product. A short phone call to one of the tool manufacturers or consultation firms will open up a world of new capabilities.