The tasks to identify and suggest security mechanisms that sufficiently offer in an economic scale a level of trust for communication in infrastructures encompassing mobile access architectures is complex. The used technology is heterogeneous and the security mechanisms that can be used are suited to each of the encompassed technologies; also, the security mechanisms protect assets or lower vulnerability depend very much on the specific roles and their individual interests participating in the communication.
The classical threat analysis is taken and enhanced by consideration of administrative domains, which describes environments of autonomy and independence for the controller of the domain, which opens temporarily their domain to interact with other domain, so that communication is enable and used, for example, to invoke services of content providers.
The methodology is organized as follows.
The first task is to:
- define security goals
- identify assumptions: detail scenario and value chain
- identify roles & assets
Subsequently, the next task is to:
- develop Domain Model (DM), map roles to domains
- identify protocol stacks at reference points (RP)
- perform threat analysis: who causes what threat to asset of whom
Finally, it is to:
- identify necessary security services/mechanisms to counter the threats
- evaluate resulting protocol stacks from security point of view
- propose security solutions
To identify sufficient security mechanisms, it is necessary to understand the problem domain, the interests of involved parties and eventually the assets that shall be protected and that are individually distinguishable. The business scenarios and value chains of MIND were valuable input to this task, especially since the scenarios highlight business roles that might appear in the future when network infrastructures will include mobile access systems, which were one of the research topic of the MIND project. Help of assets categorization has identified the individual assets so that a matrix is build up.
The next step then is to investigate in the technical environment being used by the roles. This is expressed in domains that are associated to the business scenarios roles. The purpose of the resulting DM is to describe the (access) network architecture in an abstract way allowing further developments and refinements. Mainly two issues are relevant and should be expressed by means of the DM, i.e. to
- find a way to describe the various network configurations of routers as they can be formed without listing example configurations;
- identify the responsibilities of which operators of nodes can/should care, which, as a result of any technical realisation, encompasses restrictions on the usable devices, functionalities, etc.; This includes responsibilities the operators have to obey offline (e.g. subscriptions, approval procedures, etc.).
On the other hand, the DM should describe sufficiently precisely the (access) network architecture, so that suggestions for security can be expressed. It encompasses
- the trust that needs to be achieved in flexible network configurations amongst administrative domains;
- on the technical realisation level resulting requirements, and responsibilities that are to be obeyed but can not be expressed in specific functionality (e.g. certification of routers according to specific standards).
The organisation into administrative domain is support in managing the complexity of network architecture, when security mechanisms are used to lower vulnerabilities and protect assets across heterogeneous administrative domains. When interactions go across one domain, then these relationships are expressed in terms of RPs. The objective here is to determine the functional or non-functional responsibilities and obligations forming the nature of the relationship between the associated domains.
Among the various aspects that characterise any RP, there is also the enabling technology, if any. Here, protocol stacks at RPs are used for interactions across domains. The domains and RPs describe thus the technical systems at a sufficient abstraction level (technically demanded agreements between domains to support the communication; administrative autonomy within each domain), so that a detailed threat analysis can be carried out, i.e. is to connect asset to the other domains and then determine if this threat is possible. The consequences of threats being shown are typically described as vulnerabilities.
Finally, already during the threat analysis some general security services and realizing mechanisms (authentication, authorization, integrity, non-repudiation, etc.) can be proposed to counter the identified threats. Giving hints for the security solutions that are to be proposed. The protocols at RPs are evaluated from two sides: which threats can be countered by the protocols and what new security vulnerabilities are introduced when deploying the protocols.