Index Up Site Map Latest News Working Practices Discussion & Review Glossary Module Testing Non-Func. Testing Links Test Papers Feedback Administration

Security - e-Business

This item is scheduled for review.   Received comments are at the end of this page.

Please send any comments you have on the example using the Feedback Form.

Example – Penetration Testing



Testing company “A” has conducted a series of penetration security tests directed at one IP address associated with a new investment web site built by company “B”.

 The overall purpose of this activity was to evaluate the externally observable application and web server security configuration and thereby assist company B’s management in ascertaining the current level of conformance to network security policy.


A profile of network security was accumulated through the use of specific and controlled security penetration and diagnostic methods. Specifically, the scope of the testing comprised of: 

bulletPhase 1 - Information retrieval
bulletPhase 2 - Vulnerability testing of network services on specified components

Phase 1 – Information Retrieval

The first step of the analysis consisted of querying publicly available databases on the Internet for information regarding the specified company B’s system. To have a network presence on the Internet implies exposure since it is a public environment. This information may include names of employees, physical addresses, details regarding the internals network, IP-numbers and software or hardware used.

A profile or network map of the system listed above and other information was created of company “B” using widely available tools. This included identification by platform, operating system version and application,. This formed the basis of the selection of appropriate “attack paths” during phase 2.

Phase 2 – Vulnerability Scan

The specified system address was programmatically scanned using a variety of commercial and publicly available network security assessment software. Such software is not used directly to compromise systems, but to identify vulnerabilities that are, or that may result in, a breach security policy. Typically this type of software seeks vulnerabilities that may be exploited to gain unauthorised high-level access to information systems and therefore must be updated daily with the latest list of possible vulnerabilities.

Phase 1 – Information Retrieval

This section describes how phase 1 was performed

Public Information – Queries were conducted against the whois databases, Arin, RIPE, ApNic, InterNic and other appropriate registries such as IP-indexes, domain search sites to discover domains and IP network ranges associated with the client. This was done without accessing any of company B’s systems.

Normal Known Traffic – This step involves extracting information-using channels that will not differ from any normal Internet use, for example browsing company B’s available web sites, therefore should not create any alerts triggered by company B’s firewall or Intrusion Detection Software (IDS). Extracting information was achieved by connecting to know services such as HTTP, HTTPS and FTP, then downloading as much content as possible and searched the data collected for relevant information.

Host Enumeration – This step evolves determining the IP address of potential targets on a network via the use of tools such as Icmpenum. Icmpenum  uses not only ICMP Echo packets to probe networks, but also ICMP Timestamp and ICMP Information packets as well. Furthermore, it supports spoofing and promiscuous listening for reply packets. Icmpenum is used for enumerating networks who block ICMP Echo packets but have failed to block Timestamp or Information packet, or for upstream sniffing of trusted addresses.

Full Contact Enumeration – Scanning was performed against the web site, which included TCP, UDP, stealth protool, RPC scanning as well as TCP-fingerprinting, fragmentation and reverse ident scanning. The scan also included banner grabbing and information gathering through services such as SNMP, finger, rusers, SMTP and NetBIOS.

The information gathered via the above methods is then used to identify the system types for vulnerability scanning during phase 2.

Phase 2 – Vulnerability Scan

An e-Business site may be vulnerable to two main mechanisms of attack:

bulletPenetration – unauthorised access to the system or its resources or to data held on the system
bulletDenial of Service – Where the system is flooded with traffic, preventing authorised users from normal work. This may be caused by a malicious attack, or be an indication of the vulnerability of the system to heavy loads or errors.

A mixture of a commercial available automated scanning tool and specific exploitation techniques was used, such as techniques to exploit buffer overflows, race conditions, enhanced password cracking and denial of service attacks.

A checklist of possible vulnerabilities was then created. Below is an example of such a checklist derived from categories used by Security Focus

Checklist of Possible Vulnerabilities


