Integration of SVRS into the modelling tool GOAT

(1)

Institutionen för datavetenskap

Department of Computer and Information Science

Examensarbete

Integration av SVRS i modelleringsverktyget

GOAT

av

Henrik Granlund

LIU-IDA/LITH-EX-G--09/011-SE

2009-10-01

Linköpings universitet SE-581 83 Linköping, Sweden

Linköpings universitet 581 83 Linköping

(2)

Final thesis

Integration of SVRS into the modelling tool GOAT

by

Henrik Granlund

LIU-IDA/LITH-EX-G--09/011--SE 2009-10-01

(3)

(4)

Final thesis

Integration of SVRS into the modelling tool

GOAT

by

Henrik Granlund

LIU-IDA/LITH-EX-G--09/011--SE

Supervisor : David Byers

Dept. of Computer and Information Science at Link¨opings Universitet

Examiner : Nahid Shahmehri

Dept. of Computer and Information Science at Link¨opings universitet

(5)

(6)

Abstract

This document is the final report to the thesis executed by Henrik Granlund at the University of Link¨oping. The thesis is a practical assignment which includes an extension of the currently existing modelling tool GOAT. The extension regards to a integration of the internet based security database, the SHIELDS SVRS. The report goes through an overview of how GOAT is designed and later also the parts that has been extended. Thereafter follows a summary and discussion about the work.

The research leading to these results has received funding from the Eu-ropean Community’s Seventh Framework Programme (FP7/2007-2013) under grant agreement number 215995.

Keywords : SHIELDS, SVRS, GOAT, Security

(7)

(8)

List of Tables

1.1 Abbreviations . . . 3 3.1 SVRS RESTful URI’s . . . 15

(11)

(12)

List of Figures

2.1 An example of a model . . . 5

2.2 Screenshot of GOAT before any changes . . . 6

2.3 Overview of GOATs layout . . . 7

2.4 Observer chain from resource to editors . . . 8

3.1 Screenshot of GOAT after changes . . . 9

3.2 Screenshot of GOAT with changes to import window . . . 10

3.3 Updated observer hierarchy . . . 11

3.4 Root node of a model . . . 11

3.5 Import window for importing resources into models . . . 12

3.6 Flowchart for an SVRS transaction . . . 14

3.7 SocketTimeOut error . . . 18

3.8 Unknown Host error . . . 18

3.9 Core element not uploaded . . . 19

3.10 I/O exception . . . 19

3.11 Logging error messages in GOAT . . . 20

(13)

(14)

Chapter 1

Introduction

This chapter introduces the problem, goal and background to this thesis. To make the report more easily read, there is also a summary of a few common abbreviations in table 1.1.

1.1 Background

In January 2008, the University of Link¨oping started a collaboration with a number of different organizations1 with the goal to reduce the gap between security experts and software developers. The project goes under the name SHIELDS. The idea behind SHIELDS is to create a Security Vulnerabilities Repository Service (SVRS). It will act as an Internet based database where security experts are given the possibility to upload and share their knowledge in the shape of formal security models. With the aid of SVRS the models can then be provided to any software developer. These models can then be interpreted by specific tools on the developer side and thereby aid him or her in pinpointing any security flaws that might be present in their application.

The above mentioned models are created with SHIELDS specific modeling tools. One of which is named GOAT that is the center point of this thesis. GOAT is used to create these models in the form of graphs that explains relations between security vulnerabilities, causes to vulnerabilities, threats etc. . . A more detailed description of GOAT is given in chapter 2.

For more informations about SHIELDS or SHIELDS tools, go to http://www.shields-project.eu/.

