Home | Service requirement

Service requirement

By now you should have produced a "Business case" and addressed the "Project startup" stages for your WARP. You should also have secured the necessary resources to proceed to this service definition phase and beyond. You are also likely to have reviewed some aspects of this stage in creating your Business case, to satisfy yourself that the WARP services can add real value to your community.

In this stage you will have an opportunity to check that the three core WARP services meet the requirements of your own community. To do this you will be able to use requirements capture and analysis techniques to help define exactly which of the three core services your WARP will have to deliver to meet your members’ needs. This section of the Toolbox will also help you understand how results from the pilot WARP produced the service definition for the three core services.

The two stages in the process of producing the service definition are described within this section of the Toolbox, along with example documents and case study Reference tools to help you along the way. The two stages are:

1. Requirements capture

2. Requirements analysis

1. Requirements capture

It is important to ensure that the WARP services described in this Toolbox meet the needs of your WARP community so that subsequent development will provide an optimum set of services for your community. It is also important to understand some of the issues which will help you position the argument for joining a WARP and therefore help recruit members. These requirements can be captured by meeting with prospective WARP members and the following interview checklist has been provided to help structure this process.

Requirements interview checklist (V1.0 June 2004)

Various formal or informal requirements capture techniques can be used. In the pilot study an open interview technique was used but discussion was based on the same headings as described in the previous example interview checklist. Points and activities arising from requirements meetings with members were recorded and identified for use in the analysis phase. A requirements capture summary of the points and activities raised by members of the pilot WARP is available as an example. This will be of further help to those responsible for directing and managing the requirements capture interviews for your WARP.

Back to top

Requirements capture example

This section describes the consolidated results of the WARP Service Requirements Capture exercise conducted with representative WARP members.

1. Filtering existing Warnings and Advisories is the service which adds the most value - especially in the short term;
2. Filtering should not be limited to a single individual in a members organisation;
3. A tick list of 'information categories' needs to be created where people can easily identify the information they would like to receive - the relevance/quality of this list is a critical success factor;
4. This list should be used as part of a registration process on an SSL web server;
5. The registration data will provide a valuable distribution list not just for filtering warnings and advisories but also for identifying communities with expert knowledge in particular areas;
6. A bulletin board type facility should be created to enable members to share information - further investigation is required on number of members participating and anonymity requirements;
7. Providing a trusted incident reporting and early warning service based on the common community was highlighted as important, and one which cannot easily be provided elsewhere. This service should be provided as high priority;
8. The trusted environment needs to be supported by bi-lateral NDAs;
9. A secure on-line reporting template should be created to simplify reporting;
10. Any filtered warning and advisory service should cater for multi-skilled individuals and team working;
11. A patch management support service should be investigated further;
12. A mechanism to enable members to share experience and good practice should be pursued;
13. Collective purchasing by, for example, organising security related training to meet members needs, should be investigated. This would also help establish the trusted community - possibly combine with the previous item.

These points were used as the input to the following Requirements Analysis exercise which resulted in the final Service Definitions of the three core services: Filtered Warnings, Advice Brokering and Trusted Sharing.

Back to top

2. Requirements analysis

Once the points and activities are defined for each WARP member it will be necessary to do a formal or informal fit analysis to determine which of the three core services need to be provided to meet their requirements. The Requirements analysis for a pilot WARP is available in the Toolbox as an example of fit analysis. You can use this as a model on which to base your own analysis if you wish.

This information, including more detailed requirements reflecting the responses of individual members of the pilot WARP, is also contained in a downloadable document, which you can easily print and customise.

Requirements analysis for a pilot WARP (V1.0 June 2004)

Back to top

Requirements analysis example

Analysis of the points/activities described in the previous section resulted in the identification of three core WARP services described below:

• Filtered Warnings Service - The basic concept of this service is that members will complete an on-line 'secure' tick-list which identifies their area of interest. Warnings and Advisories from a number of sources, including UNIRAS and the membership itself, will be filtered against the tick-list criteria for relevance and urgency and disseminated via email in a timely manner. This filtering will be done manually but this operation will be facilitated by an automated application.

Fit Analysis - points 1,2,3,4,5 & 10 from the WARP Requirements section are met by this service.

• Advice Brokering Service - This service will provide the community with the facility to set up a dialogue between themselves in a secure environment. Members will be able to ask each another for help or advice on Information Security issues or, conversely, offer good practice advice based on their own experiences. One way of facilitating this dialogue will be with an on-line Bulletin Board. This will be monitored by the WARP central team who will be proactive in furthering discussion and will summarise any discussions of interest. Taking note sensitivities, these could then be issued as news items or suitable training organised to help give the WARP that 'personal touch.

Fit Analysis - points 6,12 & parts 11,13 from the WARP Requirements section are met by this service.

• Trusted Sharing Service - This service will create a trusted environment to facilitate the sharing of sensitive information, such as incident or threat data, so that members will have the confidence that any information they share will not cause them harm. The benefit being that members will be alerted to information which would enable them to take timely preventative action, learning from other members experience. Reporting can be done via the telephone, via email or via an on-line system, with appropriate security safeguards as outlined in a WARP security policy agreed by members. In all cases a reporting template will be provided to help members provide the salient information. The identity of the reporting member will only be known by named individuals working in the central WARP team and controlled within the terms of a bi-lateral Non-Disclosure Agreement (NDA) with each member. The information reported will be analysed, checked to ensure anonymity, and then shared with other members using a secure dissemination route. The central team will facilitate any ensuing dialogue to ensure that the information is used by members to maximum advantage while safeguarding the interests of the reporting member under the terms of the NDA.

Fit Analysis - points 7,8 & 9 from the WARP Requirements section are met by this service.

Note: - From the Requirements capture section, points 11 (patch management) and 13 (collective purchasing e.g. training) can both be facilitated using the Advice Brokering service which can be used as a general purpose communication and sharing facility. It is noted that this Brokeing Service also provides a useful tool to judge the need for future services and support, and the discussion content should be routinely analysed as part of any WARP review.

Next step - Filtered Warnings Service describes the first WARP core service.

Back to top