In today’s environment, security is becoming an important organizational strategy. Physical security is effective, but one of the greatest risks organizations now face is software security. This risk occurs both internally (through employees) and externally (through communication lines and Internet processing).
Testing software system security is a complex and costly activity. Performing comprehensive security testing is generally not practical. What is practical is to establish a security baseline to determine the current level of security and to measure improvements.
Effectiveness of security testing can be improved by focusing on the points where security has the highest probability of being compromised. A testing tool that has proved effective in identifying these points is the penetration-point matrix. The security-testing process described in this chapter focuses primarily on developing the penetration-point matrix, as opposed to the detailed testing of those identified points.
This test process provides two resources: a security baseline and an identification of the points in an information system that have a high risk of being penetrated. Neither resource is statistically perfect, but both have proven to be highly reliable when used by individuals knowledgeable in the area that may be penetrated.
The penetration-point tool involves building a matrix. In one dimension are the activities that may need security controls; in the other dimension are potential points of penetration. Developers of the matrix assess the probability of penetration at various points in the software system at the points of intersection. By identifying the points with the highest probability of penetration, organizations gain insight as to where information systems risk penetration the most.
The objective of the security baseline is to determine the current level of security. The object of the penetration-point matrix is to enable organizations to focus security measures on the points of highest risk. Although no location or information system can be penetration-proof, focusing the majority of security resources on the high-risk points increases the probability of preventing or detecting penetration.
There are two major security concerns: Security risks must be identified, and adequate controls must be installed to minimize these risks.
This workbench assumes a team knowledgeable about the information system to be secured. This team must be knowledgeable about the following:
Communication networks in use
Who has access to those networks
Data or processes that require protection
Value of information or processes that require protection
Processing flow of the software system (so that points of data movement can be identified)
Security systems and concepts
Security-penetration methods
The workbench provides three tasks for building and using a penetration-point matrix (see Figure 20-1). The security-testing techniques used in this workbench are the security baseline and the penetration-point matrix. The prime purpose of the matrix is to focus discussion on high-risk points of potential penetration and to assist in determining which points require the most attention. These techniques can be used by project teams, special teams convened to identify security risks, or by quality assurance/quality-control personnel to assess the adequacy of security systems.
The input to this test process is a team that is knowledgeable about the information system to be protected and about how to achieve security for a software system. The reliability of the results will depend heavily on the knowledge of the individuals involved with the information system and the specific types of individuals who are likely to penetrate the system at risk points. The security-testing techniques presented in this chapter are simple enough that the team should not require prior training in the use of the security test tools.
A vulnerability is a weakness in an information system. It is the point at which software systems are easiest to penetrate. Understanding the vulnerabilities helps in designing security for information systems.
This section describes vulnerabilities that exist in the functional attributes of an information system. This section identifies the location of those vulnerabilities and distinguishes accidental from intentional losses.
The primary functional vulnerabilities result from weak or nonexistent controls in the following eight categories, listed in order of historic frequency of abuse:
Input/output data. The greatest vulnerability in this category occurs when access is most open. Data is subject to human interference both before it has been entered into a computer and after it has been output from the computer. Manual controls offer weaker resistance to people intent on interfering with data than do programs that must be manipulated to achieve unauthorized access. Input/output data controls include separation of data handling and conversion tasks, dual control of tasks, document counts, batch total checking, audit trails, protective storage, access restrictions, and labeling.
Physical access. When physical access is the primary vulnerability, nonemployees can gain access to computer facilities, and employees can gain access at unauthorized times and in unauthorized areas. Perpetrators’ access motives may include political, competitive, and financial gain. Financial gain can accrue through burglary, larceny, and the unauthorized sale of computer services. In some cases, disgruntled employees pose a risk. Physical access controls include door locks, intrusion alarms, physical-access line of sight, secure perimeter identification/establishment, badge systems, guard and automated monitoring functions (e.g., closed-circuit television), inspection of transported equipment and supplies, and staff sensitivity to intrusion. Violations often occur during nonworking hours when safeguards and staff are not present.
IT operations. In this category of functional vulnerability, losses result from sabotage, espionage, sale of services and data extracted from computer systems, unauthorized use of facilities for personal advantage, and direct financial gain from negotiable instruments in IT areas. Controls in this category include separation of operational staff tasks, dual control over sensitive functions, staff accountability, accounting of resources and services, threat monitoring, close supervision of operating staff, sensitivity briefings of staff, documentation of operational procedures, backup capabilities and resources, and recovery and contingency plans. The most common abuse problem in this functional category is the unauthorized use or sale of services and data. The next most common problem is sabotage perpetrated by disgruntled IT staff.
Test processes. A weakness or breakdown in a business test process can result in computer abuse perpetrated in the name of a business or government organization. The principal act is related more to corporate test processes or management decisions than to identifiable unauthorized acts of individuals using computers. These test processes and decisions result in deception, intimidation, unauthorized use of services or products, financial fraud, espionage, and sabotage in competitive situations. Controls include review of business test processes by company boards of directors or other senior-level management, audits, and effective regulatory and law enforcement.
Computer programs. Computer programs are subject to abuse. They can also be used as tools in the perpetration of abuse and are subject to unauthorized changes to perpetrate abusive acts. The abuses from unauthorized changes are the most common. Controls include labeling programs to identify ownership, formal development methods (including testing and quality assurance), separation of programming responsibilities in large program developments, dual control over sensitive parts of programs, accountability of programmers for the programs they produce, safe storage of programs and documentation, audit comparisons of operational programs with master copies, formal update and maintenance procedures, and establishment of program ownership.
Operating system access and integrity. These abuses involve the use of timesharing services. Frauds can occur as a result of discovering design weaknesses or by taking advantage of bugs or shortcuts introduced by programmers in the implementation of operating systems. The acts involve intentional searches for weaknesses in operating systems, unauthorized exploitation of weaknesses in operating systems, or the unauthorized exploitation of weaknesses discovered accidentally. Students committing vandalism, malicious mischief, or attempting to obtain free computer time have perpetrated most of the acts in university-run time-sharing services. Controls to eliminate weaknesses in operating system access include ensuring the integrity and security of the design of operating systems, imposing sufficient implementation methods and discipline, proving the integrity of implemented systems relative to complete and consistent specifications, and adopting rigorous maintenance procedures.
Impersonation. Unauthorized access to time-sharing services through impersonation can most easily be gained by obtaining secret passwords. Perpetrators learn passwords that are exposed accidentally through carelessness or administrative error, or they learn them by conning people into revealing their passwords or by guessing obvious combinations of characters and digits. It is suspected that this type of abuse is so common that few victims bother to report cases. Controls include effective passwords administration, periodic password changes, user protection of their passwords, policies that require hard-to-guess passwords, threat-monitoring or password-use analysis in timesharing systems, and rules that forbid the printing/display of passwords.
Media. Theft and destruction of digital data are acts attributed to weaknesses in the control of computer media. Many other cases, identified as operational procedure problems, involve the manipulation or copying of data. Controls include limited access to data libraries, safe storage of computer media, data labeling, location controls, number accounting, controls of degausser equipment, and backup capabilities.
The following list ranks the nine functional locations according to vulnerability:
Data- and report-preparation facilities. Vulnerable areas include key-to-disk, computer job setup, output control and distribution, data collection, and data transportation. Input and output areas associated with online remote terminals are excluded here.
Computer operations. All locations with computers in the immediate vicinity and rooms housing central computer systems are included in this category. Detached areas that contain peripheral equipment connected to computers by cable and computer hardware maintenance areas or offices are also included. Online remote terminals (connected by telephone circuits to computers) are excluded here.
Non-IT areas. Security risks also derive from business decisions in such non-IT areas as management, marketing, sales, and business offices; and primary abusive acts may originate from these areas.
Online terminal systems. The vulnerable functional areas are within online systems, where acts occur by execution of programmed instructions as generated by terminal commands.
Programming offices. This area includes office areas in which programmers produce and store program listings and documentation.
Handling areas for online data preparation and output reports. This category includes the same functions described in Chapter 10 for preparing online scripts.
Digital media storage facilities. This area includes data libraries and any storage place containing usable data.
Online operations. This category is the equivalent of the computer operations discussed previously, but involves the online terminal areas.
Central processors. These functional areas are within computer systems themselves, and abusive acts may originate from within the computer operating system (not from terminals).
Errors generally occur during labor-intensive work processes, and errors lead to vulnerabilities. The errors are usually data errors, computer program errors (bugs), and damage to equipment or supplies. Such errors often require jobs to be rerun, errors to be corrected, and equipment to be repaired or replaced.
Nevertheless, it is often difficult to distinguish between accidental loss and intentional loss. In fact, some reported intentional loss results because perpetrators have discovered and made use of errors that result in their favor. When loss occurs, employees and managers tend to blame the computer hardware first (to absolve themselves from blame and to pass the problem along to the vendor to solve). The problem is rarely a hardware error, but proof of this is usually required before searching elsewhere for the cause. The next most common area of suspicion is users or the source of data generation because, again, the IT department can blame another organization. Blame is usually next placed on the computer programming staff. Finally, when all other targets of blame have been exonerated, IT employees suspect their own work.
It is not uncommon to see informal meetings between computer operators, programmers, maintenance engineers, and users arguing over who should start looking for the cause of a loss. The thought that the loss was intentional is remote because they generally assume they function in a benign environment.
In many computer centers, employees do not understand the significant difference between accidental loss from errors and intentionally caused losses. Organizations using computers have been fighting accidental loss for 40 years, since the beginning of automated data processing. Solutions are well known and usually well applied relative to the degree of motivation and cost-effectiveness of controls. They anticipate, however, that the same controls used in similar ways also have an effect on people engaged in intentional acts that result in losses. They frequently fail to understand that they are dealing with an intelligent enemy who is using every skill, experience, and access capability to solve the problem or reach a goal. This presents a different kind of vulnerability, one that is much more challenging and that requires adequate safeguards and controls not yet fully developed or realized, let alone adequately applied.
This test process involves performing the following three tasks:
1. Establish a security baseline.
2. Build a penetration-point matrix.
3. Analyze the results of security testing.
A baseline is a snapshot of the organization’s security program at a certain time. The baseline is designed to answer two questions:
Baseline information should be collected by an independent assessment team; as much as possible, bias for or against a security program should be removed from the process. The process itself should measure both factual information about the program and the attitudes of the people involved in the program.
Two categories of the baseline information need to be collected. The first is related to the security process and includes the policies, methods, procedures, tools, and techniques used to protect computer resources. The second category of information relates to security acts and includes information about attempted and actual penetrations into computer resources. Wherever possible, actual losses should be quantified.
This task provides a five-step baseline procedure that includes data collection forms and suggested analyses of the data collected. Most organizations will want to customize this procedure based on their in-place security process, which may already have some of the needed information. Therefore, suggestions are offered on customizing the baseline procedure.
Industrial psychologists tell us that most individuals suffer from cognitive dissonance. This means that an individual is “blinded” by his own background and personal experiences. After surviving life’s experiences and performing different jobs and tasks, one comes to believe certain inalienable truths. When the mind becomes hardened with this cognitive dissonance, it is hard to convince an individual that other facts or positions may be more correct than the one held.
One noted security expert defines cognitive dissonance in a slightly different way. He says that there is a 20-year rule in almost all organizations (obviously not in those that have been in business less than 20 years). The rule is that if an unfavorable event has not occurred within the past 20 years, the probability of that even occurring is assumed to be zero by the key officers in the corporation. For example, if the business has not experienced a fire in the past 20 years, the fire procedures will be lax.
We see this 20-year rule vividly applied to the computer security field. Most organizations have not experienced a major computer disaster or fraud within the past 20 years, and thus tend to exclude it as a viable probability. When newspapers report a major computer disaster or problem (for example, hackers intrusions into well-known companies’ databases), senior management vicariously substitutes the reported event for a possible event in its organization. This “bends” the 20-year rule slightly, but normally the vicarious experience dissipates quickly and the 20-year rule again dominates management thinking. The net effect of this phenomenon is a widely held “it won’t happen here” philosophy.
When senior management adopts this thinking, logical arguments become useless. The only workable solution to cognitive dissonance is a factual presentation. In the area of computer security, this approach is a must.
This approach does not purport to claim to change managerial attitudes about the need for computer security. What the factual arguments do is “embarrass” people into changing behavior. The embarrassment results because they cannot intellectually refute the factual data, and thus they accept a position they may not truly believe in but are willing to undertake for the benefit of the organization.
The establishment of a security baseline need not be time-consuming. The objective is to collect what is easy to collect, and ignore the information that is difficult to collect. In many instances, the needed information may be already available.
The three key aspects of collecting computer security baseline information are as follows:
What to collect. A determination must be made about what specific pieces of information would be helpful in analyzing the current security program and in building a more effective computer security program.
From whom will the information be collected? Determining the source of information may be a more difficult task than determining what information should be collected. In some instances, the source will be current data collection mechanisms (if used by the organization). In other instances, individuals will be asked to provide information that has not previously been recorded.
The precision of the information collected. There is a tendency to want highly precise information, but in many instances it is not necessary. The desired precision should be both reasonable and economical. If people are being asked to identify past costs, high precision is unreasonable; and if the cost is large, it must be carefully weighed against the benefit of having highly precise information. In many instances, the same decisions would be made regardless of whether the precision was within plus or minus 1 percent, or within plus or minus 50 percent.
The collection of data to create a security baseline should be completed within one week. It may take longer in large organizations or if special programming is needed to gather information from computer logs.
This chapter proposes the following six-step baselining procedure:
Establish baseline team.
Set baseline requirements and objectives.
Design baseline data collection methods.
Train baseline participants.
Collect baseline data.
Analyze and report computer security status.
The baseline procedures described in this chapter are general in nature. They do not take into account any unique features of an organization or the fact that data may already be available. Therefore, the six-step procedure may need to be customized to ensure that the correct information is collected at the least cost.
If customizing the six-step procedure, keep the following in mind:
Availability of information. If data is already available, it should not be collected in the baseline study. Those pieces of information can be excluded from the six-step process and incorporated into the process in Step 5 (data collection step).
Need for information. The baseline team must establish the objectives of the baseline study. The information collected should support these baseline objectives. If recommended information is not needed to support an objective, it should be deleted (and vice versa).
Adjust for corporate language and nomenclature. Generalized terms may have been used in baseline collection forms. If so, these should be adapted to organizational terminology wherever possible. Customized terminology provides the appearance of a baseline process designed specifically for the organization. The more closely people identify with the questions, the greater the reliability of the data collected.
The baseline is presented as a one-time data collection procedure. Nevertheless, the data collected must be updated periodically to measure changes from the baseline. This follow-up data collection should be integrated into the security program, and not separated as a special data collection process in the future.
All processes need to be continually updated as business conditions change. The proper time to change processes depends on the collection and analysis of feedback information. This feedback information is the same information that was collected in the baseline study. Without this continual feedback and analysis, even the most effective security programs will fall into disrepair.
The selection of the baseline team is a critical step in the baselining process. Team members must exhibit the following characteristics:
Be representative of the groups involved in computer security
Believe they are responsible for the performance of the baseline study
Believe that the baseline study is a worthwhile exercise
Be responsible for using the results of the baseline study to improve security
The baseline study must belong to the individuals responsible for computer security and not to senior management. This does not mean that senior management does not participate in the baseline study or use the results of the study. It means that as much as possible the baseline will be owned by the people responsible for revising the computer security program.
This principle of ownership cannot be overemphasized in the computer security area. Most computer security programs fail because the employees of the organization do not believe it is their computer security program. They believe it is the program of the security officer, data processing management, senior management, or anybody but themselves. The emphasis in this book is that ownership and responsibility of the computer security belong to all employees of an organization. The concept of ownership begins with the selection of the computer security team. The recommended process for building the computer security team is relatively simple. Senior management convenes a group representative of all parties involved in computer security. In general, these should be the “movers and shakers” in the organization—the people who have the respect of the majority of the employees. These individuals may or may not be supervisors, but all must have the respect of the employees in the area from which they come.
Senior management now describes the importance and objectives of the baseline study. This presentation should be primarily a testimonial by senior management on the importance of computer security in the organization. The baseline study should be presented as a first step in establishing an effective computer security program for the organization. The presentation should not discuss the existing computer security program or identify or imply that the individuals associated with the current program have done less than an admirable job. The emphasis should be on changing requirements and the need to change and update the computer security program.
Senior management should then ask for volunteers to work on the computer security baseline study. Nobody should be appointed to this study group. If the individuals in the group do not believe in computer security, the results of the study will probably reflect that disbelief. On the other hand, if people volunteer, they must have an interest that can be nurtured by senior management to produce the kind of results desired. If senior management’s testimonial is believable, there will be sufficient volunteers for the study group. If there are no volunteers, then senior management must seriously reconsider its attitudes and practices on computer security. In that instance it may be better to hire a consultant to perform the study and then begin the new computer security program at the senior management level.
The goal of the initial meeting of the baseline team should be to establish the requirements and objectives of the baseline study. To a large degree, these requirements and objectives will have been established by senior management when the study team was formed. Nevertheless, for the requirements and objectives to be “owned” by the study team, the team must adopt those requirements and objectives as their own and not as orders dictated by management.
The objectives should be twofold: first, to collect information about the computer security process; and second, to collect information about the effectiveness of that process in detecting and preventing intrusions.
These two objectives must be converted into baseline requirements. The requirements should be defined in sufficient detail so that at the end of the baseline study it can be determined whether the baseline requirements have been met. It is these requirements that will motivate the remaining steps of the baseline process.
The baseline requirements must answer the who, what, when, where, why, and how of the baseline study; this information is then supplemented by the precision desired or achieved in the data collection process. The precision can be part of the requirements, or the respondents can be asked to state the level of precision they believe is in their responses.
The baseline requirements worksheet shown in Table 20-1 serves to record information regarding six focuses of concern, as follows:
Resources protection. Whenever possible, place a value on the resource that warrants security measures. The resources can be grouped; for example, the computer media library can be treated as one resource. It is not necessary to identify each reel of tape or each disk.
Resources used. Evaluate the number of people and the amount of computer time, security equipment, and other expenditures made for the sole purpose of providing security over the resources.
Methods. Describe in detail the tools, techniques, and processes used to protect the identified resources so that they are readily understandable by management. For example, a single reference to guards is inadequate; the methods to be described should explain the number of guards and their specific responsibilities.
Training. Define the programs used to train individuals in how to fulfill their security responsibilities, as well as the objectives, the methods used for training, and any procedures used to ensure that the necessary skills have been mastered.
Awareness. Record employee perception regarding the need for security, management’s security intent and specific responsibilities, and attitudes about the performance of security responsibilities.
Support. The support received from supervision and peers in performing security responsibilities includes being given adequate time, training, direction, and assistance where necessary.
The security violations should be available through existing reporting systems; if not, information in the following four areas must be collected:
Effectiveness. This involves the judgment of the individuals participating in the security program about the ability of the program to prevent and detect violations.
Penetrations prevented. Automated security systems log attempted violations, thus making this information easy to obtain. Manual security systems such as barriers may prevent a lot of people from penetrating, but unless the suspected offenders actually try and are observed, the information collected may not accurately reflect potential risk and efficacy of prevention.
Penetrations detected. This information should be recorded and reported by the individuals who detected the penetration (either through a formal reporting system or based on the recollection of those involved in the detection).
Losses. These are the losses to the organization that are the result of ineffective security systems. Computer security experts estimate that only about 10 percent of all losses are identified; therefore, this category might be divided into identified and estimated losses.
For all categories in the Baseline Requirements Work Sheet, the baseline team should provide guidance as to the following:
What should be collected.
Why the information is necessary.
Who has the information.
Where the information is available (For instance, the source of the information might not realize that she has the information within a database.)
Precision of information wanted.
How the information is to be provided.
The more complete the information at this point in the data collection process, the easier the remaining steps are to execute.
Ideally, the collection of feedback information about computer security should come from the process itself. Feedback information should be a by-product of the process, and not an extra task given to the individuals who perform security-related activities. For example, the scheduling or conducting of training should generate the information about training; forms required to record security violations should provide the information about violations; and job-accounting systems should indicate the amount of resources utilized to provide computer security.
The baseline study recognizes that the appropriate feedback mechanisms are not yet in place. The performance of the study is usually a one-time task, and as such, special data collection techniques need to be developed. Even so, these techniques should be commensurate with the value received from collecting the information. Two easy-to-use data collection forms are provided for the baseline study.
This Baseline Factual Data Collection form is designed to collect information that has a factual basis, as opposed to attitudinal information (see Figure 20-2). This does not mean that the factual information is 100 percent accurate, but rather that it is factual in nature as opposed to an individual’s opinion. However, both types of information are important because both affect the integrity of the security program.
Table 20-2. Baseline Factual Data Collection form.
Security Area (where)______________________________________________ | |||||
Individuals Responsible (who)________________________________________ | |||||
Resources Protected (why)__________________________________________ | |||||
______________________________________________ | |||||
______________________________________________ | |||||
Security Methods Used (what)_______________________________________ | |||||
Training Provided (what)____________________________________________ | |||||
Cost to Develop (what)_____________________________________________ | |||||
Cost to Use (how)_________________________________________________ | |||||
Number of Penetrations During Past 12 Months (why)______________________ | |||||
Prevented | ______________________________________________ | ||||
Detected | ______________________________________________ | ||||
Losses | ______________________________________________ | ||||
Description (how)_________________________________________________ | |||||
______________________________________________ | |||||
______________________________________________ | |||||
______________________________________________ | |||||
______________________________________________ | |||||
Accuracy (precision) | |||||
+/-5%___ | +/-15%___ | +/-25%___ | +/-50%___ | +/->50%___ | |
The factual information represents the areas of information defined in requirements (which are factual in nature). The information is collected according to areas of security. These can be organizational areas or areas of responsibility. The determination of what areas to survey will be based on an analysis of where computer security is conducted. At a minimum, it would include the following:
Central computer site(s)
Remote computer site(s)
Storage areas for computer media and resources
Points of physical protection
Communication lines or networks
Office equipment with security concerns
Origination of security concerns
This data collection form provides general categories of information wanted. The prototype has been designed to assist baseline study teams in developing a customized form for their organization. The end of the form provides space for the respondent to indicate the precision of the information included on the form. This may need to be qualified to indicate which piece of information is being rated. For example, training information may be provided at high precision, but the cost to develop the security measure may be provided at low precision. As stated earlier, the precision can be given by the baseline study team or provided by the respondent. If the baseline study team indicates the desired level of precision, this last item should be omitted from the form.
People’s attitudes about security are as important as the factual information gathered. People are the penetrators of security systems, and people are the guardians of the computer resources. If people are dedicated to computer security, it will happen; if they are not, the opportunity for penetration will increase.
The Baseline Attitudinal Data Collection form should be widely distributed throughout the organization (see Figure 20-3). Some organizations allow these forms to be returned anonymously because they think people will be more open if guaranteed anonymity. The baseline study team must make this judgment.
Table 20-3. Baseline Attitudinal Data Collection form.
Area of Responsibility (where)______________________________ | |
Individual Responsibility (who)_____________________________ | |
1. | I am responsible for the computer resources that I use and/or have under my control. |
Completely Agree 1___ 2___ 3___ 4___ 5___ 6___ Complete Disagree | |
2. | I have been adequately trained in the security procedures and policies of the organization, and my supervisor has verified that I have mastered these skills. |
Completely Agree 1___ 2___ 3___ 4___ 5___ 6___ Complete Disagree | |
3. | Security is an important part of my job function. |
Completely Agree 1___ 2___ 3___ 4___ 5___ 6___ Complete Disagree | |
4. | I am evaluated by my supervisor on how well I perform my security-related responsibilities. |
Completely Agree 1___ 2___ 3___ 4___ 5___ 6___ Complete Disagree | |
5. | Computer security is a high priority for senior management. |
Completely Agree 1___ 2___ 3___ 4___ 5___ 6___ Complete Disagree | |
6. | Computer security is a high priority for my supervisor. |
Completely Agree 1___ 2___ 3___ 4___ 5___ 6___ Complete Disagree | |
7. | I receive strong support from my supervisor when I request resources, raise concerns, or make recommendations relating to computer security. |
Completely Agree 1___ 2___ 3___ 4___ 5___ 6___ Complete Disagree | |
8. | The current security program is effective in detecting and/or preventing system penetrations. |
Completely Agree 1___ 2___ 3___ 4___ 5___ 6___ Complete Disagree | |
9. | The organization spends the correct amount of resources on computer security. |
Completely Agree 1___ 2___ 3___ 4___ 5___ 6___ Complete Disagree | |
10. | Management has requested my advice about computer security. |
Completely Agree 1___ 2___ 3___ 4___ 5___ 6___ Complete Disagree | |
To avoid fence-sitting, the questions on the form must be answered using a Likert scale. This form’s six-point scale requires respondents to select a response that is not average: The respondent must decide whether something is better than average or less than average.
The scale for each statement ranges from completely agree(a score of 1) to completely disagree(a score of 6). The more closely the respondent agrees with the statement, the closer he would score to a 1 (1, 2, and 3 are agreement options). The more he disagrees with the statement, the closer he would come to 6 (the disagree options are 4, 5, and 6).
The individuals administering the baseline study, as well as the individuals involved in providing that data, should be trained in what is expected from them. At a minimum, this training should include the following:
Baseline awareness. All of the individuals who will be participating in the program should be alerted to the fact that there is such a program in place and that they will be involved in it and are an important part of the success of the program.
Collection methods. The participants in the program should be trained in the sources of security information, how to get it, and the attributes of information that are wanted. This primarily will be an explanation of the information recorded on the baseline requirements worksheet (see Table 20-1).
Forms completion. If forms are distributed or used, the respondents to those forms should be instructed in the intent of the request for information, the type and extent of responses desired, and the type of precision needed.
The training is the responsibility of the chairman of the baseline study group. That individual should first train the study group, and then the study group should train the other participants.
The collection process should be performed as quickly as possible. When the requests are made, include a response due date on the request (generally, within three to five working days). This provides enough time to work the request into a normal schedule, and yet does not give the appearance that the request is unimportant.
It is recommended, but not required, that the requests be made at a meeting of the participants. This is an opportunity to train the people in the forms and at the same time to make the request to have the data collected. It is the responsibility of the baseline study group to follow up and ensure that the needed data is provided by the prescribed date. In the event that the data is collected from computer files, the baseline team may either personally perform those analyses or contract them out to other parties.
The analysis of the security self-assessment exercise resulted in a profile indicating the elements of security that presented the greatest threat. The analysis of the baseline will result in two more profiles: (1) factual information collected about security practices, and (2) attitudinal information from individuals involved in security. These analyses can be presented individually or as a single report. The approach selected should be based on experience as to how best to influence management decisions.
Let us consider a sample report of an analysis of the computer security baseline (presented in Table 20-2). This analysis shows the individual areas and selected analyses based on both the factual and attitudinal data collection processes. The areas of security listed are general, such as the central computer site. In actual practice, these should be specific organizational units.
Table 20-2. Report of Analysis of Computer Security Baseline
SECURITY AREA | TOTALS | CENTRAL COMPUTER SITE(S) | REMOTE COMPUTER SITE(S)/RESOURCES | STORAGE AREA FOR COMPUTER MEDIA | POINTS OF PHYSICAL PROTECTION | COMMUNICATION LINES/NETWORKS | OFFICE EQUIPMENT | LOCATIONS OF COMPUTER-PRODUCED DATA |
|---|---|---|---|---|---|---|---|---|
Value of computer resources | ||||||||
Cost to install security | ||||||||
Cost to operate security | ||||||||
Number of penetrations prevented | ||||||||
Number of penetrations detected | ||||||||
Value of security losses | ||||||||
Effectiveness of security | ||||||||
Management support for security |
The analyses selected show five factual areas (value of computer resources, cost to install security, cost to operate security, number of penetrations, and value of security losses) and two attitudinal areas, (effectiveness of security, and management support for security).
The translation from the data collection work sheets to this report may require some interpretation and further analysis. For example, the report suggests that a value be placed on the computer resources protected so that the cost of security can be shown in relationship to what is being protected. If the individual reports cannot quantify this, the baseline team must do it. The attitudinal analyses, such as effectiveness of security, are taken from the attitudinal data collection work sheets. In our work sheet, we had a rating classification of 1 to 6. These normally would have to be converted to terms that are more easily understandable. For example, if on the Likert scale the rating 1 represented ineffective security and 6 represented very effective security, the numbers might be converted to the following rating system:
Likert scale values of 1 and 2 are rated “poor.”
Likert scale values of 3 and 4 are rated “effective.”
Likert scale values of 5 and 6 are rated “excellent.”
A report of this type obviously requires explanatory material (in writing or orally). The purpose of showing a recommended analysis is to suggest a way of presenting the information. It is expected that the baseline team will use its creativity in putting together a baseline report.
The baseline is the starting point to a better security program. It both reports the status of the current program and provides a basic standard against which improvements can be measured.
The baseline study serves two primary objectives. First, it reduces computer security discussions from opinion to fact. Even though some of the facts are based on attitude, they are a statistical base of data on which analyses and discussion can be focused, as opposed to people’s opinion and prejudices. The baseline helps answer the question of whether the expenditure was worthwhile. For example, if a security software package is acquired but there is no way to determine whether the environment has been improved, management will wonder whether that expenditure was worthwhile. When the next computer security request is made, the uncertainty about the last expenditure may eliminate the probability of a new improvement.
A dilemma always exists as to where to place security. Earlier chapters stated that people are the problem, and therefore security should be placed over people. However, watching people is not a practical or desirable way to control people. Therefore, computer security is best achieved through controlling activities. The activities in turn control people.
For example, we want to stop people from removing computer media from the media library unless authorized to do so. This can best be accomplished by placing controls over the computer media in the form of a librarian; we can then exercise our security procedures through the computer media library and librarian.
This task identifies the activities that need control, as well as the data flow points where penetration is most likely to occur. These concepts are used to build a penetration-point matrix that helps identify security vulnerabilities for management action. The creation of the penetration-point matrix answers the question of where security is needed and whether security controls exist at the most likely points of penetration.
The computer security challenge in any organization is to control people—not just employees, but also vendors, customers, passers-by, and ex-employees.
The only effective way to control people is to continually monitor their activities. To control an individual, we would have to hire another individual to watch him first, and then hire a third individual to watch the second individual watching the first individual. Not only is this not practical, but it would be resented by a large percentage of employees and customers. Thus, another approach is needed to accomplish the same objective.
The solution to the computer security dilemma is to establish activities that control people. For example, it would be difficult to keep unauthorized individuals out of the computer center, unless a strategy such as card access control were initiated. Control designers refer to this concept as “division of responsibilities.” The activities that appropriately divide responsibilities also introduce the controls that monitor people’s activities on a continuous basis. The monitoring through activities is not considered objectionable, although constant surveillance would be.
The challenge is the identification of the appropriate activities. This is another critical step in building an effective security program. The number and types of activities selected for control are another aspect of determining the scope or magnitude of the security program in the organization.
The determination of the magnitude of the security program is based on the following two factors:
Type and magnitude of risks
Type and extent of security controls
The greater the risks, the greater the need for control. The two variables of the scope of the security program are directly related. One can measure the magnitude of the risks to determine the strength of the management security controls needed. The amount of management controls to be installed is also a measure of the scope of the security program.
The activities that require management security controls can be divided into the categories discussed in the following three subsections.
These are the activities and individuals that use computer resources. The specific activities relate to functions either needed by the computer environment or furnished by the computer environment:
Program users. Users are the operational “activities” for which the applications have been developed and for which the processing results are needed. The primary users of computer resources are the operational areas responsible for the application being processed. Secondary users include various staff units in the organization.
Technical interfaces. The operating environment includes many software packages (for example, operating systems, database management systems, and administrative scheduling systems). These individual packages need to be generated and installed; then the interfaces between the packages must be established. Many of the technical interfaces are performed by systems programmers and other specialists, such as database administrators.
Application systems. Application systems are the software packages that process user data to produce the results needed by the users. These application systems can be developed from internally generated specifications, acquired as commercially available software, or developed under contract by vendors. The activity includes testing to ensure that the application functions correctly, and then making any change necessary to ensure the operational efficacy.
Privileged users. Each organization has a group of users who by their stature in the organization are privileged. This means that they may not be subject to the same level of control as nonprivileged users. The two primary categories of privileged users are senior management and auditors.
Vendor interfaces. Organizations contract with a variety of vendors for special services. These include the vendors of hardware, software, and other support services such as maintenance, cleaning, and consulting services. In the performance of vendors’ duties, it may be necessary for vendor personnel to interact with computer operations during normal operating periods.
These are the activities that relate to the acquisition, creation, and maintenance of the software needed to accomplish the processing requirements established by users of computer facilities to meet business needs:
Policies, procedures, and standards. The organization develops policies regarding how a function is to be performed. These policies are implemented through procedures, such as system development methods by which work is performed. These standards can apply to both specific professional areas and other users of resources, such as microcomputer users.
Training. Training is key. People should be fully trained in how to perform their job and then supervised (and evaluated) to ensure that they have mastered those skills.
Database administration. Databases are groupings of data that are managed independently of the application programs that utilize the data. The creation of the databases requires a new organization structure to manage and administer the use of this new development. In many organizations, the database also includes the definition of data and the use of the data dictionary software documentation tool.
Communications. This activity encompasses the electronic movement of data between one computer facility and another. Modern communications facilities include the Internet, intranets, local-area networks, virtual private networks, and wireless systems. When common carrier facilities are used, the organization loses control over the security of information from the time it passes into the hands of the common carrier until it is again returned to the organization.
Documentation. Documentation (hard copy or electronic) includes all the narrative information developed and maintained about processing activities. For an application under development, documentation includes record definitions, system specifications, program listings, test conditions and results, operator manuals, user manuals, control documentation, flow charts, and other pictorial representations.
Program change control. The maintenance activity has the responsibility to define, implement, and test changes to application systems. Nevertheless, the control of those changes should be independent of the activity that actually performs the program maintenance. The program change control activity involves logging changes, monitoring their implementation, and verifying that all the changes to programs are appropriately authorized and that all authorized changes are made.
Records-retention program. This activity is designed both to retain needed computer-related documents and to appropriately destroy unneeded documents. Whereas the computer media is designed to physically store the data, the records-retention program relates to the amount of time that the information will be retained. The records-retention program includes both manual and computer media. The time and method by which data will be destroyed is an important part of the records-retention program. Many organizations either shred or burn key hard-copy computer documentation. In addition, some organizations have custodians to retain and control important records.
These are the procedures and methods used to process data on the computer using the software developed for that purpose as initiated by the activities that interface with the computer center. Activities also include supporting tasks necessary to ensure the integrity of the mainline operations:
Computer processing. This is the activity of processing data to produce desired results. Processing is used in this context to indicate the totality of steps performed between the initiation of a transaction and the final termination of that transaction. Processing includes both manual and automated functions that manipulate data.
Media libraries. Media libraries are repositories for computer media. The media libraries may be on-site, company facilities off-site, or with contractors who hold data at their site. Off-site libraries are used to protect data in the event of a disaster to the on-site media library.
Error handling. This activity begins when data is rejected from normal processing and continues until the time the problem has been resolved and the transaction has been correctly processed. Error handling normally involves a logging of errors and then a monitoring of the correction and reentry process. It is a particularly vulnerable point in many application systems because the reentry may only be subject to minimal control.
Production library control. The production library is the repository for computer programs and program-related parameters. For example, job control language statements are necessary to support programs, but are retained in libraries other than the production library. There are many libraries, but the emphasis in this activity is on control over those libraries that affect the integrity of computer processing.
Computer operations. These are the steps involved in ensuring that the desired results are achieved through computer processing. Operations involve terminal usage, support operations such as offline printers and office systems, and the central computer facility. Operations can also occur at off-site service centers.
Disaster planning. Disaster planning encompasses the retention of data for purposes other than normal operations, and all the procedures and methods needed to restore the integrity of operation in the event that it is lost. Because disasters can occur at any point of activity—for example, at a terminal operation—there may be many different activities included within the disaster plan. It is generally advisable to involve users in the development of the plan affecting their operations.
Privileged utilities and commands. Various aids are employed to assist the technicians, operators, and developers in the performance of their job responsibilities. Many of these utilities and aids are designed to circumvent the normal operation controls.
Organizations may want to divide their activities into different categories, or add other categories of activities subject to control. It is generally advisable to select activities that closely relate to the organizational structure of the company. For example, if the records-retention program and media library are under the same individual, it would not be necessary to break these into two distinct activities. On the other hand, the policies, procedures, and standards may involve several organizational units and therefore should be divided into two or more different activities.
The second dimension of the security program concerns controlling application processing. The activities are designed to support transaction processing. The primary objective of the data processing function is to process data (i.e. business transactions).
The security of transaction processing occurs at those points where there is transaction activity. Any time a transaction is originated, moved, stored, retrieved, or processed, it is subject to unauthorized and unintentional manipulation.
When developing security over transaction processing, it is important to identify the point where the transaction could be manipulated. These points are where the risk of manipulation is greatest and thus where control should be established. Most organizations refer to these as control points.
The ten control points in transaction processing are as follows:
Transaction origination. The creation of a business transaction through the normal conduct of business activities is the first opportunity for manipulation. An order received from a customer would originate the business transaction of filling a customer order.
Transaction authorization. It is management’s responsibility to ensure that transactions are only processed in accordance with the intent of management. The method by which this is achieved is to require transactions to be authorized prior to processing. In some instances, this requires a special authorization, such as signing a purchase order; in other instances, management has authorized a transaction if it meets predetermined criteria, such as an order from a customer whose credit has been approved by management.
Data entry. This process transcribes transactions onto computer media. In some instances, the transaction is both originated and authorized at the point where it is entered. Nevertheless, these are still three distinct control events to be performed.
Transaction communication. This control point relates to all the movement activities of transactions. Although shown as a single control point, it may be repeated several times during the life of a single transaction. For example, a transaction can be moved between the origination and authorization step, as well as from the output control point to the usage control point.
Transaction storage. This point involves placing transactions in a location to await further processing. Like communication, it is shown as a single control point but may occur several times in the transaction life cycle. For example, the paper document that originates the transaction may be stored in a file cabinet, whereas the electronic image of that transaction is stored in a database.
Transaction processing. Processing encompasses all mathematical and logical manipulations on data, as well as the updating of information stored in computer files. Processing can be automated (by computer) or manual by (by people).
Transaction retrieval. This control point involves the removal of transactions from storage. As with the storage function, this can be a manual storage cabinet or a computerized file. The removal can be the electronic image; in this case, the image is retained on file. There is also a form of retrieval in which no document or image is retained after the retrieval action is concluded.
Transaction preparation (output). This action involves the conversion of electronic media to a format usable by people. It may involve the display of a single transaction on a terminal, or it may involve the consolidation, summarization, and presentation of large volumes of transactions on reports. The content may be altered in this process; for example, state codes may be converted to the formal spelling of the state name.
Transaction usage. This involves actions taken on computer-produced results by either people or programs to meet user needs. Actions can range from doing nothing, which in many instances is a definitive action, to initiating a whole series of steps, for example, reordering products.
Transaction destruction. This final action on a transaction is the destruction of the transaction itself. In many instances, organization policy and/or the law specifies the time that a transaction must be retained before it can be destroyed. In other instances, the destruction of a transaction is up to the individual responsible for the transaction processing.
These ten control points represent the points at which transactions are vulnerable to penetration. If security is to be broken, it will be broken at one of these points. Invariably, the system will be penetrated at the weakest point.
There is a close relationship between the processing activities and the control points in transaction processing. The transactions are processed by the previously described activities. These activities either directly contribute to the processing (for example, the communication activity) or support the processes that carry out the transaction (for example, the program change control activity ensures that the programs that perform the processing are current with business requirements).
Many hundreds of years ago, the Chinese built a great wall around their entire civilization to protect themselves from penetrators. This was a costly and time-consuming exercise and in the end proved futile. The French tried the same tactic by building the Maginot line after World War I, only to find that the Germans went around these great fortifications, which in the end proved to be a useless defense.
A smarter strategy is to locate security defenses at the point where penetration could be the greatest. To select those points, we need to analyze the history of penetrations and develop hypotheses that tell us where our systems are most vulnerable.
We need to explore two premises to understand where penetration will occur. First, penetration will occur at the weakest point in transaction processing. Penetrations aimed at manipulating transaction processing will pick the weakest control point in the processing cycle for penetration. The term hacking means a continual probing to identify a weakness. Penetrators invariably hack until they find the weak point and then penetrate at that point. Therefore, if the weakest point in the cycle is strengthened, the effort required to penetrate the system increases. Each time the weak point is strengthened, the ante to play the penetration game goes up.
Second, penetration will occur in the least-controlled activity. The activity in which there is the greatest opportunity to manipulate is the activity that is most subject to manipulation. For example, if it is easiest to manipulate training, then that is the activity that will be used to penetrate the system. In one of the classic computer fraud cases, the head teller in a bank trained new tellers to ignore the warning messages that indicated unauthorized manipulation was occurring.
The two variables described in this chapter, control points and controllable activities, hold the key to determining where security is needed. If either a control point or an activity is weak, it needs to be strengthened; and if activities and control points that are related are both weak, the opportunity for penetration is even greater. By looking at these variables and showing the relationship, we can identify the point where the computer processes are most likely to be penetrated.
The Computer Security Penetration-Point Matrix is directed at data manipulation (see Table 20-3). It is not designed to identify all security threats. For example, natural disasters are a threat, but not a people threat. Disgruntled employees may wish to sabotage the computer center by destroying equipment; this is a threat to computer processing, but not a threat to transaction processing. On the other hand, most of the day-to-day security threats are data related and are identifiable through the use of the Computer Security Penetration-Point Matrix.
Table 20-3A. Computer Security Penetration-Point Matrix
USERS OF APPLICATION DATA AND PROGRAMS | TECHNICAL INTERFACE TO COMPUTER ENVIRONMENT | DEVELOPMENT AND MAINTENANCE OF APPLICATION SYSTEMS | PRIVILEGED USERS | VENDOR INTERFACES | POLICIES, PROCEDURES, AND STANDARDS | TRAINING | DATABASE ADMINISTRATION | COMMUNICATIONS | DOCUMENTATION | |
|---|---|---|---|---|---|---|---|---|---|---|
Transaction organization | ||||||||||
Transaction authorization | ||||||||||
Data entry | ||||||||||
Transaction communication | ||||||||||
Transaction storage | ||||||||||
Transaction processing | ||||||||||
Transaction retrieval | ||||||||||
Transaction preparation | ||||||||||
Transaction usage | ||||||||||
Transaction destruction | ||||||||||
Subtotal |
Table 20-3B. Computer Security Penetration-Point Matrix
PROGRAM CHANGE CONTROL | RECORDS RETENTION PROGRAM | COMPUTER PROCESSING | MEDIA LIBRARIES | ERROR HANDLING | PRODUCTION LIBRARY CONTROL | COMPUTER OPERATIONS | DISASTER PLANNING | PRIVILEGED UTILITIES AND COMMANDS | |
|---|---|---|---|---|---|---|---|---|---|
Transaction organization | |||||||||
Transaction authorization | |||||||||
Data entry | |||||||||
Transaction communication | |||||||||
Transaction storage | |||||||||
Transaction processing | |||||||||
Transaction retrieval | |||||||||
Transaction preparation | |||||||||
Transaction usage | |||||||||
Transaction destruction | |||||||||
Subtotal | |||||||||
Subtotal Table 20-3a | |||||||||
Total Score |
This matrix lists the 10 transaction control points in the vertical column and the 19 controllable activities in the horizontal column.
The matrix can be completed for each major business transaction. If the organization has a control design methodology, the insight gained from completing the form for the organization will suffice to identify the major penetration points. If each application is uniquely controlled, the matrix should be prepared for each transaction.
The matrix is completed control point by control point. The processing at each control point is viewed in relation to the activities that are involved in that processing. In most instances, many of the activities will be involved. Several questions need to be asked when looking at each activity. First, is there a high probability that this control point could be penetrated through this activity? For example, the first control point is transaction origination, and the first controllable activity is users of that application. The question then becomes: Do the users have a high probability of penetrating the point where the transaction is originated? If so, three points are allocated and recorded in the intersection of the lines from that control point and controllable activity.
If there is not a high probability of penetration, the question must be asked whether there is an average probability. If so, a score of 2 is put in the intersection between the control point and controllable activity. If there is a low probability, but still a probability, of penetration, then a score of 1 should be recorded in the matrix intersection. If there is no probability of penetration, or a minimal probability of penetration, a dash or zero should be put in the intersection. This procedure is continued until all the control points have been evaluated according to each of the 19 controllable activities.
The scores allocated for each intersection should be totaled vertically and horizontally. This will result in a minimum horizontal score of 0, and a maximum score of 57. The vertical scores will total a minimum of 0 and a maximum of 30. Circle the high scores in the vertical and horizontal Total columns. These will indicate the high-risk control points and the high-risk activities. Circle the intersections for which there are high scores for the transaction control point, and a high score for the controllable activity and either a two or three in the intersection between those high total scores.
The most probable penetration points should be listed in this order:
First priority is given to the intersection at which both the controllable activity and the control point represent high probabilities of penetration through high total scores. These are the points where there is the greatest risk of penetration.
Second priority is given to the high-risk controllable activities. The activities are general controls, which usually represent a greater risk than application control points.
Third priority is given to the high-risk control points as indicated by high total scores for the control point.
At the end of this exercise, management will have an indication of where security is needed most. Because security will be placed on activities and at transaction control points through activities, this identification process is important in determining the magnitude of the computer security program.
Software testers can analyze the results from testing computer security. This analysis provides a baseline and the points at which security most likely could be penetrated. If the testers have identified the controls at the penetration points, they will have most of the information needed to analyze the adequacy of security.
If software testers have a background in security, they will have uncovered a lot of information during their baseline exercise and while developing the penetration-point matrix. This additional information can prove helpful in analyzing.
Analysis of the following proves helpful in determining whether security is adequate for an information system:
Whether adequate controls exist at the points of highest probability of penetration
Whether controls exist at the points of most probable penetration
Adequacy of the controls to protect against penetration at the points of most probable penetration
Strengths and weaknesses identified in the baseline assessment
Risks for which there are no controls
Penetration points for which there are no controls
Because security is a highly specialized topic, software testers may need assistance in evaluating the adequacy of security in high-risk systems. If the data or assets controlled by the system pose minimal risk to the organization, software testers should be able to make a judgment regarding the adequacy of security controls.
To limit the amount of testing that must be done, complete one or all of the following three tests on the points with the highest probability of penetration. Fraud studies indicate that those points with the highest potential to penetrate are the ones where penetration is most likely to occur:
Evaluate the adequacy of security controls at identified points. The objective of this test is to evaluate whether the security controls in place are adequate to prevent or significantly deter penetration. The process is one of evaluating the magnitude of the risk and strength of controls. If the controls are perceived to be stronger than the magnitude of the risk, the probability of penetration at that point is significantly reduced. On the other hand, if the controls appear inadequate, testers could conclude that the identified point is of high risk.
Determine whether penetration can occur at identified point(s). In this test, testers actually try to penetrate the system at the identified point. For example, if it is the payroll system and testers are trying to determine whether invalid overtime can be entered into the payroll system, the testers attempt to do this. In fact, the testers would attempt to break security by actually doing it.
This type of test requires pre-approval by management. The testers must protect themselves so that they are not improperly accused of actually trying to penetrate the system. Also, if the system is actually penetrated at that point by the technique used by the testers, they stand to be among the potential perpetrators who might be investigated.
Determine whether penetration has actually occurred at this point. This test involves conducting an investigation to determine whether the system has actually been penetrated. For example, if improper overtime is the area of concern and the payroll clerks are the most likely perpetrators, testers investigate paid overtime to determine whether it was in fact properly authorized overtime.
Note
Software testers can create a penetration-point matrix. The testers may want to work with security experts and/or internal/external auditors when performing any or all of the three tests. The software testers can be helpful in this process, and also learn how auditors perform these types of tests.
The check procedures for this test process should focus on the completeness and competency of the team using the security baseline process and the penetration-point matrix, as well as the completeness of the list of potential perpetrators and potential points of penetration. The analysis should also be challenged.
Work Paper 20-1 contains questions to help check the completeness and correctness of the security test process. Yes responses indicate good control. No responses should result in challenging the completeness and correctness of the conclusions drawn from the matrix.
Table 20-1. Test Security Quality Control Checklist
YES | NO | N/A | COMMENTS | ||
1. | Has a team of three or more people been put together to prepare and use the penetration-point matrix? | ||||
2. | Is there a reasonable possibility that the team members can identify all the major potential perpetrators? | ||||
3. | Do the team members have knowledge of the location/information system under investigation? | ||||
4. | Is there a high probability that the team will identify all the major potential points of penetration? | ||||
5. | Will the team use a synergistic tool to facilitate brainstorming/discussion to identify potential perpetrators/penetration points? | ||||
6. | Does the prepared penetration-point matrix include the identified potential perpetrators and potential points of penetration? | ||||
7. | Has the team used appropriate synergistic tools to rate the probability that a given perpetrator will penetrate a specific point? | ||||
8. | Has every perpetrator and penetration point been analyzed? | ||||
9. | Has the accumulation of points been performed correctly? | ||||
10. | Have the high-risk penetration points been identified? | ||||
11. | Has there been a reasonable challenge that the identified high-risk points are in fact the high-risk points of penetration? |
The output from this test process is a security baseline, the penetration-point matrix identifying the high-risk points of penetration, and a security assessment.
You can use the penetration-point matrix in one of two ways:
It can be used to identify the people and the potential points of penetration so that an investigation can be undertaken to determine whether a particular location/information system has been penetrated.
It can be used to evaluate/build/improve the security system to minimize the risk of penetration at high-risk points.
This test process is designed to help software testers conduct tests on the adequacy of computer security. The process is built on two premises: First, extensive security testing is impractical; after all, practical security testing involves focusing on specific points of vulnerability. Second, software testers are most effective in identifying points of potential security weakness, but help may be needed in performing the actual security analysis.