- Understanding Trust
- Qualities of Trust Relationships
- Major Trust Models
- Developing Your Own Trust Model
- Conclusions
- Acknowledgements
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Developing Your Own Trust Model
Just as we identified original entity authentication as the first step in establishing trust, we need to identify the starting point for defining a trust model. We have already talked about matching a model to business requirements, but at this point, we will go back an additional step. At the very foundation of trust model development, there should be a basic principle governing acceptable use of both data and processing resources. Sometimes this is referred to as the security stance. A common security principle used by many organizations in the Internet space is that data must be accessible only on a need-to-know basis, and processing resources must be accessible only to those explicitly approved to use them.
This principle would be appropriate for an organization with stringent security requirements, but another organization concerned with attracting customer interest would have a different philosophy about access to at least certain types of data.
With the underlying principle understood, the next step is to gather business requirements. These requirements must be specific to the organization, although they may well be similar to those of other comparable organizations. In many cases, requirements will be determined by legal and regulatory mandates. Perhaps a Service Level Agreement (SLA) will be a determining factor. If there is a requirement for a certain level of performance (such as speed, throughput, or availability), it must be identified, because a security mechanism with a noticeable impact on performance might be unacceptable.
Next, build a threat profile based on a data flow analysis. An example of a data flow analysis is provided below, but the key point here is to catalog threats and vulnerabilities. Some risks are going to be more significant than others and will require greater effort to mitigate. Some may even be judged relatively inconsequential and therefore not cost-effective to address.
In assessing risk, be sure not to focus solely on technical issues. It cannot be stated often enough that good security requires a combination of people, process, and technology. Look for those places where human error or poorly designed processes introduce risk.
Finally, identify security mechanisms to respond to those risks that must be addressed. Response mechanisms may be technical in nature (for example, a firewall), but they may also address the human factor (for example, better training). At this point, a technical solution will likely be identified at a relatively high level (for example, to install a firewall). The choice of the specific firewall to install and the configuration details generally come later in an implementation phase.
Example of a Data Flow Analysis
To illustrate what data flow analysis offers, consider the example of online banking. For the purposes of illustration, the following steps assume the customer wants to view his current account balance, and the bank has already established customer authentication credentials.
The customer initiates a session with bank's server. The protocol governing the session is SSL.
The SSL server dialog is established, which encompasses all of the following steps. (Note that client-side SSL authentication is not performed.)
The customer enters the required information (for example, name, account number, and PIN) on the login screen.
The authentication server validates credentials.
The Web services server presents a welcome and a menu of options the customer can invoke.
The customer's selection of the account query option is passed to the application server.
The application server queries the authorization server to see if the selected option is allowed.
The authentication server returns a response to the application server, based on rules. For this example, it allows the query to be made.
The application server requests the database server to obtain account records.
The database server returns records to the application server.
The application server formats data and passes it to the Web services server for presentation to the customer.
Note that the SSL server has encrypted all session data to and from the customer.
)
FIGURE 1
Data Flow Analysis
In this example, two types of data were processed:
Customer authentication information (name, account number, PIN)
Customer account information (account balance)
A complete analysis requires examination of the type of data processed at each trust point, identification of the types of threats affecting each trust point, and specification of the appropriate countermeasure.
For the purposes of this example, start by identifying all the different servers involved:
- SSL server
- Authentication server
- Web services server
- Application server
- Authorization server
- Database server
For a seemingly simple request, the sheer number of servers dramatizes the number of communication paths, and therefore trust points, that data flows through. Each of the trust points is also a potential attack point. A security failure of any of these points could have very damaging consequences.
What is the risk of exploitation of a security failure? Presumably, it is very high, because sensitive financial data is at stake. Compromises could lead to disastrous results, such as:
Someone other than the account owner gaining access to data
Legitimate account owner being presented with more information than should be transmitted
Account owner (or someone else) being able to perform unauthorized transactions
Our hypothetical financial institution must have as minimum business requirements (no doubt reinforced by legal and regulatory requirements) the need to protect data confidentiality and integrity.
Trust Model Derived From the Example
Upon completion of a much more thorough analysis of threats, based on data flow analysis, risks, and business requirements, you have the information necessary to determine the appropriate trust model. In the example, to satisfy the requirements for confidentiality, integrity, and non-repudiation, there must be very stringent authentication and authorization mechanisms. Because sensitive data is being transmitted over the Internet, encryption should be required. The trust required is between the customer and the bank. No trust among the various customers using the online banking application is required or even allowed. Based on these facts, a direct trust model should be employed. Because the type of information a customer is allowed to access must be strictly controlled, the trust model incorporates the basic principle: data will be accessible only on a need-to-know basis.
Expressed more formally, our trust model might read something like the following:
The security architecture must implement a direct trust model.
All users must be identified and authenticated. Trust and authentication can never be implied or assumed.
No transitive or assumptive trust can exist between any component of the bank's computing environment and any external system.
Entities that are uniquely identified and authenticated may be trusted to access data and resources only on a predefined need-to-know basis.
Data transferred over the Internet between the bank and an authenticated user must be encrypted.