четверг, 14 января 2010 г.

Thoughts on building a taxonomy of vulnerabilities, pt.1

Classifications, taxonomies... Web security...
I decided to make a number of posts discussing these topics.
The important questions are:
- what is a classification; what is a taxonomy;
- what to classify: flaws or vulnerabilities; and what for;
- what are the existing taxonomies/classifications;
- why it is easier to build a taxonomuy of attacks/threats than of flaws or vulnerabilities;
- finally, is it possible to build a useful taxonomy of web application vulnerabilities.

First of all, I'd like to introduce the notion of taxonomy, just to make sure those readers that might come across these posts are synchronized with me.
In common life the terms taxonomy and classification are usually used interchangeably. Further, often by word “classification” people refer to some process of breaking the set of items into groups. Let us introduce some order here.
Marradi (“Classification, typology, taxonomy”) defines the process of classification as one of the following:

  • an intellectual operation, whereby the extension of a concept at a given level of generality is subdivided into several narrower extensions corresponding to as many concepts at a lower level of generality;

  • an operation whereby the objects or events in a given set are divided into two or more subsets according to the perceived similarities of one or several properties; or

  • an operation whereby objects or events are assigned to classes or types that have been previously defined.


As we see, there are two approaches to building a classification. I will call them a model-based (from the general to the particular, or some might say deductive) approach and an instance-based (from the particular to the general, or some might say inductive) approach respectively.
Ok, what's then a taxonomy anyways?
According to Simpson (“Principles of animal taxonomy”), a taxonomy is a “classification, including bases, principles, procedures and rules”. Thus, a taxonomy is more than a classification – it states the principles, according to which the classification is done, and procedures to be followed in order to classify new objects.
Taxonomies should have taxonomic categories with the following characteristics:

  1. Mutually exclusive: the categories do not overlap.

  2. Exhaustive: taken together, the categories include all the possibilities.

  3. Unambiguous: clear and precise so that classification is not uncertain, regardless of who is classifying.

  4. Repeatable: repeated applications result in the same classification, regardless of who is classifying.

  5. Accepted: logical and intuitive so that categories could become generally approved.

  6. Useful: could be used to gain insight into the field of inquiry.


As the authors of “A Vulnerability Taxonomy Methodology applied to the Web Services” point out, there is no such thing as the ultimate taxonomy. Rather, each taxonomy is designed for the specific intended usage. Hence, the value of each taxonomy and its usefulness should be considered along with the viewpoint and the scope that the authors thereof had intended. Moreover, the authors of the certain taxonomy should explicitly state the intended usage, the scope and the viewpoint thereof.

In the next post I am going to say a few words on taxonomies in application to web security. The important questions is: what to classify: flaws or vulnerabilities? And what for?

понедельник, 11 января 2010 г.

NULL pointer dereference flaw -> vulnerability

NULL pointer dereference is a common implementation-time flaw. Sometimes this flaw becomes a vulnerability. Strangely, but this is because of a bad design.


To illustrate this, let us consider a network application. Suppose, it dereferences a NULL pointer under certain circumstances. In order for this flaw to become a vulnerability, a single user should have an opportunity to interrupt application services exploiting NULL pointer dereference. Obviously, this is a bad design decision.


This is the way implementation-time flaw becomes a design-time vulnerability.

среда, 6 января 2010 г.