using-the-assurance-questionare
2.3 Using the Assurance Questionnaire
It is anticipated that assurance with the Framework will become an integral part of an organisation’s security process and will provide the supporting evidence for business assurance. An accompanying audit and assessment tool (available to IoTSF Members), the Assurance Questionnaire, may be used at various stages in the product lifecycle. Firstly, by identifying the need for security at the concept stage; secondly listing evidence gathered; to finally signing off security requirements for production release.
The evidence gathering process can only commence after establishing the Assurance Class described in section 2.2. This is done using a risk assessment (see Appendix A).
Once the Assurance Class is determined, the applicable requirements are automatically derived by the accompanying Assurance Questionnaire tool as either mandatory (M) or advisory (A). The Assurance Questionnaire could also be used to optimise the product design and establish if a change would allow a lower Assurance Class to be selected. For example, by not collecting or processing sensitive personal data or perhaps providing automatic failover to alternative services for customers to maintain service availability.
2.3.1 Assessment Methodology
The assessment method is determined by the context i.e. Business (process) or System (technical) and the Class.This determines both the type of assessment e.g. physical testing or document review, along with the degree of rigour from Self-Assessment for lower Classes to full third-party audit for high classes.
2.3.2 Keywords
To improve the usability of this document the requirements in sections 2.4.3 to 2.4.16 have been categorised using the keywords defined in the Table 3 below.
Primary Keyword | Description | Secondary keyword | Description |
---|---|---|---|
System | The requirement is applicable to the technical elements of the device/ product or service | Software | The requirement is directly applicable to the software of the device or service |
Hardware | The requirement is directly applicable to the electronics of the device/service hardware (PCB, processor, components etc.) | ||
Physical | The requirement is directly applicable to mechanical aspects of the device such as the casing, form factor etc. | ||
Business | A business requirement not directly related to the operational function of the device/ product or service | Process | A flow of activities that indirectly contributes to the security characteristics of a device or service |
Policy | The instructions and guidelines that indirectly contribute to the security characteristics of a device or service | ||
Responsibility | A role or responsibility that indirectly contributes to the security characteristics of a device or service |
Table 3: Keyword Categories
Please Note: the terms Device and Product are interchangeable in this document
2.3.3 Assurance Requirements Completion Responsibilities
The Assurance requirements completion will be addressed by a variety of roles in an organisation. These roles cannot be prescribed exactly as every organisation is different, but each section of requirements may require the attention of Managers and other specialist staff as suggested in Table 4 below. Responsibility for any individual requirement may be determined by use of the associated keywords, which can be selected by filter, for users of the Assurance Questionnaire.
Section | Topic | Topic Audience & Typical Responsibilities |
---|---|---|
2.4.3 | Business Security Processes, Policies and Responsibilities | Management responsible for governance of a business developing and deploying IoT Devices. |
2.4.4 | Device Hardware & Physical Security | Design and Production staff responsible for hardware and mechanical quality. |
2.4.5 | Device Software | Device application quality management by Software Architects, Product Owners and Release Managers. |
2.4.6 | Device Operating System | Management and Design staff responsible for selection of a third- party operating system or assessing the quality of ‘in-house’ developed software. |
2.4.7 | Device Wired and Wireless Interfaces | Design and Production staff responsible for device communications security. |
2.4.8 | Authentication and Authorisation | Design and Production staff responsible for security of the IoT systems interfaces and foundations of authentication. |
2.4.9 | Encryption and Key Management for Hardware | Design and Production staff responsible for security of the IoT systems hardware key management and encryption. |
2.4.10 | Web User Interface | Design and Production staff responsible for security of the IoT Product or Services’ Web Systems. |
2.4.11 | Mobile Application | Design and Production staff responsible for security of the IoT Product or Services’ Mobile Application. |
2.4.12 | Privacy | Management and staff responsible for Data Protection and Privacy regulatory compliance. |
2.4.13 | Cloud and Network Elements | Design and Production staff responsible for security of the IoT Product or Services’ Cloud or Network Systems. |
2.4.14 | Secure Supply Chain and Production | Management, Design and Production staff responsible for security of the IoT Product or Services’ Supply Chain. |
2.4.15 | Configuration | Design and Production staff responsible for security of the device and IoT Services configurations. |
2.4.16 | Device Ownership Transfer | Management, Design and Production staff responsible for a products and services’ Supply Chain. |
Table 4: Assurance Responsibilities
Relevant requirements should be shown as “addressed” and a reference made to the applicable evidence for the product design.
The accompanying Assurance Questionnaire allows for entries, against each relevant requirement, of either the evidence gathered to prove assurance or a link to that evidence. The evidence may be compiled from a number of sources and people. Evidence should be verified by the person responsible for completion of the Framework and such verification should be recorded.
An example of completed Assurance Questionnaire fragment on Business Processes for a high-risk Class 3 device is shown Figure 1 below.
ReqNo | Requirement | Required Assessment Method | Evidence Type | Pre-Assurance | Evidence | Responsability |
---|---|---|---|---|---|---|
2.4.3.1 | There is a person or role, typically a board level executive, who takes ownership of and is responsible for product, service and business level security and makes and monitors the security policy | SA Document review + TP Inquiry | Organisation al Chart and Job role description/documentation and Proof of Competence (certification/attestation) | URL or reference to document with Third party attestation | CIO name | |
2.4.3.2 | There is a person or role, who takes ownership for adherence to this compliance framework process. | SA Document review + TP Inquiry | Organisation al Chart and Job role description/documentation and Proof of Competence (certification/attestation) | URL or reference to document with Third party attestation | CIO name | |
2.4.3.4 | The company follows industry standard cyber security recommenda tions (e.g. UK Cyber Essentials, NIST Cyber Security Framework, ISO27000 etc.). | SA Document review + TP Inquiry | Organisation al Chart and Job role description/documentation and Proof of Competence (certification/attestation) | URL or reference to document with Third party attestation | CIO name |
Figure 2: Assurance Questionnaire Partially Completed Example
2.3.4 Evidence
This Framework offers a comprehensive set of security requirements (see section 2.4 under Assurance Applicability) and should be used with the products or services design documentation including the Risk Register. Evidence of the mitigations made to address each risk line item must also be recorded. Users of the Framework should therefore create their own records and IoTSF members are encouraged to use the Assurance Questionnaire for the recording process.
Such records should be kept safe and secure, we recommend having back-up copies. They could be useful in the case of real-world threats to the product, but also as evidence for any business assurance regimes used in the organisation. The record keeper should enable access, for auditing, to any referenced evidence and supporting documents. URLs especially should be checked to ensure they will remain accessible at least for the life of the product plus any warranty period. Attention should also be paid to maintaining any tools or applications needed to view the evidence material.
An organisation procuring products, systems and services from a supplier, which declares it has used the Framework, may request an audit of the evidence assembled, using either internal resources or a Trusted Third Party (“T3P”). A T3P might be used in situations where the documented evidence would expose sensitive information such as intellectual property or commercial aspects.