Structure of specifying security for each area in the Taxonomy
A.1 Core specification
The Zero Outage Security Taxonomy for IoT (refer to Figure 2) consists of 32 areas arranged in an architectural manner. For each area a security specification will be provided which is concise and right to the point. The specification uses the structure below. Each area will fill approximately one page. Some descriptions may be shorter.
The template can be found below. Text in brackets needs to be replaced by the area specific text. [Text in brackets also provide hints for providing the required information. All such text is deleted after being used.].
|[short description of cluster]|
|Area in Taxonomy||Abbr.||IT components, procedures and other subjects|
|[name of area plus|
|[code]||[short description of the subject: What is covered? What are main issues? Not more than approx. 50 characters]|
Scope and Content:
- [Add a couple of bullet points helping to understand the subject: What are the technical components or activities for which security will be specified? Specify technologies or technical components such as product groups. Mention products without mentioning product names and vendors. Enumerate activities or refer to business process like the ones defined in ISO 20000.]
Goals and Objectives:
- [Provide a bulleted list of several security objectives (neither threats, problems and issues nor requirements or solutions). That is what needs to be achieved. Outline the secure state and describe briefly what one shall pursue and aim at.]
- [In this way, we are close to stating solutions. The specification of actual solutions is almost impossible without any knowledge about the specific IoT system. However, stating security objectives provides the reader with helpful information on what he or she must care for.]
- [The specification of security objectives is always highly recommended since only this allows checking if a specification and an implementation of security measures (technologies and practices) is actually suitable and appropriate.]
Primary external support:
The Taxonomy is designed in a way that its areas stand for themselves as much as possible. Nevertheless, the above area requires security support from the following area(s):
- [Provide the name of the area and outline what type of security service is expected and required from there in order to be able to achieve the security objectives by implementing security measures in the area specified here. Consider this description to be a short reference only. Do not describe full problems and solutions. Note that this is a table in Word that adjusts the icon of the right.]
- [More than one dependency may occur. An example for a dependency is the following: Managing Changes requires to have an Asset and Configuration Management in place. Add only a very short description. Only state inputs (services that are required) and not outputs (areas that utilize the area describe in this structure.]
A.2 Specification of security measures
When, according to Annex B, all these specifications are available, one can stipulate security measures based on the security objective definition. This should be done as follows:
- The definition of the security measures should be embedded into a structure according to the Specification Concept described by Zero Outage Industry Standard.
- The definition of the security measures themselves should follow the structure given below. The inserted text also provides explanation for the specification.
Security measure: [description/name] ([Code of area]/[Code of measure])[Each security measure is given a name which is unique (refer to the line above). Here a specification of the security measure is given by stating security related facts. Instead of “XYZ shall be implemented in order to ensure that…”, the description shall be provided as “XYZ is implemented in order to ensure that…” Make also clear if this measure builts upon another (in the same area) which shall be reffered through its six-digit code such as TTE-ABC.]
- [The so-called implementation guidance provides further details and substantiation with examples of implementation or technical detail. Especially technically oriented readers are therefore helped to associate the security measure with their own practical experience and knowledge.]
- [The implementation guidance can refer to specific solutions as examples. It can provide tips or explanations.]
- [Several bullets can be added as appropriate.]
Rationale:[A rationale is provided for each security measure which provides justification and additional information about the purpose and benefit of the security measure. Through this, it is shown that the means are complete and working together. The Rationale feeds back to the security analysis and to the definition of security objectives.]