“White Box” Techniques for security testing

White box” tests and analyses, by contrast with “black box” tests and analyses, are performed on the source code. Specific types of white box analyses and tests include:

Static Analysis

It is known as “code review,” static analysis analyses source code before it is compiled, to detect coding errors, insecure coding constructs, and other indicators of security vulnerabilities or weaknesses that are detectable at the source code level. Static analyses can be manual or automated. In a manual analysis, the reviewer inspects the source code without the assistance of tools.

In an automated analysis, a tool (or tools) is used to scan the code to locate specific “problem” patterns (text strings) defined to it by the analyst via programming or configuration, which the tool then highlights or flags. This enables the reviewer to narrow the focus of his/her manual code inspection to those areas of the code in which the patterns highlighted or flagged in the scanner’s output appear.

Direct Code Analysis

Direct code analysis extends the static analysis by using tools that focus not on finding individual errors but on verifying the code’s overall conformance to a set of predefined properties, which can include security properties such as noninterference and separability, persistent_BNDC, noninference, forward-correct ability, and nondeductibility of outputs.

Property-Based Testing

The purpose of property-based testing is to establish formal validation results through testing. To validate that a program satisfies a property, the property must hold whenever the program is executed. Property-based testing assumes that the specified property captures everything of interest in the program and assumes that the completeness of testing can be measured structurally in terms of source code. The testing only validates the specified property, using the property’s specification to guide dynamic analysis of the program. Information derived from the specification determines which points in the program need to be tested and whether each test execution is correct. A metric known as Iterative Contexts Coverage uses these test execution points to determine when testing is complete. Checking the correctness of each execution together with a description of all the relevant executions results in the validation of the program with respect to the property being tested, thus validating that the final product is free of any flaws specific to that property.

Source Code Fault Injection

A form of dynamic analysis in, which the source code is “instrumented” by inserting changes, then compiling and executing the instrumented code to observe the changes in state and behavior, which emerge when the instrumented portions of code are executed. In this way, the tester can determine and even quantify how the software reacts when it is forced into anomalous states, such as those triggered by intentional faults. This technique has proved particularly useful for detecting the incorrect use of pointers and arrays, and the presence of dangerous calls and race conditions. Fault injection is a complex testing process and thus tends to be limited to code that requires very high assurance.

Fault Propagation Analysis

This involves two techniques for fault injection of source code: extended propagation analysis and interface propagation analysis. The objective is not only to observe individual state changes that result from a given fault but to trace how those state changes propagate throughout a fault tree that has been generated from the program’s source code. Extended propagation analysis entails injecting a fault into the fault tree and then tracing how the fault propagates through the tree. The tester then extrapolates outward to predict the impact a particular fault may have on the behavior of the software module or component, and ultimately the system, as a whole. In interface propagation analysis, the tester perturbs the states that propagate via the interfaces between the module or component and its environment. To do this, the tester injects anomalies into the data feeds between the two levels of components and then watches to see how the resulting faults propagate and whether any new anomalies result. Interface propagation analysis enables the tester to determine how a failure in one component may affect its neighboring components.

Pedigree Analysis

While not a security testing technique in itself, the detection of pedigree indicators in open source code can be helpful in drawing attention to the presence of components that have known vulnerabilities, pinpointing them as high-risk targets in need of additional testing. This is a fairly new area of code analysis that was sparked by concerns regarding open source licensing and intellectual property violations.

Dynamic Analysis of Source Code

Dynamic analysis involves both the source code and the binary executable generated from the source code. The compiled executable is run and “fed” a set of sample inputs while the reviewer monitors and analyzes the data (variables) the program produces as a result. With this better understanding of how the program behaves, the analyst can use a binary-to-source map to trace the location in the source code that corresponds to each point of execution in the running program, and more effectively locate faults, failures, and vulnerabilities. In The Concept of Dynamic Analysis:

  1. Coverage concept analysis
  2. Frequency spectrum analysis.

Coverage concept analysis attempts to produce “dynamic control flow invariants” for a set of executions, which can be compared with statically derived invariants in order to identify desirable changes to the test suite that will enable it to produce better test results.

Frequency spectrum analysis counts the number of executions of each path through each function during a single run of the program. The reviewer can then compare and contrast these separate program parts in terms of higher versus lower frequency, the similarity of frequencies, or specific frequencies.

The first analysis reveals any interactions between different parts of the program, while the second analysis reveals any dependencies between the program parts. The third analysis allows the developer to look for specific patterns in the program’s execution, such as uncaught exceptions, assert failures, dynamic memory errors, and security problems. A number of dynamic analysis tools have been built to elicit or verify system-specific properties in the source code, including call sequences and data invariants.

References

[1]Assuring Software Security Through Testing, White, Black and Somewhere in Between by Mano Paul https://www.isc2.org/uploadedFiles/(ISC)2_Public_Content/Certification_Programs/CSSLP/Software%20Security%20Through%20Testing.pdf

[1] http://www.agitar.com/solutions/why_unit_testing.html

[1] http://www.swsec.com/resources/touchpoints/

[1] State-of-the-Art Report (SOAR) July 31, 2007 – Information Assurance Technology Analysis Center (IATAC) Data and Analysis Center for Software (DACS)

[1] Gu Tian-yang, Shi Yin-sheng, and Fang You-yuan “Research on Software Security Testing” – World Academy of Science, Engineering and Technology 69 2010

vii https://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Table_of_Contents

Advertisements

What is Software security testing?

Secure Software

In Software industry, Most of clients have a main requirement which is “we want the system to be secured”. Security is a non functional property of system, the main goal for securing the system to make this system dependable. So, we can depend on this system and it can perform its excepted functions as required and specified.

