Novell is now a part of Micro Focus

Network Security: Determining Your Risk Index

Articles and Tips: article

RICH LEE
Senior Research Engineer
Novell Systems Research

01 Aug 1996


This AppNote presents commercially-applicable material which can help network administrators determine the Risk Index associated with sensitive data and the users who access that data. This information can be used as a guide for network administrators and auditors in organizing security objectives, addressing the security concerns of management, and establishing the requisite amount of security for a company's data. Since implementation must be based on a company's real need for security, this AppNote also aims to promote an understanding of the need for protective mechanisms within the network operating system.

RELATED APPNOTES Jul 96 "Shaping the Infrastructure for Information Security in the 21st Century" Mar 95 "NetWare Workstation Security Architecture" Aug 94 "An Introduction to Novell's Open Security Architecture"

Introduction

Connectivity is the rule today. It is easy to observe the growing diversity of the local area network as new connections appear everywhere--the Internet, NetWare Connect Services, remote dial-up, and so on. Unfortunately, the greater the diversity of connections, the harder it becomes to find a general mechanism to secure data. A "one size fits all" cure for security has been extremely elusive.

The basic problem is that growing connectivity increases the vulnerability of computer systems to attack. Recent coverage of security in the trade press has been beneficial in that it has stimulated security conversations inside many organizations. However, most of these articles do not offer any real insight on how to resolve these increased security concerns. Most are non-prescriptive, and worse, some propose "patch and fix" as a viable approach to end-user security.

In our previous articles, we have looked at the ongoing benefits derived from working with evaluated security products, as well as the security assurances those evaluations can provide. We have also emphasized the critical need for all network systems administrators to have this understanding. Our previous NetNote on the differences between Red Book and Orange Book evaluation explained how to obtain those security assurances (see "Network Security: Red Book vs. Orange Book Evaluation" on page 74 of the June 1996 issue).

This AppNote introduces an often overlooked but highly essential initial component of network information security analysis--the Risk Index. LAN administrators working at the server configuration level and with user accounts, as well as those dealing with large integrated systems, need quantifiable security metrics that can be applied to networked systems. Risk Index provides such a metric.

This AppNote also examines what constitutes a real security risk on your network, and presents guidelines for creating a viable corporate security policy. This information is targeted toward LAN administrators, corporate network systems administrators, and corporate Electronic Data Processing (EDP) auditors, so that each group will have an understanding of the security goals and objectives of the others.

Risk Index Defined

For the purposes of this article, we define Risk Index as a number --an integer derived from a simple, straightforward calculation of information sensitivity. Neither the calculation nor the integer is very difficult to obtain, and one does not have to have any advanced degrees in security science or auditing to utilize them.

Risk Index involves the two basic fundamentals of computer networks--the data and the users. There are two parts to the Risk Index calculation: data sensitivity level and user clearance level.

The calculation is essentially the difference between the highest level of document sensitivity and the lowest level of a user's granted access to documents. You do need to establish some arbitrary categories for sensitivity, such as public, private, and confidential. However, you can apply these categories to both the data in the system and to the people who have access to that data. Risk Index has nothing to do with group access privileges.

According to the National Computer Security Center (NCSC) "Yellow Book" publication, Risk Index is a mathematically-derived matrix determined by a simple function f(x) = x1 - x2. The parameters x1 and x2 assume values as determined by the corporate information policy: x1 is the highest document sensitivity and x2 is the lowest access sensitivity of any person on the system. You first ascribe a numerical value to each of the categories you establish in determining the sensitivity of the documents; for example, Public=0, Confidential=1, Proprietary=2. Then you determine maximum levels of document access for the people on the system. You do not have to actually impose this access control on anyone to determine the Risk Index; you simply have to know the difference. This allows the Risk Index to be readily calculated, while providing auditors and network security administartors with an excellent opportunity to gain insight into their corporate data structure.

What you end up with is an "apples to apples" comparison between how sensitive the material in your computer systems is (the most sensitive document or data), and how "clear" to access that material your people are. You simply look at the highest level of sensitivity any one document has, and the lowest clearance level of any person on the system. It doesn't matter whether they have access to the data via privileges. It only matters that they are on the system where the information resides. This is the actual information risk.

