ADMN641 Information Systems Management and Integration
Lesson 10 - Computer Security Threats: Evaluation and Mitigation
 
Quality is not an act. It is a habit. Aristotle 
 
There can be no doubt that the impact of computer security is growing. Certainly the IT manager should be aware of all the technical aspects of security including threats and countermeasures. But perhaps more importantly he/she should be able to evaluate what threats are most likely in their own organizational environment and be capable of  balancing the costs of security breaks against the cost of measures for combating those threats. This balancing act is known as risk assessment. The other primary concern of the IT manager is to insure that a thorough security audit is performed periodically. That audit would raise issues which may likely be overlooked because of system familiarity - i.e. the can't see the forest from the trees syndrome.
Source: Egan, J. Information Security Threats to Software Development, 1998.

Technical Aspects/ Threat Identification

Understanding all the technical aspects of computer and network security and privacy is large effort. There was a time in the history of computing, perhaps twenty years ago, when it was a part time concern. But now, at the turn of the millennium, quite simply you must be a specialist  to act effectively in this arena. If, as an IT manager, you do not have the budget to employ a full time specialist, you should minimally have a security specialist "on call". The IT consulting and outsourcing firms - companies such as EDS, AMS, Computer Sciences Corp. Boeing Computer Services, Lockheed Martin's EIS Division, and the "Big 6" accounting firms all provide these types of services. There are other firms who specialize in security only and who have grown significantly in the last 5 years because of the increase in connectivity especially associated with the internet. These firms include Trusted Information Systems, Vanguard Integrity Professionals, and Fisher International Systems.

At least in the software arena, the principal life cycle threats include malicious software, hacker intrusions, reverse engineering and software errors. As opposed to what is assumed as true, most serious security threats arise from within the organization, not from external sources. For example in an article by Egan1:

"Ken Thompson of AT&T Bell Labs has described  a  C-compiler Trojan Horse, in which a modification to the compiler caused the next recompilation of the UNIX login routine to place a trapdoor in the object code of login. This trapdoor could  permit any unauthorized user to gain access to the system. This trapdoor  would not be caught by code inspectors  because it would not appear in any source code. Mitch Kabay Director of Research at the National Computer Security Association, tells a story about how MCI in 1993 prosecuted one of its former software designers for putting  a “backdoor” into a system that enabled him to commit over three million dollars in fraud by capturing customer credit card numbers and using them in fraudulent transactions. In another story, a Dutch chemical firm used  a software system to control the mixture of chemicals through the use of computer-controlled codes. A certain combination of codes -thought to be prohibited by the system-created a unstable mixture causing an explosion which killed several people."
The Computer Security Institute in a 1998 study listed the percentages of organizations having problems with different types of security breaches:
 
BREACH %
Virus 74
Unauthorized Access 39
Service Denial 22
System Penetration 21
Data Theft 16
Telecomm Fraud 14
Sabotage 13
Financial Fraud 13
Eavesdropping 9
Wiretapping 1
Source:Computer Security Institute

Keeping up with the possible computer security threats is not a task for most IT shops. But it is the sole function of several government and University centers. The Computer Security Division (893) is one of eight divisions within NIST's  Information Technology Laboratory. It has a section, The Computer Security Resource Clearinghouse (CSRC) whose tasking is to collect and disseminate computer security information and resources to help users, systems administrators, managers, and security professionals better protect their data and systems. They publish a wide variety of information on topics such as encryption, testing, viruses, and emerging technology. An example is the Internet Policy Security Guide which contains tips on such topics as Risk Profiling, Profile Matrixes, Information Asset Inventory, Internet Firewall Policy, and other Resources for Internet Security. This NIST division is also responsible for The Federal Computer Incident Response Capability . This group of government and University researchers track down and find antidotes for viruses and other maladies.

Evaluation

Evaluating what threats are most relevant to a specific organization and what measures are best applied to those threats is a tasking which can only be performed by the specific organization. Nonetheless, there are obviously common threats which can be identified and for which countermeasures are likely already available. The Common Criteria Project , which operates as an international group, is an effort to identify some common themes and to create measures for identifying the efficacy of countermeasures - i.e. typically commercially available products. Their top level theme is shown below.

Source: Common Criteria for IT Security Evaluation, ISO, 1998.

As it is outlined in their literature:

"The CC will be used as the basis for evaluation of the security properties of IT products and systems. By using such a common criteria base, a wider audience may find the results of an IT security evaluation meaningful. The CC permits comparability among the results of independent security evaluations. It does so by providing a common set of requirements for the security functions of IT products and systems and the assurance measures applied to them during a security evaluation."
The CC provides a series of requirements in areas including communication non repudiation, cryptography, access control, authentication, rollback and recovery, trusted channeling, flow control, and privacy.
 

Risk Assessment