Therefore, it is mandatory to run the security testing procedures to insure that we can depend on this system, but we need also to consider some functional requirements on writing requirements specifications document that helps to obtain this goal.

Definition of Security testing

“Security testing is a process to determine that an information system protects data and maintains functionality as intended” Wikipedia

We can summarize that we need security testing on the following:

  1. Information and access security. Security tests help to find out loopholes that can cause loss of important information or allow intruder into the systems.
  2. System stability and availability. Security testing helps to improve the system and finally helps it to work for longer time (or it will work without hassles for the estimated time).
  3. System integrity. If involved on the early stages of development life cycle, security testing allows eliminating possible flaws in system design and implementation. We need to consider security aspects in architecture phase.
  4. Economic efficiency. It’s much cheaper to prevent the possible problem rather than to strive for resolving it and its consequences.

The main objective of software security analysis and testing is the verification that the software exhibits the following properties and behaviors:

  1. Its behavior is predictable and secure.
  2. It exposes no vulnerabilities or weaknesses (ideally it contains no vulnerabilities or weaknesses, exposed or not).
  3. Its error and exception handling routines enable it to maintain a secure state when confronted by attack patterns or intentional faults.
  4. It satisfies all of its specified and implicit nonfunctional security requirements.
  5. It does not violate any specified security constraints.
  6. As much of its runtime-interpretable source code and byte code as possible has been obscured or obfuscated to deter reverse engineering.

Software Security testing

What did they say about Software security testing?

“Over 70 percent of security vulnerabilities exist at the application layer, not the network layer” Gartner.

Hacking has moved from a hobbyist pursuit with a goal of notoriety to a criminal pursuit with a goal of money” Counterpane Internet Security.

“64 percent of developers are not confident in their ability to write secure applications” Microsoft Developer Research.

“Losses arising from vulnerable web applications are significant and expensive – up to $60 billion annually”IDC/IBM Systems Sciences Institute.

“If 50 percent of software vulnerabilities were removed prior to production use, enterprise configuration management and incident response costs would be reduced by 75 percent each.”Gartner.

General Statistics

The figures below illustrate that lake of software security allows data breaches. These breaches have been categorized by sector, this has been illustrated in figure [1] and figure [2].

clip_image001

Figure (1) Data breaches that could lead to identity theft and identities exposed, by sector
Source: Based on data provided by OSF DataLossDB (due to rounding, percentages may not total 100 percent)

clip_image002

Figure (2) Average number of identities exposed per data breach, by notable sector
Source: Based on data provided by OSF DataLossDB

The figures below illustrate that lake of software security allows data breaches. At these figures, these breaches have been categories by cause.

clip_image003

Figure (3) Data breaches that could lead to identity theft and identities exposed, by cause
Source: Based on data provided by OSF DataLossDB (due to rounding, percentages may not total 100 percent)

clip_image004

Figure (4) Average number of identities exposed per data breach, by cause
Source: Based on data provided by OSF DataLossDB

Below figure illustrates type of information exposed in deliberate breaches.

clip_image005

Figure (5) Type of information exposed in deliberate breaches
Source: Based on data provided by OSF DataLossDB (due to rounding, percentages may not total 100 percent)

The Impact of unsecured application

The impact of unsecured software application can vary from organization to another based on importance of the system and its related data as following:

The potential impact is LOW if:

The loss of confidentiality, integrity, or availability could be expected to have a limited adverse effect on organizational operations, assets, or individuals.

The potential impact is MODERATE if:

The loss of confidentiality, integrity, or availability could be expected to have a serious adverse effect on organizational operations, assets, or individuals.

The potential impact is HIGH if:

The loss of confidentiality, integrity, or availability could be expected to have a severe or catastrophic adverse effect on organizational operations, assets, or individuals.

Types of application need to have security testing

  • Web-applications
  • Applications with sensitive commercial or personal information
  • Payment and statistic systems
  • Applications, sensitive to data distortion
  • Social applications
  • Applications with expensive licensing

The need for security testing

It is important to recognize that there are three key quality components to software assurance as shown in Figure [6]; reliability, resiliency, and recoverability.

  • Reliable software is that which functions as needed by the end user.
  • Resilient software is that which is able to withstand the attempts of an attacker to compromise confidentiality, and/or impact integrity, or availability (CIA).
  • Recoverable software is software that is capable of restoring itself or being restored to expected normal operations when it has failed in its reliability or resiliency.

clip_image006

Figure (6) [i] Software Quality component

Most commonly, when software is said to be of “quality”, it essentially means that the software is working as designed and expected. This is primarily a consideration of software functionality and not its assurance capabilities. However the reliability aspect of software quality today, it is also imperative to take into account the security of the software. This two-pronged approach to software quality testing ensures that software is not only reliable but resilient to withstand attacks that impact CIA.

Therefore, Security testing is necessary because it has a distinct relationship with software quality. The software may meet quality requirements related to the functionality and performance, but it does not necessary mean that this software is secure. The inverse, however, is true.

So, software called secure when it is software with added resiliency, thus software of higher quality, for example, when the “Add to cart” button on a web page is clicked and the selected product is added to the cart (functionality) in less than the expected two-second requirement (performance). It can be urged that this software met the reliability quality requirements as established by the business, but if the software is not tested for security, there is no guarantee that the product code that is added to the cart has not been tampered by an unauthorized user.

Moreover, poor architecture and implementation of the web application cannot assure the CIA aspect of software assurance.

This was an introduction for software security testing; I will add more posts to illustrate more about the definition of Security testing, its relation with the software developing life cycle, and its techniques.

References


[i]Assuring Software security through testing, White, Black and Somewhere in between by Mano Paul https://www.isc2.org/uploadedFiles/(ISC)2_Public_Content/Certification_Programs/CSSLP/Software%20Security%20Through%20Testing.pdf