It is important to keep in mind that the Risk Index is derived from internal values surrounding data sensitivity. While determining the Risk Index allows for some flexibility in the interpretation of data sensitivity, there are several caveats you should be aware of if the results are to be meaningful:

  • Risk Index does not allow for broad or local interpretation by corporate finance policy, nor for redefinition to fit departmental objectives. Risk Index must be viewed in the context of the entire network.

  • Risk Index is not specific to a server or group of people given access to the information. If there is a connection over which information can flow, both nodes and users must be considered in determining the Risk Index.

Thus, the Risk Index is not a general assessment of security threats and vulnerabilities; it has specific implications to the business model and to the sustainable viability of that model. It deals entirely with the risk coming from users and the potential for disclosure, loss, or alteration of information.

Creating a Security Policy

While the Risk Index is an indicator of the corporate need for security, it relies heavily upon the policies of the corporation for guidance and direction. You cannot arbitrarily assign sensitivity to corporate documents without some guidance as to what is sensitive and what is not. This can become a real Catch-22 in companies without a security policy, and can be detrimental if implemented as a restrictive procedure in the business environment. To arrive at a corporate standard for sensitivity determination, both management and users must recognize and understand the need for corporate network security.

In most organizations, the first area needing clarification in determining a security policy is "Where do we need security?" However, in pursuing the answer to this question, it is easy to miss crucial points in information security. Often the question is answered with a location or department, such as Accounting or Human Resources, rather than by analyzing the data itself. Equally often, the solution imposed has little to do with the actual threat. For instance, imposing a cryptographic solution on the storage of sensitive files does not handle the actual risk of disclosure, loss, or alteration.

Here are some important points to keep in mind:

  • Organizations comprise many susceptible components, predominately people and systems.

  • Network administrators and auditors support different control objectives.

  • Since Risk Index deals with information at risk, it is best suited in developing a systems exposure. It can be juxtaposed with assurance level.

The Risk Index is thus a suitable metric for ascertaining the levels of assurance required from a specific system.

Recognizing Roles

Risk determination is considered a function of auditing, since corporate auditors can bring to light policy and criteria that affect the sensitivity of documents. However, the local network administrator may have more direct insight into a system's contents and the real sensitivity associated with that material.

Clearly, the two groups should work together to determine the Risk Index. Yet it must be recognized at the outset that each group has different concerns. Auditors and network administrators perform different functions within the organization. They work in different time frames. They usually work in different divisions and fulfill different roles. Although risk is a common area of concern shared by many people, there are perceptual differences in a risk assessment developed by an auditor and the Risk Index needed by a corporate network administrator. Risk Index gives the network systems administrator a clear indicator of the assurance levels needed on corporate information systems.

Risk analysis by itself is a broad topic, generally referring to identifying activities which could result in potential loss to the organization if information is disclosed, altered, or lost. In the large corporate setting, this topic is usually covered by corporate auditors and the financial staff. In this AppNote, however, we are taking a network point of view on evaluating the security risk to corporate data. This point of view is different in that it ascribes to the data some inherent characteristic which makes it worth attacking.

LAN and network system administrators in IS departments do not usually receive training as EDP auditors, nor in risk analysis. Consequently, while LAN and network administrators may be aware of the inherent security risks within the network configuration, they are not normally responsible for modifying the corporate infrastructure to handle those risks. Most often it is the auditors who prescribe corrective measures.

Corporate auditors may be familiar with the information contained within the network, including the access controls and audit procedures for the network operating system. However, few auditors have insight into how the corporate information stored on the network affects either the types of attacks system administrators may have to contend with, or the types of assurances the network operating systems should exhibit to protect against the disclosure or loss of that information.

Auditors who lack training in network security can be a divisive factor when they set out to work with network administrators. Some of this difficulty stems from the fact that auditors are expected to make recommendations, whereas administrators are expected to produce excellent security, often without the resources or training to evaluate their current situation. Even worse, upper management (audit, IS, and executive management) may feel that passwords and virus checkers are sufficient for network security. This is not the case in networks. The network administrators are thus unable to institute the requisite level of security.

Navigating Political Waters

Forming the Risk Index is one area where LAN and network administrators need to work closely with audit staffs in obtaining the required levels of security. Yet this area has proven to be one of the more difficult areas to navigate politically since it crosses the authority boundaries of different divisions in classical corporate structure. Joint responsibility and good navigation are imperative if corporate auditors and network administrators are to achieve their common goal of providing adequately secure information systems.

