Current existing and conventional tools fail to support industrial needs adequately. Although requirements are very diverse there is a common set of industry generic requirements applicable to a large number of industrial software developing companies. The RASEN project is addressing those, striving to deliver a new methodology and a supportive software environment.

The RASEN project (http://www.rasenproject.eu/) is a European Research Project, which investigates new means of risk management and security testing and their application to large scale networked systems. This modelling approach – or more precisely – this modelling convention is based on extended ARIS models and attributes and capable of picturing an actual software product by its different components and their sub-components. These elements can be classified in pre-defined and manually-defined component types. A component type itself consists of a defined set of weaknesses derived out of the Common Weakness Enumeration (CWEs) Schema [1]. A CWE in turn describes a typical weakness in a software system. This modelling convention is described in detail in the next few lines.

Picture 1: Abstract view of a product model containing a Product, a vignette describing the deployment, and a number of components/sub-components used to classify the product. The model contains “Generic Component Types” – containing a predefined set of weaknesses to a certain components – as well as “User-Specific Component Types” defined by the used.

The illustration above denotes an abstract overall view of a product model. A product model itself describes a software product with a so called vignette and its building blocks namely its components. Therefore a tree-like structure is used. The root element is described by the product itself, components are connected to the product and are represented as nodes on the first level. Components may consist of other components and so on. There is no limitation in terms of depth of the tree. All components have zero to n different component types. To indicate that a component is of a special component type, the component type element is connected to the component element.

 

Product Model

Picture 2: Product Model of a Sample Application

In ARIS a so called Application System Diagram are used to picture a product model in its tree structure. The root element is an Application System. In addition, the vignette defines the deployment scenario of the application. In the RASEN Modeling Framework different reports and macros are included to assist a modeler by creating such models. To create a product model a modeler can use the Create Product report. Using this report the name of the product and the vignette of the product must be specified (cf. vignette section).

 

Component

Picture 3: A product consists of different components, for instance of a Web Interface

A component is modelled as an object of type Module in a manual step by creating the component hierarchy. A modeler just has to place a “Module” with a name in the product model and connect it to its parent either the product root element or another component. In addition, a component type represents the type of component along with its underlying weaknesses.

Generic Component type

Picture 4: A component type providing a generic component of type “Networking” along with an assigned list of applicable CWEs.

The illustration above shows the content of a component type model for type Networking. A component type consists of a defined set of CWEs. Therefore one has to make sure the CWE database is already imported to the ARIS database. To do so the “Import CWE database” report can be used. Component types can be generated by using the “Create Component Type” macro. To use a component type to specify a component, a modeler has to open the component type model and copy the module type object (in Picture 4 “User Controlled Input”) and paste it in the product model. Then he or she just has to connect the component type with the component he or she wants to specify. In the RASEN package a set of predefined generic component types is contained. These component types can be imported by using the “Import Component Types” report. Note that also in this case the CWE database has to be imported first.

 

Picture 5: A component type providing a generic component of type “Networking” along with an assigned list of applicable CWEs.

As denoted in the graphic before, the networking CWE List contains two potential weaknesses (CWE-226, CWE-406) which need to be tested in order to evaluate the risk of the component and consequently the overall risk of the product.

Vignette

A vignette is a table that represents the different impacts of CWEs on different layers. Layers may cover Application Layer, System Layer, Network Layer, or Enterprise Layer. A vignette is created automatically when the Create Product Macro is used. A vignette nevertheless can be modified manually be editing the vignette model. Such a model is displayed in the following figure.

Picture 6: A vignette defining the deployment scenario for the Application Layer   The goal of the created product model is to represent which security issues can occur on which level. It is possible to perform an export of the model as a JSON representation. This JSON representation builds an interface to security testing components that evaluate the model and in a final step we will create a possibility to retransfer these results back to the model to give a better overview on how high the security impact is at which component always with the overall product in view.

References

[1] CWE: Common Weakness Enumeration Framework, MITRE, 2015, http://cwe.mitre.org/

 or register to reply.

Notify Moderator