Extend evaluation function

[JefJacobs00]

Extend evaluation function

The tools need to be evaluated based on two types of information: Historic based info and Session based info.

Historic info

The historic based information is info that comes from previous scans. Evaluation parameters are:

• Amount of new info
• Usefulness of the info
• Execution time

The amount of new info is the added information that the scan adds to the knowledge base. This information can be used for other tools. If the information is used by other tools it is useful information. Then the execution time of a scan is also considered.

Session info

This information is based on the current session and what has happened so far in the execution process of the framework. The evaluation parameters based on session information is:

• Amount of similar scans that have been executed
• Info required for tools that have not yet executed
• Attack path/chain

When a scan is executed Prolog remembers this. If the tool is similar to an already executed tool the usefulness of the tool goes down. In a session tools may need certain information to run. To speed up the process tools that grant that information should be prioritised. The attack path or attack chain is the current vector the framework is trying to exploit. To remember attack paths and reuse them it could be good to keep some kind of logical execution of tools.

Let's say a gobuster scan has just executed and revealed a couple of webpages. A normal pentester would first explore those before trying to brute force an ssh port that it saw before.

[JefJacobs00]

Amount of new info

Amount of new info is done. Parser.pl now checks what the amount of info a profile has given in total. Also per scan it can give the result. Only one scan gets points for discovering data. So if you first do a full scan and then a fast scan you won't find new info. The other way around you can find new info.

[JefJacobs00]

Usefulness of the info

The way I thought it could be solved was with adding what input values a scan has had. This is difficult because the put data in ontology function can not know when data is a parameter or a result. Issues with linking.

Parameter klasse waarin de URI mee gegeven wordt van de gebruikte parameter. In prolog kan dit dan bekeken worden Scan -> parameters

[JefJacobs00]

Info required

Add part in the config file that just says what it requires, maybe parameter could be used. For gobuster a service would be required. Then the tools that have not yet executed might not be as easy but a weight could be added by the expected result from a tool perhaps.

[JefJacobs00]

Attack chain

Usage of most recent info is prioritised. Adding the Uri of a parameter would make it possible to see if the most recent info is in the parameters. Adding the uri in the parameters is required for usefulness of the info anyways.

[JefJacobs00]

Amount of new info

Represents the amount of info a profile has resulted so far.

Preficates

• totalProfileInfo/2 (total info profile has resulted)
• listProfileInfo/2 (list with the info a profile had as result)

Eval

1. Avg/max (How good the avg result is compared to the max result or consistency of the scan)
2. Mean/max
3. total
4. Avg

Usefulness of the info

Represents the usages of the info

Predicates

• checkUsefullnessProfile/2

Eval

1. Info uses
2. Info uses / info resulted (The avg uses per scan)

Info required

Indicate how many profiles can use this information

Predicates

• checkParameterCount/2
• profileDemand/2

Eval

Instead of +1 when a tool uses the info add the quality of the tool.

1. Amount of time the info gets used

Attack chain

Adds higher priority to tools that use recently acquired information

Predicate

• checkAttackChain/1

Eval

When a tool uses the most recent parameters, add 1*weight