In the ideal situation, there would be no contention between divisions and authority domains. But whatever your situation, it helps to recognize the difference in the roles between corporate auditor and corporate systems administrator. While each of these corporate roles tackles the security problem from different perspectives, both are trying to raise productivity to a higher level with a minimum amount of end-user involvement (maximum transparency). In addition, corporate auditors look to achieve the requisite level of financial accountability. It is not easy to balance such seemingly mutually-exclusive goals as end-user transparency and accountability. This is why both the LAN administrator and the EDP auditor must work together to determine the Risk Index.

Working Together

In a simplistic solutions point of view, a small network administrator may not have to understand the implications of the Risk Index, although it might be helpful. In organizations where the LAN administrator is also the Information Services system administrator--small businesses included--understanding the Risk Index is absolutely essential. In fact, corporate auditors trying to evaluate risk often approach LAN administrators to discern which files and directories contain sensitive information. When this information is not available from LAN administrators, departmental managers and employees need to be consulted.

At issue for both network administrators and auditors is the actual security of their network. Yet LAN administrators and system administrators do not usually have the connections (or the clout) to gain the needed resources to implement secure network operating systems technology. Traditionally, gaining the resources and dollars to put together a secure network was the job of the corporate audit departments. The cooperation of corporate audit makes the acquisition of suitable assurance measures much easier. However, without fully understanding what protections are really needed as compared to the object sensitivity being protected, it is impossible for audit staff to assist or accurately plan network assurance needs. Even audit departments have difficulty getting management to spend money for corporation information security without clarity.

In the past, many of the largest companies have had to maintain "fortress" systems (mainframes) for their confidential corporate data and transactions. However, today LAN administrators have the ability to obtain secure network software right off the shelf. The Green River version of NetWare will be the first Class C2 commercial-off-the-shelf (COTS) network system available. Corporate auditors will need to evaluate this Green River release of NetWare to be aware of these new capabilities and the assurance it provides.

Also, network administrators and corporate information security officers must recognize the specific areas where risk can affect network security and the integrity of network audit files. Corporate auditors need these assurances. They may have to actually prove, in court, that the system does in fact operate the way it is supposed to. Thus a risk-evaluated operating system is an absolute necessity for corporate auditors. Audit file integrity is the issue. If the audit files are not safe from external modification, there is little point in performing an audit.

On the other hand, it is the network system administrator who will be expected to implement secure technology and provide enough testimonials from qualified individuals that the technologies have the protections needed. In the corporate process, LAN administrators must be concerned with the security of network data.

Analyzing Risk

We have established the need for LAN administrators to work well with corporate auditors if any real security-related changes are to occur. To do this, the two groups must discuss what the risk to information really is and how the implications affect data security. Positioning this discussion is important. From a network administration point of view, a risk evaluation is one of three components that are needed to establish an information security model for the corporation. These three major areas for network information security administration are referred to by the acronym ERA:

  • Environment

  • Risk

  • Assurance

Environment is the complete understanding of the network configuration and use in terms of connectivity, segments, data volumes, application software, bridges, and firewalls.

Information security risk (or data security) becomes important because it shows the real value of the security mechanisms and assurances.

Finally, it is only with assurance in the strength of the security mechanisms that the system administrator can hope to achieve security.

Topically, network information security is the relationship between the following:

  • End-users and the information they manipulate

  • The network environment

  • The security features and services

  • The security mechanism assurances for both services and features

These factors all contribute in one way or another to the discussion of ERA. There is no way to separate them and still address security in an operable system. Security is a "weakest link" technology, building in a hierarchical fashion from the bottom up. To implement any form of real security in a system, one must drill down from the topical discussion of ERA to the foundations of risk.

Threat and Vulnerability--the Basis for Risk

Traditionally, corporate risk assessment comprises an analysis of potential threats and vulnerabilities. EDP audit staffs look for both of these factors in corporate information systems. But before the needed protection can be provided, the roots of threat and vulnerability must be exposed.

Basically, threat can be related to reward, as illustrated in Figure 1. The greater the reward for penetrating a system or for exposing or modifying information, the greater the potential threat, as intruders look for any security weakness that can be exploited. There are several social theories on why this occurs, but for now, suffice it to say that it occurs.

Figure 1: As the reward for penetrating a system increases, so does the level of threat to that system.

Next is the concept of vulnerability, a difficult word to define clearly. Different vulnerabilities exist, and it can take some time to evaluate them. While vulnerability is composed of several different components, data disclosure or modification are the vulnerabilities which we will address here. As is the case with threat, vulnerability also increases as the potential reward for penetrating a system increases.

