Categorizing Data

Having analyzed your applications and categorized them into fitness levels, you must now begin categorizing the data and services offered by those applications. This information will be used to build a security model. The categorization process itself is a procedure of data and service categorization, followed by cataloguing the existing authentication and authorization systems.

The information collected in Evaluating Applications is used for the former portion of the process. A good methodology might be to organize the collected information into various tiers of security. These tiers would indicate the amount of risk associated with data loss, application compromise, abuse, or other illicit types of access. Using well-defined categories can help to simplify the mapping of resources into a security model incorporating authentication and authorization requirements.

The data or service is separated into four levels of security. The X axis is the data or service and the Y axis is the security level associated with it. Tier 1 is illustrated with a minimal amount of security and might be data applicable to a public web site. Tier 4, on the other hand, requires maximum security and might be financial or human resources (HR) data. Your organization’s categorization might have more or less tiers, but this chart shows how typical it is for large amounts of data to have low associated risk, and thus, low security requirements. As risk associated goes up, security requirements also go up. (Usually, there is very little data with high security requirements, and a lot of data with limited or no security requirements.)

The following figure shows the security requirements for data and services within a typical organization.

Figure 2–1 Security Requirements of Data and Services

Keep in mind that you are planning to build functional groupings of data and service types so that authentication and authorization functions can be mapped to them. Too many tiers can inject extra complexity into your process, while too few tiers might not offer enough flexibility. It is also important to note that there might be data with too much risk to place on the network at all. If relevant, make sure distinctions are made between internal and externally available data. Keep authentication and authorization requirements in mind as you build out these tiers, as well as conditional qualifiers such as such as access time of data and network location.

Mapping To Authentication

With the data categorized according to security level, the next step is to inventory authentication and authorization mechanisms. Using a current list of available authentication mechanisms, associate those mechanisms with the security tiers defined. For example, the following association might be appropriate for the data categorized in the previous figure.

• Tier 1 data might be appropriate for anonymous authentication with no access control.

• Tier 2 data might require password protection only.

• Tier 3 data might require hard token or certificate authentication.

• Tier 4 data might require multi-factor authentication (or might not be placed on the network at all).

You should ensure a clean mapping between authentication requirements and the data and services categorization. If there is none, look for common criteria between those items that do not match. Don’t hesitate to make multiple charts if logical distinctions occur.

For example, separate charts can be made for intranet and extranet applications. You might also categorize data based upon a functional security domain such as human resources (HR) or finance. While not a universally applicable tool, categorizing your data in this manner can help you to understand your security requirements and to map them into logically manageable groups.

Mapping To Authorization

Using the data available from your application assessment, examine each of the applications to determine a scalable authorization model. Typically, it is best to look for common groups and roles used across applications. Ideally, these groups and roles will map to functional roles within the organization. You should also determine the source of those groups and roles (where does the membership data live and how is it modeled). For example, the data might be in Sun Java System Directory Server.

If not, custom plug-ins might be required. If a robust grouping model is in place, begin associating each application with existing groups or roles. If not, begin planning a group or role mechanism, finding common relationships between functional user types and access to specific applications. When completed, you should have the following items:

• A clear map of existing groups and roles.

• A clear understanding of where that data lives and who is the authority over its quality and management.

• A clear understanding of new groups or roles that need to be created to facilitate your deployment or to reduce cost and complexity of the deployment.

• A mapping of existing and future grouping mechanisms to your categorized applications.

• Notes on additional conditions required by the applications to allow access to a certain group or role.

With this basic security model (categorization of data, with correlation to authentication and authorization mechanisms), you can now put together a time line to drive your deployment.