Security Testing – How We Do It

Securing your software against external threats is always a tricky proposition. If your software is accessible outside your environment, it immediately becomes a vulnerable candidate for attacks from unethical entities hungry for stealing confidential information that can leave you embarrassed, or even worse – facing multi-million dollar lawsuits. Due to this, many of the software clients mandate their software vendors to be security compliant (like OWASP Top 10, HIPAA, etc.)

Organizations across the globe are hosting their mission critical services over the internet with a lot of sensitive data being exchanged across systems and users. The security of web applications is thus becoming increasingly important at the application, server and database levels.

Your software can be a small web application or a mammoth architecture involving Web, Desktop and Mobile interfaces. Lets start by understanding how to go about with the Security Testing process.

System Architecture

First Step is to understand your system architecture – The basic building block of the software. Here, you need to understand which components are involved (middleware, software, clients, etc.) and how the different components of the system talk to each other (protocols, ports, etc.). It is always a good idea to draw this system architecture, the components & protocols, and keep it handy since you may need to refer to it time-and-again during Security Testing.

Security Testing Requirement Document

Next, you need to chalk out a document detailing the requirements of the Security Testing exercise. It should contain the goals and objectives and any compliance/certifications needed. You will have to strategize your testing based on the compliance/certification required. It should also contain all the algorithms to be used for every protocol in case encrypted requests are being sent.

Analyse System Boundaries

A person/system trying to compromise the security of your software will, in all probability use the existing interfaces to infiltrate and hack the system. You need to make sure that you have identified these boundaries and the protocols used to access the system and have marked them in the above architecture diagram. This will give you a fair idea on how vulnerable your software can be to an attack.

Analyse System Access Policies

Security threats to a software system are more from the actual users of the system than external hackers. Hence, you need to analyse your system access rules, password policies, user-role relations, etc. to make sure that there are no loopholes.

Test Environment

The test environment being used for executing these tests plays a very important role. The test environment should be as close to production as possible. The OS, servers, runtime environments (like Java, .NET), etc. should be exactly similar (right down to the version number) to that of production. You don’t want to be caught in a situation where you run the tests on a Java 1.7 system, only to realise later that the production server runs Java 1.6. This will make all your testing effort null and void since libraries may behave differently under different runtime environments.

Threat Modelling & Attack Vectors

Armed with the above information. You should now go ahead and do the actual Threat Modelling. In threat modelling, you analyse exactly which attack vectors can be used to hack your software. An attack vector is nothing but the strategy that an attacker can use to exploit a vulnerability. You can also use popular techniques like STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privileges) for threat modelling analysis. Armed with this information you should create test scenarios and use cases for each vector.

(You can refer to this link for more information on STRIDE and other modelling technique)

Impact/Risk Analysis

Based on the threat modelling done, you should carry-out impact or risk analysis of the threats to find out which areas of your software or what data are vulnerable to attack and what are the risks associated with such attacks. This will help you in prioritizing your test scenarios and understanding which area of your software needs more attention from the security perspective. A very popular model to analyse threats is DREAD (Damage, Reproducibility, Exploitation, Affected Users, Discoverability). This will help you in analysing the risks and impacts of a particular threat.

(Refer to this link for more information on DREAD)

Security Test Planning

Next, draw up a security test plan. This should include all of the above analysis and also details on how and when you plan to test the identified vulnerabilities. It should also contain your security testing requirements and any compliance or certification that needs to be adhered to. Typically, it also contains a summary of the Threats, Attack Vectors (approach) and test conditions. Also, put in the tools that are going to be used for testing each vector. The environment on which the security testing is going to be done should also be mentioned.

Test Cases

The test planning and threat modelling should be translated into actual test cases and test data that would be executed during the execution cycle. Prioritize the test cases based on Impact analysis done for each threat.

Penetration Testing

Execute the above test cases on the prepared environment and log your defects or observations in your bug tracking system. Usage of enabling tools like Fiddler, Web Scarab, Firefox add-ons, etc. is highly recommended. If you are using a tool to execute the tests, make sure that it is executing all the identified scenarios and threats.

Tools

Penetration and security testing ROI can be best achieved using specialized automated security testing tools. These tools help in identifying vulnerabilities

Bug Fixing

The software will now follow the regular software lifecycle. The reported bugs will be fixed by the developers and will provide a new build. These fixes will be re-tested and security regression tests carried out. Ideally, functional regression tests should also be done to rule out any functionality breaks. In rare scenarios, a system architecture change may be required to fix a certain bug. In which case, you will have to modify your approach and carry out the analysis all over again to make sure that this change does not affect other components.

Reporting/Compliance/Certification

Finally, once all the bugs have been ironed out and test pass carried out successfully, you will need to prepare the report on compliance or certification as required.

This completes the security testing cycle.

Tools

– Fiddler

– Burp Proxy

– IBM AppScan

– SQL Map

– Web Scarab

– Firefox Addons – XSS Me, SQL Inject Me