Figure 2 is a composite chart relating threat and vulnerability to risk. As you can see from this chart, risk increases with an increase in threat and vulnerability. If there is no vulnerability in the absolute sense, there is no risk for data disclosure or modification. However, in real situations, no vulnerability does not mean no risk. As applied to electronic systems, data modification is still a possibility.

Figure 2: Relationship between vulnerability, threat and risk.

There is a close relationship between vulnerability and exposure. Indeed, exposure might be a better word for conveying the meaning here, especially in getting agreement on common terms with corporate audit staffs. It is also helpful to consider how connectivity relates to exposure. The more connections you have, the greater the exposure to potential data disclosure or modification (including loss). Clearly, opportunity follows connectivity, as shown in Figure 3.

Figure 3: As connectivity increases, so does the vulnerability or exposure of the system.

Connectivity initially includes the wire to the workstation, and eventually encompasses the Internet connection of that workstation on the public network. Interestingly, opportunity contributes to vulnerability--especially where you do not recognize the vulnerability in exposure.

Risk increases whenever there is an increase in connectivity (environment) without a suitable modification in assurance. This has definite implications to the developmental life cycle of network security products in providing assurance, especially for future products. While these implications are outside the scope of this article, they are mentioned to show how much attention vendors such as Novell will have to give to security as connectivity increases.

Discussion Milestones

All of this makes interesting background for a discussion of vulnerability and risk with your audit staff, since they probably understand the practical aspects of discerning risk better than the network staff does. The trick is to avoid getting into a debate on what risk is. Your aim should be to relate to the auditors that you have specific system needs in the area of providing security assurance, specifically regarding the strength of protective mechanisms in the operating system when dealing with corporate data and users.

Along the road to a substantive discussion, you will want to set up several significant milestones to assist you in determining if corporate audit staff can assist you and if corporate audit is ready to address your needs. These might include the following:

  • Mutual understanding that the network administrator is not encroaching on audit territory and vice versa.

  • Explaining the network security criteria--that there are classes of available commercial software for networks which provide levels of assurance to fulfill different networking models.

  • A clear grasp of how the Class C2 evaluated operating system (NetWare Green River) provides assurance of audit trails.

  • Specific needs for corporate audit in obtaining assurance (at alevel of network security).

  • Information provided to auditors on the influence Risk Index has upon corporate configuration versus information security needs.

Once you discuss how to audit in NetWare Green River, you will be well on your way to getting your security needs established in what will hopefully be a non-confrontational setting. (Audit configuration will be discussed in future security-related AppNotes.)

One of the points you will be making in these conversations is the need for a level of assurance which can be related to the Risk Index. While this relation is not an immediate solution to the amount of security needed for any given system, it is the first step in providing levels of accountability upon which a secure model can be built.

Establishing Data Sensitivity and Access

There are several considerations pertaining to the establishment of data sensitivity when looking at records and data. Unfortunately, this is an area that has been commercially misinterpreted in the trade press over the past few years--sometimes as something you should not do, sometimes as a restrictive activity. It is therefore likely to be controversial, or at the very least subject to the different viewpoints of auditors and security officers.

To clarify some of these viewpoints, it is best to establish a common view of data sensitivity. Auditors establish data sensitivity as a means for determining the potential risk to the company due to information disclosure or modification. Interestingly, network administrators can use the Risk Index to determine how strong the operating system's services and features must be to prevent disclosure or modification. In this usage, system administrators are also determining a factor of potential risk to the company. However, each group uses sensitivity differently.

In the corporate world, data sensitivity might be established just by recognizing there are certain pieces of information you do not want other people to know about or have access to. Unfortunately, the tendency in policy-making discussions is to pile up restrictions until no one is allowed to see anything. This is one of the reasons why Risk Index is so often misunderstood.

In determining data sensitivity, there are several important points to consider:

  • Most businesses assume that employees can be trusted not to disclose internal materials.

  • Most businesses limit access to internal materials on a need-to-know basis.

  • Most businesses do not have systems security, staff, training, or resources to extend their data networks to allow external access by vendors, public, or employees to sensitive materials.

  • Most companies are embracing the Internet without understanding the ramifications of non-employees having public access to corporate networks.

Figure 4 illustrates how public and private information should be kept separate in a network.

Figure 4: Basic model for segregating public and private information on a network.