Risk assessment is often though as technical subject. It may be viewed very technically if large data sets are available for analysis. Most frequently however, few or no data sets are available which provide necessary data such as frequently of security breaches, damage assessment, and risk profiling. Just how the term "Acceptable Range of Risk" is defined is typically a very subjective call. It is very different for the Central Intelligence Agency than for Lowes Theaters. Therefore risk assessment frequently is a matter of measuring management's attitude toward risk. But just how do we measure that risk? Two very different approaches are outlined below. The first is a whole organization approach using a system dynamics tool. The second is a specific case by case analysis using a decision support mechanism.

  Source: Egan, J. Information Security Threats to Software Development, 1998.

An Integrated Security Risk Model

There is a tendency to look at security in a "incident" mode. A virus attacks - let's kill it. This is equivalent to treating symptoms versus root causes. For an organization to stay healthy in the security realm, security policy should be looked at holistically. To help the IT manager better understand this approach Sturges and Winch2 put together an integrated security policy model. This business model contains all the elements of an organization - customers, finance/accounting, personnel, technology, and
potential security threats. It allows a user to play through multiple business cycles and allocate funds and personnel for security mitigation. It randomly interjects security threats such as the theft of computer chips, damage to data bases, viruses, and other specific attacks to an organizations information base. If adequate protection is in place, the threats may be thwarted. If protection is not in place damage is done.

It is possible to place significant security measures in place to thwart virtually all attacks. But is it practical or realistic to spend 50% of the IT budget to accomplish this goal? For 99% of organizations the answer is NO! Therefore, as we have studied earlier the issue is how to best balance measures against funds available. How much protection is sufficient for the organization? What level of risk will the organization assume? A formal risk assessment is necessary to understand and balance the risks.

Portions of the Sturges and Winch model are highlighted below to demonstrate both the breadth and depth of the model. Refer back to The Technology of System Dynamics  to review the symbology used.

The first diagram below is a snapshot view of the effects of a intruder attack on a file server - bringing it down. As with any organization there is extensive use of the server. Having it down would affect the processing of accounts, admissions, secretarial work, registration and enrollment. Those areas being down would affect the student flow. Student flow would affect the incoming dollars. Reduction in incoming dollars would affect quality of IT purchases, which would then affect the ability to serve and protect the information assets. It is a potential downward spiral.

You can see from the diagram below how the same attack could affect rework in prospectus reviews, application reviews and vetted applications. This ultimately would affect places offered and enrollments.

Such a model as the above requires considerable hard work in extracting an understanding of a system's processes. But the benefits can be exceptional. The model provides not only a better understanding of the overall system and how one area impacts another, but also upon the delays involved in the receipt of those affects.

Assessing the Risk Exposure at Security Budget Levels

The following evaluation model (using Expert Choice - discussed in lesson 8) typifies how a manager may wish to provide a framework for assessing risk. This is a high level model for identifying the portion of a budget which should be allocated toward security. The same approach could be utilized for selecting specific measures or for doing a benchmark analysis of an organizations security profile.

This diagram shows the overall goal of the model, along with criteria that may be utilized for selecting a funding level. They include openness of the computing environment,  trustworthiness of the organization's employees, the % of the IT budget of the overall organizational budget, and finally the extent of the effort to recover should security breaks occur. Finally on the bottom the specific funding levels are identified - .1(10%), .2 (20%), or .3 (30%) of the entire IT budget. This particular model places  .434 or about 43% of the weight of the model on the impact of the overall IT budget, with about 25% on system openness and 23% on recovery. This scenario would seem most probable for an organization which has significant resources in IT, but also possesses very trustworthy personnel (therefore not much weight needs to be given to "testing the veracity"  of  personnel). Keep in mind that these weights would be generated by a knowledgeable manager, utilizing his/her skills and experience in the context of an understanding of the organization.
 

 
The specific evaluation methodology is performed by comparing the criteria on each level of the above structure. The diagram below demonstrates this comparison in a snapshot view. In this particular case the evaluator is judging that a larger security budget (30% of the total IT budget) would provide a greater level of security (.72) in an environment which has High Openness versus a security level of only (.216) with a lesser security budget (20%) and almost none (.064) with a low security budget (10%).


 
This modeling capability provides the manager with the ability to do sensitivity analysis - i.e. what if the open nature of our organization changes, or what if the IT budget percentage is reduced in relation to the overall organization budget. A snapshot view of this analysis is provided below.


 
 

References:

1. Egan, John. Information Security Threats to Software Development, Information Resources Management College Report. 1998.

2. Sturges, S. and Winch, G. "Computer Attack: The Role of Modeling in Developing an Integrated Security Policy." International System Dynamics Conference Proceedings. 1996.



Assignments (due by midnight, Saturday, 04/01/2000):
 
No discussion assignment this week. Students writing research project papers now have two week left to complete the research and paper.
Organization Analysis Paper Track -  Task :
Complete the section of your paper which looks at Life Cycle Methodologies.
 
 
 
(c) John H. Saunders 1999. Permission granted for use in courses at the University of Maryland 1999.