Trusts and Risk Acceptance/Avoidance Sample Clauses

Trusts and Risk Acceptance/Avoidance. As noted in Section 2, trust is really one of the possible responses to a potential risk (risk acceptance), alongside other responses (risk avoidance or distrust, risk transfer, or risk reduction by means of security measures). A trustor is really someone who believes1 that certain risks will not arise or (if they do) will not cause them undue harm. To capture what the trustor is really assuming, it is necessary to understand what risks are present, and which of those risks the trustor is accepting. We propose that the 5G-ENSURE trust model should be based on the most comprehensive and rigorous model of risks that can be constructed, following the approach used in the FP7 OPTET project based on machine understandable models, as described in Section 3.3.3. This approach is also well suited to the agile, configurable nature of virtualised 5G networks because it is based on identifying generic types of asset, threats, consequences and countermeasures, and then deriving potential threats in a given situation by mapping knowledge of the generic archetypes onto a specific system configuration. To give a simple example of this, one might identify two generic related asset types:  Service: an asset that responds to requests by carrying out actions;  Client: an asset that initiates requests to a Service. If a Client ‘uses’ a Service, it means that particular Client initiates requests to that particular Service. In many situations the Service needs to know which Stakeholder controls the Client, so its action can be correctly attributed and billed, and so confidential information from the Stakeholder is not released to a third party. An attacker might seek to impersonate a Client in order to get the service without paying, or to gain access to confidential information. These attacks can be represented as generic threats. In this simple example, the Impersonation threats could be countered if the Service implements client authentication (i.e. verifies the identity of the Client before taking a requested action), and the Client has a verifiable form of identification such as a username/password, or a PKI identity certificate, etc. In a specific system, one might choose to address a risk by implementing such countermeasures. This knowledge can be captured by encoding it as semantic relationships, as shown in Figure 14. 1 But see Section 6.2.5 below. Identi- fication protects Client ClientAuth- entication protects Service Client Imp- ersonation