The project's idea is to create a flexible application for finding vulnerabilities and their potential exploits on the given data flow diagram (DFD).

The input diagram is an XML document which defined under the basic and extended XML Schema. This XML Schema can be modified and expanded for the specific needs of the project. The same goes for exploits and assets. If the existing definitions are not suitable and more exploits or assets are needed, the user can simply modify these XML files. If exploit and asset definitions are updated the rule-engine definition files have to be updated as well, so changes can be included in the analyzing process.

The system consists of five components:

1. EDS Application (written in Java) - Main part of the system that manages resource files, decomposes DFD into patterns, generates reports, etc.
2. Rule Definitions (Drools files) - Files which contain definitions of rules used to find potential exploits
3. Data Flow Diagram Schema (XML Schema file) - XML Schema used to validate input DFD
4. Exploit Definitions (XML file) - Contains definitions of exploits which can be found and are used in rules
5. Asset Definitions (XML file) - Contains definitions of assets which are in use
6. XML Schema Apply Tool - Simple tool that applies changes on XML schema by creating library with classes that describe XML schema elements
7. .tm7 to Input DFD Conversion Tool - Tool that converts DFDs created with Microsoft Threat Modelling Tool to DFDs suitable for this system

There are two more components that are not part of the system but are used for properly handling:

8. Data flow diagram file (XML file) - This file represents the structure of a system that is to be analyzed. This is the systems main input, and it has to be in accordance with DFD XML schema (component 3).
9. Report file (XML file) - Result of the analyzing process. Contains exploits, with their definitions, that are found for the selected diagram.

The user chooses all of the above components, except application (component 1) and rule definitions (component 2), before starting the analyzing process. Rule definition files are listed in the specific file named "locations.txt", where the user can change rule files that are in use or can add new ones.

Analyzing process can be divided into six main phases:

1. Validating and importing resources
2. Applying assets
3. Decomposing data flow diagram
4. Analyzing diagram patterns
5. Applying exploits
6. Creating report

When the analyzing process is started, the system checks if the required XML documents are valid, and loads them afterward. These documents are: asset definitions document, exploit definitions documents and system's data flow diagram (which will be analyzed).

Because elements on DFD contain only id's of the assets they hold, the system has to merge asset definitions to diagram elements using these id's. After merging, the application can easily access properties of each element's assets.

Next step is decomposing diagram into patterns that will be analyzed. The algorithm goes through every diagram's node and finds all the other nodes that are directly or indirectly leading to this one. Patterns are made out of these nodes and links. Also, every node has a pattern representing itself (this pattern has no links, just node).

For example, diagram like this: a <-----> b <-----> c, would give us these patterns: a, a <----- b, a <----- b <----- c, b, b <----- a, b <----- c, c, c <----- b, c <----- b <----- a

After diagram is decomposed to patterns, set of rules are applied to these patterns. Every asset has corresponding rules definition file. At the beginning, the first rule of every file is activated. This rule checks if the pattern contains resource corresponding to this file. If it does - next group of rules in that file is activated. If it does not - rest of rules in that file won't be activated.

Rest of the rules are searching for vulnerabilities in this pattern. They are checking the type of nodes and links in the pattern. Depending on the type, a different subgroup of rules is activated. The subgroup controls an attributes specific for that element type. Some of the rules are more specific and even check all of the elements in the pattern and their attributes.

When pattern's vulnerability is discovered, rules are for looking for an exploit that could exploit this vulnerability. When the exploit is found, it's id is added to this pattern's list of discovered exploits.

When potential exploits are discovered for each pattern and their id's are saved, system loads exploits definitions. Using exploit id's, the system merges exploit definitions to patterns. Now, patterns contain definitions of exploits which are found over it and every definition contains exploit description and recommended countermeasures.

Every diagram pattern which contains at least one exploit is converted to a report-pattern. Report-pattern contains information that would be useful for the user: pattern starting element, pattern ending element and list of potential exploits. Report-patterns are gathered and combined into report XML. Some basic information is added to this report: date and time of creation and name of diagram that was analyzed. This report is saved to file that is chosen by the user.

EDS is implemented using Java technology version 8. Besides Java, the project holds two more libraries: drools-compiler and kie-api. The first one contains the compiler/builder components to take rule source and build executable rule bases. The second library provides a knowledge-centric API, which is used to create service and session that will execute rules.

One more tool is used in this project and it is Maven. It helps to easily download required libraries, compile and build this project.

Anybody can be using the system and anybody can create input files. Anyway, it is recommended for it to be used this way. In order to get the most precise results, a different type of users should be creating different input files.

• Input files which represent system architecture such as system's data flow diagram and DFD's XML schema should be created by the system architect
• The knowledge base (which is written in rule definition files) and exploits definition file should be created by a security expert
• Asset definitions file should be created by a system architect and security expert
• The final report should be handed over to an employee who is working as system architect or manager

As it is stated before, this is not an obligation but a suggestion in order to get the most out of this system.

The application has a modest user interface and it is easy to use.

The user has to choose a location of diagram that is going to be analyzed, and location where the report will be saved. As additional settings, the user can locate another resource XML files where exploits and assets are defined or another diagram XML schema file. The picture below shows application's main window. After the user clicks "Analyze diagram and Create report" button, the process is started and the status window pops out.

Status window shows the current state of the analyzing process and a "Cancel" button. This button can be used at any time to stop the process. You can see the status window at the picture below.

When the process is finished successfully user is prompted to close the dialog or to locate the report. Otherwise, if the process had an error and did not finish, there is an error message displayed.