1_{The entire list can be found at http://www.shields-project.eu/}

(15)

2 _{1.2. Problem}

1.2 Problem

At the moment GOAT does not have any contact or handling of information from SVRS. The thesis assignment consists of an integration of SVRS-functionality into GOAT. GOAT shall then be able to communicate and handle data and services that SVRS offers. The internal representation of SVRS in GOAT is to be implemented. The thesis also comprise of how the user is to interact with GOAT regarding the new services that are introduced.

1.3 Purpose and goal

The goal of this thesis is to enable GOAT to interact with the other parts of the SHIELDS project. This interaction should make it possible to receive and distribute models and resources that are produced with GOAT. After the thesis is completed a working implementation of the solution will be presented. The goal is also to make a local representation of SVRS inside of GOAT. This will hopefully help with the future development of GOAT and serve as a easily used interface towards SVRS. The end product will contain a simple to use GUI to make user interaction efficient.

1.4 Problem approach

To find a solution to the problem of integrating SVRS functionality into GOAT I split the work up into a few parts:

• Studies of Java as a programming language • Studies of GOAT’s internal architecture

• Studies of SVRS architecture and communication protocols • Solving to problem, stepwise

Because I have never programmed in Java before the first step had to be getting to know Java and what the differences are to other programming languages that I have worked with before, like C/C++. Next a study of how GOAT is constructed internally and specifically how the MVC architecture is laid out. This is important to quickly get acquainted and learn to get around in the environment. It also presents an opportunity to learn more about the IDE I will be using, eclipse. After studying GOAT I can begin to implement the local parts that is needed in GOAT. To start the implementation of SVRS related work I first have to study SVRS and how the machine interface is used. The implementation work is done stepwise with a vision of the final goal always in mind. The work is often paused to take a step back to plan the next step of the process.

(16)

Introduction 3

1.5 Abbreviations

Abbreviations

DOM Document Object Model

GOAT Graphical Overview and Analysis Tool GUI Graphical User Interface

HTTPS Hypertext Transfer Protocol Secure IDE Integrated Development Enviroment

MVC Model View Controller

RESTful Representational State Transfer

SAG Security Activiy Graph

SHIELDS EU-Project that contains several modeling tools and a security database.

SVRS Security Vulnerabilities Repository Service

VCG Vulnerability Cause Graph

UI User Interface

UUID Universally Unique Identifier

XMI XML Metadata Interchange

XML Extensible Markup Language

(17)

Chapter 2

GOAT and the SHIELDS

SVRS

To understand the result which will be explained in chapter 3, I will here give a briefing of GOATs architecture and explain important concepts like models, core elements and the SHIELDS SVRS.

2.1 What is a core element?

There are two kinds of basic objects which are being handled in GOAT. coreelements and models. Core elements are objects we are trying to describe. The different types of core elements are:

Causes Consequences Security Activities Security Goals Threats Vulnerabilities

As stated above, a core element is something we want to describe. A vul-nerability that a security expert is trying to describe to a software developer is classed as core element of the type ”Vulnerability”. Causes that makes some-thing occur are also considered core elements, but with the type ”Cause”. Example:

All software vulnerabilities are core elements. (Vulnerabilities)

Everything that makes the vulnerabilities occur are core elements. (Causes)

2.2 What is a model?

A model relates to a specific core element that it describes and the same model consists of several core elements that it relates to in some way. The relationship to that single core element that it describes is the reason for it’s creation and can be something like ”prevents” or ”verifies”. The model could for example

(18)

GOAT and the SHIELDS SVRS 5

describe how to prevent a vulnerability. The content of the model is a graph and it describes how the modeled core element relates to other core elements. See figure 2.1 for a concrete example where “Wrong source size used” is a cause and there are several other causes relating to it.

To clarify this we can state that:

A model describes a core element with a graph. The graph contains references to other core elements.

Figure 2.1: An example of a model

Models and core elements are considered “resources” and will sometimes be referenced by that name in this report.

2.3 What is the SHIELDS SVRS?

The SVRS, or Security Vulnerabilities Repository Service, is a database for stor-ing information about vulnerabilities found in software as well as other security knowledge. The information is gathered and put together in models. The mod-els can describe software vulnerabilities, things that cause them and how to prevent them and so forth.

The SVRS can be seen as a gathering point for all of these models. One place to keep all of the information and to keep it updated and relevant. Essentially SVRS is an object-relational database with both a machine interface and a user interface through the web. The fact that it is accessible through a web interface makes it a powerful concept. It means that anyone with an Internet connection could benefit from the knowledge of security experts around the world. The user interface will not be discussed in this document. The machine interface will be used for the GOAT-to-SVRS communication in the next chapter.

(19)

6 _{2.4. An overview of GOAT}

2.4 An overview of GOAT

GOAT stands for Graphical Overview and Analysis Tool and is a graphical modeling tool. At the moment it can handle six types of core elements1 and two types of models2. The program is written entirely in Java and is being developed at LiU. Until this point the only means of distributing models that has been created in GOAT is by translating them into XML-data and saving them to files. The idea has always been to implement a direct communication with SVRS, but has until now been absent.

Figure 2.2: Screenshot of GOAT before any changes

In figure 2.2 we can see what the program looks like in its original state when first started. To the left we have a tree structure which displays any local data (models and core elements) and to the right we have the work area where all the editors are opened. In this figure we are met with a welcome message. Every new editor is opened in a new tab.

2.5 GOATs architecture

A central part of GOAT are editors. Almost everything that is visible to the user is an editor, and by editor meaning everything that inherits from the AbstractEditor class. The entire GOAT window is an instance of the M ainW indowEditor and inside the main window there is a T reeEditor and an array of opened editors. Because the M ainW indowEditor can open all kinds of editors each new editor is presented in it’s own tab. It could be a P ropertiesEditor or an editor used to edit of one the different models avail-able. Inside the main window at bottom there is a logging window used for

1_{The ones mentioned in section 2.1}

(20)

GOAT and the SHIELDS SVRS 7 M a i n c l a s s M a i n W i n d o w E d i t o r T r e e E d i t o r T a b s V C G E d i t o r S A G E d i t o r P r o p e r t i e s E d i t o r L o g V i e w e r

Figure 2.3: Overview of GOATs layout

storing log messages.

Another important aspect of GOAT is that the program is plugin based. Everything that is used in editors are in the form of plugins. Core elements originate from the core-plugin so each time GOAT is booted up all of the plugins are loaded into the program. Without the core-plugin the program would not know how to handle core elements. The same regards to models as they also are plugins. GOAT supports two sorts of models at the moment, VCG and SAG, which originates from VCG-plugin and SAG-plugin.

To aid the plugins and allow them to tell GOAT what they can do, we have registries. Registries are a place to register functionality. If a plugin provides GOAT with a new type of model it uses the ModelRegistry to let GOAT know about it. The different kinds of registries are: DOMInputRegistry, DOMOutputRegistry, EditorRegistry, ModelRegistry, PropertiesRegistry and UIRegistry.

Two other concepts are actions and commands. These are used to perform things that a user wants done. Generally this has to do with the user interface. Commands are commonly used for performing a task associated with a button — like opening a model. Actions are similar and are associated with performing a task, for example U ploadResourceAction or ExitGoatAction which are self explanatory.

Storage in GOAT is handled by a class named M odelCollection. It is a storage area for all the models and core elements that are currently loaded into the program. This class has been replaced during this project and the changes are presented later in chapter 3.

(21)

8 _{2.6. MVC - Model/View/Controller}

2.6 MVC - Model/View/Controller

GOAT is constructed using the Model/View/Controller architecture (MVC). MVC is a common architectural design pattern in software development which isolates data logic from the presentation of data. To relate this to GOAT the models never present any data. They only provide data to the relevant projec-tions who are listening to the model. This interaction is realized with Observers and Observables which together make up an observer hierarchy. The figure 2.4 displays one of several of this kind in GOAT. In this example we have the most basic of objects lowest in the observer hierarchy, the resource, that can be either a model or core element. When a resource changes in some way it notifies it’s parents above about the change. This change will then be passed along the ob-server chain until it ends or some parent chooses not to forward the information. When doing things this way there is the benefit of viewing changes in realtime. If one editor changes a resource in some way. All other editors currently editing the resource responds immediately and displays the updated version.

Resource ModelCollection

TreeEditor

PropertiesEditor GraphEditor

(22)

Chapter 3

Result

The report is not written in a chronological order that corresponds to the order of the implementation because the work that has been done has not been that straight forward. Instead the result is explained in a top-down fashion.

3.1 Overview of result

In figure 3.1 we can see a snapshot of the finished result. The obvious change here is that the T reeEditor now is split in half and has both a local section and a remote SVRS section. This illustrates very well the purpose of the extension made to the program. To provide data from both a local source and a remote source.

Figure 3.1: Screenshot of GOAT after changes

Further new additions is seen in figure 3.2 where the import window is

(23)

10 _{3.2. TreeEditor}

displayed. Another instance of a T reeEditor is placed in every import window to support easy importing of both local and remote objects in a model.

Figure 3.2: Screenshot of GOAT with changes to import window

3.2 TreeEditor

The tree editor, seen to the left in figure 3.2 and in the import window, is implemented in the T reeEditor class. In it’s original form it had only the pos-sibility to present data from a M odelCollection. The M odelCollection was the predecessor to the now implemented M emoryRepository1 and was in charge of handling all the models and core elements currently loaded into the program. Upon initialization there exists only six nodes in the tree editor, one for each of the core element types. When a resource (model or core element) is cre-ated it is added to the M emoryRepository. Because of the observer chain the M emoryRepository then sends an AddM essage telling everyone who is noted as a listener that the resource was added. The T reeEditor is one of those and receives the message and adds the new node.

3.3 Updated observer chain

As previously mentioned there existed a class named M odelCollection. It has been replaced with three new classes and with the new changes the observer hierarchy is somewhat different. The three new classes consists of two basic repositories and one that combines those two. The repositories are discussed in more detail in 3.5, but for now this means that all changes has to go through the Repository class (figure 3.3). The Repository is in charge of combining the other

(24)

Result 11

two’s functionality into one single unit and give the appearance of one single repository. So now when a resource in memory detects a change. That change is percolated up just like before but is now sent to M emoryRepository which may take any appropriate action as a response to this change or simply forward the change to it’s own parent, Repository. The Repository also forwards the changes to all editors that are observing the Repository. All editors that operate on any kind of resources listens to the main Repository class. There can be several listeners, for example the TreeEditor which displays the resource in the tree view is notified. If a resource’s name is changed, a message of that name change is percolated up and immediately changed in the T reeEditor. The same goes for any other editor that is handling a resource. Property editors or graph editors to mention a few.

Resource MemoryRepository Repository TreeEditor PropertiesEditor GraphEditor SVRSRepository SearchResults

Figure 3.3: Updated observer hierarchy

3.4 Importing resources into models

When a model is created the user is prompted with an empty model except for the root node, which always represent the core element that it relates to. To extend the model with additional nodes the user needs to open the import window by clicking the arrow located above the node (see fig. 3.4). This brings up the import window.

(25)

12 _{3.5. Repositories}

The import window now makes use of the new T reeEditor and can be used just as before by selecting a node in the tree and pressing the import button. But it has been modified so that imports can now be done with resources that is not located in GOAT but in the remote SVRS section. If the imported resource is from SVRS and not present in memory, then it is downloaded and imported automatically. The user can make use of the search area to locate a specific resource and because of the MVC architecture the search is then mirrored in the instance of the TreeEditor back in the main window2.

Figure 3.5: Import window for importing resources into models

3.5 Repositories

M odelCollection had a few drawback that had to be corrected. It was a local solution to store resources (models and core elements) and it had pointer ref-erences which could only be used locally. That particular reason were one of the big defects with this solution. Relationships between resources are a central

(26)

Result 13

part in the entire SHIELDS structure. To be able to reference other objects are crucial and a better approach than using local pointers would be to use global UUID’s3 which does not take locality into consideration. Then a request for a resource would be sent with a UUID as opposed to asking for a specific location in memory that only GOAT understands. This enables GOAT to handle refer-enced objects that are not even loaded into the program yet. And if a request is received for a resource that currently is not present in memory the resource can then be retrieved and passed to the requester.

M odelCollection was replaced by three repository classes. One repository to represent the data local to the computer, M emoryRepository. One reposi-tory to represent data that is present in SVRS, SV RSReposireposi-tory, and one final repository to be used for data transparency, Repository. The thought behind the Repository class where that it was to be used all the time and would coor-dinate the use of the other two classes. For example if a request for a resource is received, then a search is first performed in the M emoryRepository, and if no resource was found the request would pass to SV RSRepository and then load it into memory so it can be used. If it still is not found then probably it does not exist. To understand the role of each repository you can observe figure 3.3 which clarifies the hierarchy.

3.5.1 MemoryRepository

MemoryRepository is in charge of handling three things. Models, core elements and ModelAssociations. There are a few things here that differentiates from M odelCollection. First of all the models are stored in a HashM ap with a unique UUID as a key which maps UUID to resource. This allows us to pass requests in the form of a UUID to the repository. The core elements and models are both stored as resources as they both are inherited classes from the Resource class. M odelAssociations on the other hand are stored separate. Apart from re-questing a specific resource with get(), functions for getting associated resources also exist, such as getCoreElementF or() and getM odelF or().

ModelAssociations

Another big change is that previously the models themselves kept track of which core element it depicts through a private pointer. This is what we want to eliminate. Now the M emoryRepository uses a separate Two-Way-Index to store associations between models and core elements. The association itself is stored in an object called M odelAssociation and is a simple object that contains: UUID of the model, UUID of the core element and a model role. Note the use of UUID instead of reference pointers. The role is as mentioned earlier in chapter 2 a description of the relationship between the two objects. Something like “prevents” or “verifies”. Every model that is loaded or created in GOAT must be accompanied by a M odelAssociation object that corresponds to that model. If that is not the case then there is no way of knowing which core element the model describes.

The Two-Way-Index uses two separate HashM aps. One is used to store UUID of a model mapped to a M odelAssociation. The other is used to store

(27)

UUID of a core element mapped to an array of M odelAssociations. This com-bined makes it a “two way”. You can give it either a core element, in which case you get a bunch of models that is associated with it, or you can give it a model and get a single core element which it relates to in return.

3.5.2 SVRSRepository

The SV RSRepository is a complement to the M emoryRepository and handles data that is present on the remote SVRS server. Unlike MemoryRepository it has no memory space for local data except for an array of search results from the latest search. The SV RSRepository has been made to a singleton, hence there exists only one instance of this particular class. This makes it impossible to ever have two simultaneous connections to SVRS. Requests for resources should always go through the Repository and it forwards any relevant requests to the SV RSRepository. Let’s say we request the resource with UUID “d24a48f3-9d8d-400a-86be-9cd39467e4cb” from Repository like so:

ModelID uuid = ModelID.fromString(

"d24a48f3-9d8d-400a-86be-9cd39467e4cb" );

Repository.current().get(uuid);

Then first the MemoryRepository is checked for the UUID. Thereafter if it is not found the request is passed forward to SVRSRepository. First a connection to SVRS is established with a TCP/IP handshake and an encrypted HTTPS connection is established. Then a HTTPS request is passed with the required HTTPS Headers with GET as method. The communication flow is illustrated in figure 3.6.

P r o g r a m c o d e R e p o s i t o r y S V R S R e p o s i t o r y S V R S X M L B u i l d e r S V R S P a r s e r S V R S

Figure 3.6: Flowchart for an SVRS transaction

SVRS uses what is called RESTful (Representational State Transfer) com-munication. 4 Therefor the different services are used with the URI’s in table 3.1.

(28)

Result 15

Name URI Method Payload

Upload Resource /svrs/resourcetype/{UUID} PUT XML

Update Resource /svrs/resourcetype/{UUID} PUT XML

Download Resource /svrs/resourcetype/{UUID} GET None

Search /svrs/search POST XML

Table 3.1: SVRS RESTful URI’s

Messages and requests that are sent to SVRS all work the same way and require similar input, so the communication part of SV RSRepository is per-formed the same way no matter if it is an upload, download or a search. All of the earlier mentioned requires a URI, method and in some cases a payload. All of these depend on what we are trying to accomplish and relates to the RESTful design.

Searching

The search field in the T reeEditor where earlier only there to perform searches within the tree that is displayed. While typing characters in the search field objects would be selected in the tree if their name matched the search string. This functionality is still preserved and the search field has been extended to include SVRS searches. The tree structure that represents SVRS (SHIELDS Repository in fig. 3.1) is cleared when detecting an enter key and a search request is sent to the Repository class.

In the case of sending a search query to SVRS we first determine from table 3.1 that the URI should be “/svrs/search” and the method should be “POST”. The payload is a predefined search schema in XML that is sent along. It describes what kind of search it is and in this case contains a search text which is specified as case insensitive. This is what a produced search query to SVRS could look like, including the HTTPS Headers:

POST /svrs/search HTTP/1.1 Host: www.shields.eu:7777 User-Agent: GOAT/1.0 Content-Type: application/xml Content-Length: 296 <?xml version="1.0" encoding="UTF-8"?> <s:search xmlns:xsi=’http://www.w3.org/2001/XMLSchema-instance’ xmlns:s=’http://www.shields-project.eu/svrs’ xsi:schemaLocation=’http://www.shields-project.eu/svrs SearchQuerySchema.xsd’> <s:searchtext casesensitive="0">example</s:searchtext> </s:search>

After this query has been sent. GOAT awaits an answer to be received. If no error messages are received then the returned answer consists of an XML-DOM tree. The tree is processed by an the XM LReader which interpret the content node by node. For each search result that is read a corresponding node is created and displayed in the T reeEditor0s “remote section”. The observer hierarchy

(29)

does this by percolating an AddSearchResultM essage up to the TreeEditor who catches it and takes appropriate action by displaying the new node.

Downloading

Downloading from SVRS is done with the same mechanism as a search. The same mechanism as in any SVRS request as a matter of fact. All the required parts are present here as well. The URI found in table 3.1, /svrs/resource/{UUID}, where {UUID} is replaced with the identifier of the resource that is to be down-loaded. With the method set to “GET” and an empty payload the request is sent. The response will be a XML-DOM tree. The XML answer conforms to a predefined XML schema defined by the creators of SVRS.

The XML tree contains a node named resourcedata. Inside this node we find properties that reflect the object. If the object to be downloaded is a core element, the specific constructor is looked up and fetched so the element can be created. If the object were a model we hand the xmidata that defines it over to an XMLReader which analyze and creates it. Because both core elements and models inherits from the Resource class they are automatically added to the MemoryRepository ready to use.

Contains

SV RSRepository.contains() is used to check if a resource exists on SVRS or not. It is based on the get() function that handles downloading of resources. What it does is to send a download request to SVRS and depending on if the response is a resource or if it is the standard HTTP response code 404 — File Not Found. If the response is a resource the functions returns T RU E otherwise F ALSE. This is used when sending uploads/updates to SVRS, but could also be handy in future development of GOAT. The additional parameter of version can be given if a more restricted query is needed.

Uploading and Updating

Like the previously mentioned transmissions the basics are the same with up-loading. Although uploading differs in a few other areas. We gather what

infor-mation we can from table 3.1 and determine our URI and method. “/svrs/resource/{UUID}” and “PUT”. The payload however needs some consideration and will be

ex-plained in a moment.

What separates an UPLOAD from an UPDATE is the fact that, if the re-source does not exist on the server, it is considered an UPLOAD. If a rere-source with the same UUID already exists on the server it is considered an UPDATE, and updates need an update comment to be sent along with the update. An upload does not contain such information and would give an error message if it were present.

So before creating the payload we need to determine if the request should be an upload or update by using:

SVRSRepository.contains(UUID);

A check is performed to see if it exists remotely. Depending on the answer we can now construct the payload. In case it were an update a InputDialogWindow

(30)

Result 17

pops up and requests input for the comment to submit. The task of constructing a payload is given to the SV RSXM LBuilder class. It takes an object and outputs the XML code as a string ready for transmission to SVRS.

SVRSXMLBuilder

The payload to be sent with the HTTPS request conforms to predefined XML-schema’s. SVRSXMLBuilder takes one resource as a argument. By looking at the properties of the resource it is translated to XML and returned to SVRSRepository as a string.

Core elements and models each have their own schema’s so they are treated somewhat different. The model needs an xmidata section. This section contains the graph data, something the core element obviously lacks. Because of the xmidata also being is in XML, the xmidata is converted to Base64 code to avoid any mishaps. An update for a core element would output something like the example below. <?xml version="1.0" encoding="UTF-8"?> <s:resource xmlns:s="http://www.shields-project.eu/svrs" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.shields-project.eu/svrs UploadSchema.xsd"> <s:updateinfo> <s:origversion>2</s:origversion>

<s:updatecomment>comment about update.</s:updatecomment> </s:updateinfo>

<s:coreelement>

<s:coreassociations/> <s:resourcedata>

<s:name>Necessary cause #1</s:name>

<s:uuid>01234567-89ab-cdef-0123-456789abcdef</s:uuid> <s:accesslevel>0</s:accesslevel> <s:description>This is a example.</s:description> <s:creationdate>2009-01-01T10:10:11.000+01:00</s:creationdate> <s:lastmodified>2009-02-24T16:46:28.727+01:00</s:lastmodified> <s:externalrefs/> <s:resourcetype>cause</s:resourcetype> </s:resourcedata> </s:coreelement> </s:resource> SVRSParser

All answers that return from within a HTTPS transaction are parsed with an instance of this class. Because all answers from SVRS are in XML-format the same approach is taken on all answers. SVRSParser first creates a DOM-tree out of the XML and proceeds to step through each node, one-by-one. For each node it asks the DOMInputRegistry if there is a reader that can handle a node of this type. Normally a class is sent back in response and the node is then passed to that particular handler for further processing.

(31)

18 _{3.6. Error handling}

to ease communication between classes and they are all registered in the DOM-InputRegistry when the SVRSRepository is first instantiated.

3.6 Error handling

When having to deal with transactions over the Internet we can not always count on a request returning successfully. Errors are handled different depending on what we want to achieve. In general if something is not accomplished an error message pops up in a dialog window requesting that the user take some action to correct the situation. If the error is not critical it is merely logged in the logging window. When the SV RSRepository is trying to contact SVRS and the connection timeout, then the request is sent once more. The server could just have been occupied with other requests or the users connection might be very slow. All SVRS functions has this retry system for recovering a lost answer and the number of retries can be set in a constant named RET RY AT T EM P T S (default set to 3 retries). If the answer is still unrecoverable the user is either prompted with figure 3.7 or 3.8.

Figure 3.7: SocketTimeOut

SocketTimeOut error occurs when the server is not responding in time. Three retries are made then this message is prompted together with a log entry.

Figure 3.8: Unknown Host error

Unknown Host error occurs when the server is not reachable. Three retries are made then this message is prompted together with a log entry.

(32)

Result 19

Figure 3.9: Core element not uploaded

Core element not uploaded. This is prompted when the user is trying to upload a model without the corresponding core element being uploaded first. The parent has to exist on SVRS for a model that describes it to be uploaded.

Figure 3.10: I/O exception

If something is unreadable in the responses received from SVRS. Maybe an incorrect base64-code. Then this message is displayed.

(33)

20 _{3.6. Error handling}

Figure 3.11: Logging error messages in GOAT

Errors that does not output a dialog window may still report to the logger that something did not succeed. All of the above error messages that displays a pop up to the user still adds an entry to the logger in addition to the pop up.

(34)

Chapter 4

Discussion

My approach to integrating SVRS into GOAT was primarily to imagine the final result and then setting up partial goals in order to get to that point. It seemed as a good choice of strategy and I still consider it as a valid option. Even a requirement. Although the fact that i had no previous experience with working in Java or programming in a relatively large and complicated environment made estimating what parts the solution would comprise of very hard. As a result my time plan were too general, and the estimated time for each task seldom corresponded to reality.

The initial work phase had to be getting acquainted with GOATs architec-ture, and early on everything went according to schedule. The lack of experience sometimes led me to solutions that worked but not in an optimal fashion. In these cases I often took the decision to remake the solution because the previ-ously wasn’t satisfactory. As this happened repeatedly it caused the time plan to be pushed forward. As I prioritized the implementation before the report I ended up writing the report after the planned period.

Over this period of time I have learned plenty and even before I knew that planning is a crucial part of a project. This has been confirmed and I realize that I could have planned even more, which would have made the implementation go smoother. Experience is in my opinion the best asset and there is no shortcut to get there, but this has been a big step to getting there. I feel that my Java knowledge has increase tenfold.

I’m satisfied with the end result but I would have liked to have more time with testing the application.

I’ve learned a lot but i realize that there is much more to learn. Especially about workflow in a project. I feel that I have much more experience in working with code that is being shared and worked on by other people at the same time. Changes to a program can’t just be submitted without thought and with this project each team member has had their own designated areas of the program.

(35)

(36)

Appendix A

Test protocol

A.1 Description

This is a test protocol to verify that the SVRS funtionality is working properly.

A.2 Requirements

• A working internet connection.

• A newly started instance of GOAT. (≥ REV. 411) • SVRS need to be online and accessible.

A.3 Activities

#1

Activity

2 PASS 2 FAIL Start a new instance of GOAT and type “failure” in the

search field and press ENTER Expected outcome

Search results should appear in the SHIELDS Repositroy tree.

#2

Activity

2 PASS 2 FAIL Replace “failure” in the search field with “use” and press

ENTER.

Expected outcome

The previous search results should be cleared and re-placed with the new search results.

(37)

24 _{A.3. Activities}

Activity

2 PASS 2 FAIL Create a new core element without any special

charac-ters. Create a VCG model to this core element. Right-click the model and choose upload.

Expected outcome

The upload should be denied because of the core element not being on svrs.

(39)

(40)

Avdelning, Institution Division, Department Datum Date Spr˚ak Language 2 Svenska/Swedish 4 Engelska/English 2 Rapporttyp Report category 2 Licentiatavhandling 4 Examensarbete 2 C-uppsats 2 D-uppsats 2 ¨Ovrig rapport 2

URL f¨or elektronisk version

ISBN ISRN

Serietitel och serienummer Title of series, numbering

ISSN Titel Title F¨orfattare Author Sammanfattning Abstract Nyckelord Keywords

This document is the final report to the thesis executed by Henrik Granlund at the University of Link¨oping. The thesis is a practical assignment which includes an extension of the currently existing mod-elling tool GOAT. The extension regards to a integration of the internet based security database, the SHIELDS SVRS. The report goes through an overview of how GOAT is designed and later also the parts that has been extended. Thereafter follows a summary and discussion about the work.

The research leading to these results has received funding from the European Community’s Seventh Framework Programme (FP7/2007-2013) under grant agreement number 215995.

ADIT,

Dept. of Computer and Information Science 581 83 LINK ¨OPING 2009-10-01 — LIU-IDA/LITH-EX-G--09/011--SE — http://www.ep.liu.se/exjobb/ida/2009/dd-d/011/ 2009-10-01

Integration of SVRS into the modelling tool GOAT Integration av SVRS i modelleringsverktyget GOAT

Henrik Granlund

(41)

(42)

Copyright

Svenska

Detta dokument h˚alls tillgängligt p˚a Internet - eller dess framtida ersättare - under 25 ˚ar fr˚an publiceringsdatum under förutsättning att inga extraordinära omständigheter uppst˚ar.

Tillg˚ang till dokumentet innebär tillst˚and för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för under-visning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillst˚and. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet p˚a ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i s˚adan form eller i s˚adant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/

English

The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years from the date of publication barring exceptional circumstances.

The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Link¨oping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/

c

Henrik Granlund Link¨oping, October 8, 2009

Integration of SVRS into the modelling tool GOAT

Institutionen för datavetenskap

Department of Computer and Information Science

Examensarbete

Integration av SVRS i modelleringsverktyget

GOAT

Henrik Granlund

LIU-IDA/LITH-EX-G--09/011-SE

2009-10-01

Integration of SVRS into the modelling tool GOAT

Integration of SVRS into the modelling tool

GOAT

Abstract

Contents

List of Tables

List of Figures

Chapter 1

Introduction

1.1

Background

1.2

Problem

1.3

Purpose and goal

1.4

Problem approach

1.5

Abbreviations

Chapter 2

GOAT and the SHIELDS

SVRS

2.1

What is a core element?

2.2

What is a model?

2.3

What is the SHIELDS SVRS?

2.4

An overview of GOAT

2.5

GOATs architecture

2.6

MVC - Model/View/Controller

Chapter 3

Result

3.1

Overview of result

3.2

TreeEditor

3.3

Updated observer chain

3.4

Importing resources into models

3.5

Repositories

3.5.1

MemoryRepository

3.5.2

SVRSRepository

3.6

Error handling

Chapter 4

Discussion

Appendix A

Test protocol

A.1

Description

A.2

Requirements

A.3

Activities

#1

#2

#3

#4

#5

#6

#7

#8

Copyright