Historically, companies have employed vastly different methods to insure sensitive data against loss or disclosure. Thus, an understanding of the inherent value of a document or data if lost, disclosed or modified within the corporation is definitely open to some interpretation. However, there are two main points to be considered:

  • Look for structures that already exist. It is impractical to assign document sensitivities to every document in any good-sized company. Even under the best of situations, such an exercise would be very time consuming and less beneficial.

  • Verify that all sensitive information has already be isolated. For along time, companies have segregated sensitive materials away from public view. In the typical scenario, an information system containing sensitive information is physically isolated and can only be viewed by authorized individuals. It is a specific case of protection through isolation, a policy that assumes everyone has the same level of responsibility and need-to-know.

Much of the basis for establishing data sensitivity is already discernable from the structure of the organization. For example, some Human Resources (HR) data is legally considered private and not to be disclosed to the general user base. Thus most HR departments isolate personnel data. The same is true for payroll data. Both HR and Payroll have sensitive information, yet neither is sensitive enough that it would put the company out of business if it became widely known. This is a good example of inside information versus outsiders who do not have access to the information. However, it does not apply when there are external connections that allow outsiders access to the network.

As a second example, consider employee medical histories. There is no reason for the Payroll department to have access to this information. However, network connections often connect Payroll and HR departments directly. In the corporate context, disclosure of personnel information might make some people in the company uncomfortable, but in most cases it would not put the company out of business (provided it only occurred once). In the corporate context, then, access to personnel information by employees in the payroll department is viewed as necessary on a need-to-know basis. While this is sufficient for the business to operate, it does not address several of the privacy issues generated.

While the above examples cite special cases, they depict situations where the addition of public access to the network vastly increases the Risk Index. Inside the company, data is often segregated by location and file type. However, the simple connection of outsiders to the network can immediately raise the Risk Index without changing the data sensitivities.

This provides a good starting point for establishing a relationship between the security administrator and auditing staff. It is important to have an acceptable method for valuing information and for identifying users who have connections to the network. Isolating sensitive materials from exposure is hardly enough in the electronically-connected community. Changes with major ramifications to corporate risk can take place in an instant.

Classifying Data

Our choice for the next step has been to take a U.S. Government/ NCSC "Yellow Book" point of view regarding the implementation of a Risk Index. While we do not suggest that commercial users implement U.S. Government data sensitivity classifications, these classifications do provide a readily available example for network administrators and auditors to develop their own categories.

To determine data sensitivity, the U.S. Government uses an established method of classification. In this method, the lowest classification of information sensitivity is Unclassified (U). This simply means no one has looked at the data to classify it. It does not mean that the material is not worth looking at or that it is not sensitive. It simply means what it says: "not yet classed and categorized."

There are progressively higher levels of data sensitivity, from Unclassified up to Top Secret:

  • Unclassified (U)

  • N-data (N)

  • Confidential (C)

  • Secret (S)

  • Top Secret (TS)

These classifications have not only a symbolic representation but they also have a value level which can be represented as an integer (0, 1, 2, 3, 4), as shown in Figure 5.

Figure 5: The five basic U.S. Government classifications can be represented by integers.

Successively greater levels of sensitivity beyond Top Secret receive special category assignments of single-category (1C) and multi-category (MC). These require significantly different treatment to provide effective assurance of system security. This brings the total number of classification levels to seven (see Figure 6).

Figure 6: The addition of two special levels bring the total number of possible classifications to seven, numbered 0 through 6.

Relating Data Sensitivity to Your Categories

Most companies already have difficulty sorting and differentiating their data sensitivity. At first glance, it would appear that using a multi-level categorization method such as this would require significant effort. However, this does not need to be the case. While it is necessary to consider all system users in the design and development of computer operating systems, the five levels shown in Figure 5 (numbered 0 through 4) may be adequate for commercial purposes.

Unless a corporate auditor or system administrator works in an organization where the categories normally run up to Top Secret, there will likely be considerable resistance to implementing these U through TS classifications. Military categories like those depicted in the NCSC Yellow Book seem a bit, well, military when applied to the commercial sector. In most cases it is the choice of names, not the sensitivity definition itself, which causes this reaction.

Alternative category names such as "Public," "Company," and "Proprietary" might make more sense. For example, you could call data in the Unclassified category "public" data. You could also choose to define Public as a "general use" category.

Once you decide on your data sensitivity classifications, you simply build a table and assign integer values for the various levels. An example is shown in Figure 7.

Figure 7: An example of a four-level data sensitivity table.

