Usability-requirements

Usability-issues are mostly about how the user perceives and uses the solution. An overall set of headlines gave birth to the listed usability-requirements in this section. These headlines are:

Overview: The solution should present a GUI, which enables the user to see the current config-uration and the processing done by the tool.

It manifest itself as req# B1, B2, B3 and B4.

Configuration: Whatever the presentation-type, it should present an clear overview, which en-able the user to make adjustments in what is being presented.

It manifest itself as req# B1, B2 and B6.

Trust: The user must have confidence in the changes performed by the solution, and such con-fidence should be high due to the high security impact of mis-configuration. Being able to

see and change at various layers and APIs enables trust in the resulting processing.

It manifest itself as req# B3, B4 and B5.

Maintenance: The user must be able to use the tool to maintain and alter setups as time goes by. This implies a usage-cycle which reads the setup, alters it and saves it again. Also, such enables progressing of experience-levels from setup to setup - and user to user.

It manifest itself as req# B6 and B7.

With the above headlines in mind - a solution should incorporate some of the following specific requirements:

Req# Description Reasoning

Category Priority Workload

B1

* See the current running processes on the host, that have opened network-communication-sockets. I.e. server- and clients-processes that are poised for communication. In essence, this is specifying Input- and Output-policies for processes run-ning locally on the host.

* See the current network-interfaces and -routing on the host.

Possibly with display of network-segments and -hosts found on neighbouring segment. This is specifying Forwarding- and NAT’ing-policies¹ for processes running on remote hosts pars-ing though the local host.

The above ability to see the communication-poised processes to-gether with the network-interfaces forms the basis for firewall-rules - as experienced by the user. The user is concerned with the Question: ”What program on what computer, is to be allowed in or out?” But, firewall-rules needs programs and computers represented as port- and IP-numbers. The port-number can be traced to the program-processes, and the IP-addresses are as-signed to the network-interfaces. Hence the need for displaying processes and interfaces.

Functional Essential

Easy

B2

* See and configure the firewall’s local filtering setup (Input-/Output-filters, see Section 5.1). This is specifying rules for local processes.

* See and configure the firewall’s forwarding setup (Forward-and NAT-filters, see Section 5.1 etc.). This is specifying rules for remote processes on remote machines (forwarding) and for rules relating to re-routing (NAT’ing).

Display and configuration of the firewall setup should be intu-itive point-’n-click (or drag-n’-drop) operations.

E.g. the user selects a network-interface (#B1), drags and drop it onto a local web-server-process (#B1), then a dialog pops up with suggested rules for allowing incoming traffic to the web-server running on the host. Had the user done the reverse, i.e.

selected the server and dropped it on the interface - the rules would indicate outgoing traffic etc.

Functional Essential

Hard

Req# Description Reasoning

Category Priority Workload

B3

* Any point-’n-click (or drag-n’-drop) operations should be rea-sonable simple, and whenever confirmations or possible decisions are to be made, a dialog or wizard should guide the user.

Since some operations are difficult to fully automate, a semi-automated approach is necessary - as argued for in Sec. 2.4.

But, the core goal is still to achieve as automated a process as possible, and wizards and dialogs are good for creating checkpoint-states in any process-flow.

Functional Highly Desirable

Unknown

B4

* Any changes and results should be pre-viewable before they actually take effect. I.e. the ability to see generated rules be-fore execution, output of actual execution and result of actually accepted commands by the firewall.

Allowing inspection and confirmation of important security choices are essential. It creates a built-in solution for verify-ing expected results - by expert eyes. And for providverify-ing insight and teach context to less experienced users.

A pre-viewable, complete, round-trip firewall-environment could be achieved by operating in a inactive/disabled part of the firewall-rules, thereby manipulating and inspecting the result and only then, actually activating the part.

Functional Highly Desirable

Unknown

B5

* Logs of execution should be saved for tracing changes and inspecting execution-trace.

Such are confidence building measures allowing back-tracking, error-traceability and forensic-investigations.

Functional Desirable

Unknown

B6

* Ability of importing the current firewall setup (rules) and re-exporting them again, making the solution capable of per-forming the complete round-trip-engineering of a firewall-maintenance-cycle.

With the ability of import/export, pre-defined setups can be provided to novice users, and customised rule-sets can be car-ried on from host to host. In general, this is raising the over-all protection-level by providing means for expert-knowledge to proliferate - just like libraries.

Functional Essential

Medium

B7

* Learn new types of rules from the user, i.e. rules that aren’t part of a pre-defined/-programmed setup. This involve creating a engine which can turn newly discovered rules into drag-able objects for future reference and use.

Providing means for teaching the application new abilities by scripting new rules into sets of specific tasks e.g. an anti-spoofing rule-set. An another way for expert-knowledge to be manufactured.

For the tools to remain vibrant, libraries should easily created (#B7) and published (#B6).

Functional Desirable

Hard

Usability is a notoriously error-prone and subjective area, where good guidelines exists - but no right answers. In general, all the usabilityrequirement below boils down to: ”I want to see it -click and change it - verify it, and thereby trust the result.”

Therefore, the GUI should show the firewall-setup including the processes and network-interfaces in a clearly perceived overview. The firewall inside the kernel is used by this projectas is, and it already have an matured conceptual model for showing packets-flows. This architectural model

will be the link from processes to network-interfaces and -routing, thereby making it possible to show a complete overview of packet-flows policies for the local host. The challenge is turning the complete overview into aclearly perceived overview - that is clearly an usability-issue.