Friday, December 26, 2014

Why we need security testing and how we can do it

When is security testing necessary? There are many instances where this is the case, but listed below are the basic ones. Security testing is necessary when:

    There is a corporate network or web application that was never checked for security issues (or was checked a REALLY long time ago).
  *  The system was successfully attacked or there was an attempt at attack.
  *  New functionality was implemented in a functioning product.
  *  Layout of corporate network underwent a significant change.
  *  The application was migrated from a test environment to a manufacturing environment.
  *  The company follows domain standards (PCI DSS, HIPAA).

There is actually a very simple way to define whether or not you need to perform security testing. If you have "something" and this "something" processes important data and can be accessed via the Internet, then security testing is essential. But what should be defined as important data? Everything that is valuable: user personal data, payment card information, company bills, invoices. Even if application doesn't store or process important information, possible reputation damage should not be underestimated; for example, you wouldn’t want someone to hack your website and change your logo to a competitor`s.

Once it is decided security testing should be performed, the type of testing used must be determined. If you are starting from scratch, you have a couple of options:

Option #1: Approach a software testing company, saying "I have a website/network and want to check its security." The downside to this option is that it can take testing specialists several days to define the need, which results in additional costs.

Option #2 (the one I recommend): Work out your security testing needs on your own, taking the following criteria into consideration:

    * Define testing goals.
    * Collect system data to provide analysts with necessary information.
    * System entry point (relevant only for testing local networks).

Defining Testing Goals
There are two types of security testing: penetration testing and vulnerability assessment.

The goal of penetration testing is to enter a web application internal infrastructure, cease control over the internal servers or access the important information. In doing this testing, specialists feign the actions of real hackers. However, the defects detected in the testing process and testing methodology isn't the main goal here. What is truly important is for the testers to determine whether the system, in its current state is accessible for hackers.

Penetration testing takes less time than vulnerability assessment and evaluates the efficiency of your security measures. If your primary goal is to discover whether it is possible to hack your system, penetration testing the best option.

Vulnerability assessment provides a more comprehensive system check. Its main goal is to identify system drawbacks and vulnerabilities that can lead to unauthorized access or unwanted public sharing of data. All the detected defects get qualified according to the level of risk and influence upon the general system security state. Usually, specialists do not exploit the detected vulnerabilities, but it can be done if both parties have agreed to it. Vulnerability assessment does take more time than penetration testing and is often held to comply with standard requirements.

Let's consider a specific case that shows the differences between penetration testing and vulnerability assessment.

Imagine that we have detected a bug: absence of HttpOnly security flag in cookie file with identifier of user session. Flag absence allows stealing of a user cookie, applying cross-site scripting method. In the context of vulnerability assessment this is definitely a defect and should be described in the final report. In using penetration testing, this case will be considered a defect only if it allow a tester to access the authorized user account; if not, the defect won`t be described in the final report.

Collecting Data

Next, you must determine what system data to provide to analysts. The provided data will define which testing method will be chosen. There are three options:

    * Black box testing – testers receive no system information except the list of IP addresses or the website link;
    * Grey box testing – testers receive valid accounts and limited system information;
    * White box testing – testers get full information about the system: accounts, network maps, technological specifications, web applications source code, etc.

As you can see, the "whiter" your "box", the more detailed information about system security you get at the end of the testing process, and the more important information the third party discovers – hence it is also more expensive and time-consuming.

System Entry Point
Finally, you must consider the system entry point. This criterion is valid only for performing penetration testing on a local network level. In this case there are two options:

    * External penetration test – only external company IP addresses accessible from the Internet are tested;
    * Internal penetration test – test is performed inside the corporate network. Testers work inside your team in the company office or work via VPN access.

Typically, the internal penetration test is performed to comply with requirements of domain standards or to check security level against inside attacks (i.e. those executed by company staff).

In combining the above security testing criteria, you should be able to define the best requirements methods for your company. For example, if you need a thorough check of your system, choose a combination of vulnerability assessment and white box penetration testing. If the budget is limited black box penetration testing may make the most sense.

No comments:

Post a Comment