From a numerical point of view, the values do not change--only the names for establishing sensitivity are different. If you can get people to agree that the name is better described by a number, real progress towards a Risk Index can occur.

The Users Component

The next part of the Risk Index involves the system users. If you have data sensitivity, there obviously must be be someone or something which the data is sensitive to. Therefore, we must expand our table of data sensitivity to include which users should be able to look at sensitive data. We use the same numerical scale to describe the users. An example is shown below.


DATA SENSITIVITY

USERS

0

1

2

3

4

5

6

7+

1

2

3

4

In this table, the top axis represents document or data sensitivity and the vertical axis represents all possible users, depicting their highest level of access to sensitive documents. The matrix formed between the two axes depicts all of the possible cases (that are allowed by the existing criteria) for access to sensitive materials. This chart is similar to the Security Risk Index Matrix from the NCSC "Yellow Book," which is depicted in Figure 8.

Figure 8: Security Risk Index Matrix from the NCSC Yellow Book.

Implicit to the NCSC chart is the derived risk--the Risk Index-- stemming from system users who have a lower access category than the highest sensitivity of information on the computer: Risk max- Risk min In this chart, the Risk Index formula has already been calculated through for | Risk max - Risk min | >= 0 These values are displayed as the matrix of the chart above. Zero value is represented in the bottom diagonal of the chart. A key observation in this Risk Index matrix lies in the first row, where risk escalates as the Unclassified viewer (employee or not) is placed on a system where higher levels of sensitive documents exist. While the NCSC chart shows the potential risk between information and users, the application of the user categories is often misunderstood when placed in a commercial setting. In the government specification, users are given clearances--Top Secret, Secret, and Confidential--to denote the type of information they may access. In the commercial sector, very little is done to determine the background of system users. In a military setting, information is usually passed between individuals who all belong to the same team, even if lower echelons are not told what is going on by the upper echelons. In the commercial sector, you are just as likely to be working with a member of some other group or team. In fact, you may be working with the competition on some projects. The U.S. Government does not work from an "us" and "them" approach--people inside the organization as opposed to people outside the organization. Their approach only includes people operating on the same system. Later, after the actual risk is determined, a policy model can be created which allows for interactivity.

A Reality Check

The NCSC chart indicates the risk of employees who are associated with sensitive network data. No mention is made about access controls in the form of permissions which might limit users with a class lower than the material in the data store. File and directory permissions do not really prevent sensitive information from disclosure. They are most appropriately used in a need-to-know environment where users operate at the same level as the most confidential material. This is a reality check for system administrators and auditors alike, because in most instances, employees are the people using company information. It is important for the people in the company to recognize that the data they incorporate into the system creates the computer information security risk, based on company-determined sensitivity gradations and the prescribed levels of access of the system users. People in the company will have to be realistic in deciding where the sensitivity demarcations really are. This has extensive implications with regard to the overall expense of obtaining the requisite level of security. For your company, it may be enough to recognize that there are some pieces of data you do not want some people to see. You may have conditions where you do not want certain information disclosed outside of the place where it is used. At the very least, you probably have a differentiation based on two distinct categories of users--us and them. However, your security needs may go beyond this simplistic distinction as you increase the connectivity of your network beyond employees who you might consider at the highest level.

Summary

This AppNote has introduced the Risk Index, a metric that indicates the degree of exposure a company may potentially incorporate into the system. Data sensitivity and users are the two components needed to determine the Risk Index. This metric provides the initial step in obtaining requisite levels of network security assurance. You have to know what you're up against in order to prepare for it. The prescriptive level of activity in this AppNote has been directed towards whichever entity is responsible for network security: the system administrator, LAN administrator, or corporate EDP auditor. Determining the Risk Index is only the first step to be taken. Once you have determined your Risk Index and identified the threats and vulnerabilities of your network, your options are to (1) increase operating system security assurance, (2) modify the environment in which the data is used, or (3) both. Implementing audit recommendations for access control permissions is different than implementing access controls on sensitive information. In either case, it is essential that you have a company policy model outlining sensitive information and what can be done with it. Fortunately, most of the work, study, and detail surrounding Risk Index and related concepts has been published by the National Computer Security Center. These volumes are available as bound or electronic text for administrators, developers, and implementers who would like to access it. To obtain copies, contact the NCSC at the following address: National Computer Security Center 9800 Savage Road Fort George G. Meade, MD 20755-6000

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates