- Unauthorized copying of applications or data
- Unauthorized access control (e.g., ability to perform tasks for which the user does not have rights). User rights, access and privileges are the focus of this testing. This information should be available in the specifications for the system.
- Software which exhibits unintended side-effects when performing its intended function. For example, a media player which correctly plays audio but does so by writing files out to unencrypted temporary storage exhibits a side-effect which may be exploited by software pirates.
- Code inserted into a web page which may be exercised by subsequent users (cross-site scripting or XSS). This code may be malicious.
- Buffer overflow (buffer overrun) which may be caused by entering strings into a user interface input field which are longer than the code can correctly handle. A buffer overflow vulnerability represents an opportunity for running malicious code instructions.
- Denial of service, which prevents users from interacting with an application (e.g., by overloading a web server with “nuisance” requests).
- The interception, mimicking and/or altering and subsequent relaying of communications (e.g., credit card transactions) by a third party such that a user remains unaware of that third party’s presence (“Man in the Middle” attack)
- Breaking the encryption codes used to protect sensitive data
- Logic bombs (sometimes called Easter Eggs), which may be maliciously inserted into code and which activate only under certain conditions (e.g., on a specific date). When logic bombs activate, they may perform malicious acts such as the deletion of files or formatting of disks.
Security Test Planning
In general the following aspects are of particular relevance when planning security tests:
- Because security issues can be introduced during the architecture, design and implementation of the system, security testing may be scheduled for the unit, integration and system testing levels. Due to the changing nature of security threats, security tests may also be scheduled on a regular basis after the system has entered production.
- The test strategies proposed by the Technical Test Analyst may include code reviews and static analysis with security tools. These can be effective in finding security issues in architecture, design documents and code that are easily missed during dynamic testing.
- The Technical Test Analyst may be called upon to design and execute certain security “attacks” (see below) which require careful planning and coordination with stakeholders. Other security tests may be performed in cooperation with developers or with Test Analysts (e.g., testing user rights, access and privileges). Planning of the security tests must include careful consideration of organizational issues such as these.
- An essential aspect of security test planning is obtaining approvals. For the Technical Test Analyst, this means obtaining explicit permission from the Test Manager to perform the planned security tests. Any additional, unplanned tests performed could appear to be actual attacks and the person conducting those tests could be at risk for legal action. With nothing in writing to show intent and authorization, the excuse “We were performing a security test” may be difficult to explain convincingly.
- It should be noted that improvements which may be made to the security of a system may affect its performance. After making security improvements it is advisable to consider the need for conducting performance tests.
Security Test Specification
Particular security tests may be grouped according to the origin of the security risk:
- User interface related – unauthorized access and malicious inputs
- File system related – access to sensitive data stored in files or repositories
- Operating system related – storage of sensitive information such as passwords in non- encrypted form in memory which could be exposed when the system is crashed through malicious inputs
- External software related – interactions which may occur among external components that the system utilizes. These may be at the network level (e.g., incorrect packets or messages passed) or at the software component level (e.g., failure of a software component on which the software relies).
The following approach may be used to develop security tests:
- Gather information which may be useful in specifying tests, such as names of employees, physical addresses, details regarding the internal networks, IP numbers, identity of software or hardware used, and operating system version.
- Perform a vulnerability scan using widely available tools. Such tools are not used directly to compromise the system(s), but to identify vulnerabilities that are, or that may result in, a breach of security policy. Specific vulnerabilities can also be identified using checklists such as those provided by the National Institute of Standards and Technology (NIST).
- Develop “attack plans” (i.e., a plan of testing actions intended to compromise a particular system’s security policy) using the gathered information. Several inputs via various interfaces (e.g., user interface, file system) need to be specified in the attack plans to detect the most severe security faults. The various “attacks” described in are a valuable source of techniques developed specifically for security testing.
Security issues can also be exposed by reviews and/or the use of static analysis tools. Static analysis tools contain an extensive set of rules which are specific to security threats and against which the code is checked. For example, buffer overflow issues, caused by failure to check buffer size before data assignment, can be found by the tool.
Static analysis tools can be used for web code to check for possible exposure to security vulnerabilities such as code injection, cookie security, cross site scripting, resource tampering and SQL code injection.