bulletAccess Validation Faults
bulleta subject invokes an operation on an object outside its access domain
bulletan error occurs as a result of reading or writing to/from a file or device outside a subject's access domain
bulletan error results when an object accepts input from and unauthorised subject
bulletan error results because the system failed to properly or completely authenticate a subject.
bulletfailure of user input checking results in component failure, incorrect operation and/or data leakage.
bulleta user can bypass security checks e.g. by entering the URL of a web page nominally password protected
bulletan intruder impersonates the identity of an authorised user (e.g. by adopting their network IP address)
bulletPassive - an intruder obtains data from the system (e.g. passwords, security information, transaction details) by capturing network traffic.
bulletActive - an intruder runs code on the system, enabling them to access data. (Trojan Horse)
bulletEnvironment Faults
bulletA fault results from an interaction in a specific environment between functionally correct modules
bulletA fault occurs only when a program is executed on a specific machine, under a particular configuration
bulletA fault occurs because the operational environment is different from that for which the software was designed.
bulletan unauthorised device can be inserted into the system allowing the intruder to obtain information and data.
bulletConfiguration Faults
bulletA fault results because a system utility was installed with incorrect set-up parameters
bulletA fault occurs by exploiting a system utility that was installed in the wrong place 
bulletA fault occurs because access permissions were incorrectly set on a utility such that it violated the security policy.(e.g. the utility allows a user to access parts of the system normally blocked to them)
bulletthe default configuration of a component places the component or system in an insecure state. (e.g. systems shipped with default passwords in place)
bulletInput Validation Fault
bulleta fault occurs because a program failed to recognize syntactically incorrect input
bulleta fault results when a module accepted extraneous input fields
bulleta fault results when a module failed to handle missing input fields
bulleta fault results because of a field-value correlation error.
bulletFailure to Handle Exceptional Conditions
bulletan error manifests itself because the system failed to handle an exceptional condition generated by a functional module, device, or user input.
bulletinformation relating to the configuration or build of a component is freely obtainable or obtainable through other errors. (e.g. error messages providing database structure)
bulletAtomicity Faults
bulleta fault occurs when partially-modified data structures were observed by another process
bulleta fault occurs because the code terminated with data only partially modified as part of some operation that should have been atomic.
bulletRace Condition Fault
bulleta fault is exploited during a timing window between two operations.
bulletit is possible to modify input data after validation of the data has taken place but prior to final submission. (e.g. in a two stage transition process where the validity of the data is checked after the first stage)
bulletSerialisation Faults
bulletA fault results from inadequate or improper serialisation of operations.

Denial of Service

bulletData overload
bulletThe system is flooded with traffic, preventing authorised users from normal work. This may be caused by a malicious attack, or be an indication of the vulnerability of the system to heavy loads or errors.
bulletBuffer Overflow
bulletFailure of a component to adequately check the length of received data (e.g. input data) prior to passing it to a small, fixed length buffer
bulletBoundary Conditions
bulleta process attempts to read or write beyond a valid address boundary
bulleta system resource is exhausted
bulletan error results from an overflow of a static-sized data structure (classic buffer overflow conditions).

Completion of the Attack/Vulnerability Matrix (AVM)

Once the vulnerabilities have been identified, an Attack Vulnerability Matrix should be completed for both mechanisms of attack

Example: (This is a very basic example – the final one should be more extensive)

Denial of Service AVM


Heavy traffic




Malformed data




Fragmented packets




URL Flood




Mail Flood





Data overload

Buffer Overflow

Boundary Conditions


Derivation of Test Cases & Testing of the implementation

Given the list of possible vulnerabilities from the Attack Vulnerability Matrix test cases were created to test for the presence of vulnerabilities in each of the components of the system. These test cases should cover all possible system configurations.


Comment from Isabel Evans Lots of really useful information, needs to be transferred to the template agreed at the last meeting.

Would be useful to have some test cases in the example.

Useful to have the phased approach and the list of vulnerabilities - might be good to have (eventually :-) ) in the guidelines for the standard a generic list of vulnerabilities or a long example list and then in the example the specific vulnerabilities to be checked in this system.

May be useful to set some acceptance criteria as part of the requirements for the example, perhaps based on ISO 9126 e.g to show the level of risk to be contained in the example system - as presumably the higher risk to the system, the greater effort spent on security testing and the higher the acceotance criteria are set. Example might be percentage of different types of vulnerability to be contained by the system security?

Normal known traffic: Should the test cases be directed not only at confirming the firewall does check for access from the web site (which the example implies) but also at finding the places where the firewall does not check but should? For example a state transition test to show the ways that information moves from inside to outside the firewall and vice versa?

Is there a place for using any review / inspection techniques? I am thinking here that e.g. in the UK the Data Protection Agency have rules about what is personal data and what may / may not be kept/kept public. So an inspection of the system rules against the DPA rules might show vulnerabilities/places of illegal access?

Terminology - does some of the security terminology need to be in the glossary, or if not testing specific, explained in the example:

Tools and techniques mentioned: are these freely available/shareware/owned? DO they need acknowledgement/sources in a table at the end?

Comment from Marco Giromini Sorry but I did not have enough time to make a detailed review.

Anyway I think it is good and I basically agree with it.

Comment from Margaret Edney This example needs some expansion. I accept this is a huge area to deal with.

The information retrieval section is quite informative and should help testers get an idea of how to start.

The example starts off as a description of a penetration attack but the matrix only lists a few examples for DoS attacks. The penetration matrix is much harder! The vulnerability scan should help to populate the matrix. It is also important to check that any countermeasures for a penetration attack don't trigger a major DoS.

There is nothing on any techniques used to derive the test cases (e.g. use of syntax testing to determine values that should be illegal and then creating packets with these values.)