Security
Fundamentals
CIS341 – Spring 2004
Attribution: This discussion is based on the book Fundamentals of Secure Computer Systems by
Brett Tjaden, Franklin, Beedle
& Associates. Direct quotes are in italic.
Basic
Terms
Security policy – a precise specification
of what types of actions are and are not permitted within an information
system. Ideally this is written, but
often much of it is defined by practice.
Secure system – an information system that always obeys the
existing security policy.
Security breach – a violation of the
security policy.
Restriction – a rule limiting what actions can and cannot
be taken within an information system.
Basic
Principles
Restrictiveness/Functionality
Tradeoff:
The
more restrictive the security policy, the less overall functionality the system
will have, and vice versa.
Restrictiveness/Security
Tradeoff:
The
more restrictive the security policy, the more secure the system will be, but
only if no security breaches occur; and vice versa.
Restrictiveness/Incident
Tradeoff:
The
less restrictive the security policy, the fewer security breaches it will have,
but at the cost of overall loss of security.
Discussion:
A
system with absolutely no restrictions will have no security breaches (by
definition). And there will be no limits
to its functionality, other than the physical limits of the hardware and
software of the system. But, it will
also be effectively insecure.
An absolutely restricted system will also
have no security breaches. No actions are
allowed, so no actions will be taken.
Therefore no security breaches will occur. But such a system will have no functionality
whatsoever.
The key to designing and implementing a
security policy is to strike a balance between these two extremes. That balance is expressed by these two
principles.
Policy Simplicity Principle:
System Functionality Principle:
Excercises:
1. What purpose is served by the Policy Simplicity Principle?
2. What purpose is served by the System Functionality Principle?
3. Give an example of a violation of the Policy Simplicity Principle?
4. Give an example of a violation of the System Functionality Principle?
5. A user must take great precautions when opening email
attachments. Which principle is being
violated? How? How would you redesign the software
product(s) involved to more closely adhere to this principle?
Policy Shortcomings:
Security breaches caused by policy shortcomings are most often due to an incomplete or inconsistent policy, a misunderstanding of the policy’s requirements, or an error in its implementation. [p. 2]
Software Shortcomings:
Many security problems can be attributed to software bugs that enable attackers to cause some part of the system to malfunction in a manner that compromised security. [p. 2]
Component Interaction Phenomenology:
[Phenomenology:
A description, history, or explanation of
phenomena.]
The
number of potential security problems associated with two interacting system
components is the multiple of the problems associated with each component
individually.
Two system components, which are secure in isolation, could interact in a dangerous fashion when used together. The more components a system has the more combinations of those components that exist, and reasoning about possible interactions between all possible combinations of features is extremely difficult. The complexity of computer systems and the limits on our ability to verify their software are constraints that computer scientists deal with regularly and few people expect us to overcome completely. In the realm of security, these constraints imply that few, if any useful systems will be absolutely secure. [p. 3]
Security Cost:
The
total hardware, software and personnel cost of the security aspects of an
information system.
Cost of Security Attack:
The
total cost of engineering and implementing a security breach.
Cost of Security Breach:
The cost to the owner of the information system of sustaining a
security breach.
Benefit of Security Breach:
The gain to the perpetrator of achieving a security breach.
Absolute Security:
The
goal is to design a system that has no security breaches whatsoever.
Relative Security:
The
goal is to design a system in which the benefit to the perpetrator of achieving
a security breach is clearly less than the cost to him or her.
Cost/Benefit Principle of Security Design:
A. Design the security system in such a way that the cost of achieving a
security breach clearly exceeds its benefit.
B. Design the security system in such a way that the cost to the owner of
the information system of sustaining a security breach is clearly less than the
cost of thwarting that breach. (This is
what Tjaden calls the Cost/Security Tradeoff).
Comment: In the real world, no simple formulas can be given. A hacker who hacks for glory willingly expends
costs far in excess of any tangible benefit gained. Also, the costs of achieving security may be
higher than a business or institution can bear, regardless of the loss incurred
if a security breach occurs. Thus, these
definitions and principles are useful to establish a context of discussion, but
must be adjusted in the specific case to the realities of the situation.
Increasing the amount of time and skill required to breach a system’s defenses decreases the pool of intruders who can successfully attack it. Increasing the odds (and penalties) of getting caught serves to dissuade many of those who possess the requisite time and skills from trying. Increasing the cost to intruders of mounting a successful attack further reduces their numbers. If the cost of attacking exceeds the expected payoff for a successful attack, then most intruders will seek out a more rewarding target. [pp. 3,4]
Excercises:
1. What are the advantages of the cost/benefit approach to security
design?
2. What are the disadvantages?
Give specific examples.
3. What is your overall assessment of C/B?
Problems with Cost/Benefit Approach:
1. Underestimating the cost of mounting a successful attack.
a. Unknown system vulnerabilities
which enable easy attack
i. System design errors
ii. System design
vulnerabilities
a. Trap doors or (back
doors)
A means of disabling a
system's security, by a hardware or software mechanism which is intentionally
hidden by designers of the system, often for the purpose of providing access to
service technicians or maintenance programmers.
b. Morris Internet worm
Perhaps the most famous UNIX back door was the DEBUG option of the sendmail program, exploited by the Internet worm program in November of 1988. The DEBUG option was added for debugging sendmail. Unfortunately, the DEBUG option also had a back door in it, which allowed remote access of the computer over the network without an initial login. The DEBUG option was accidentally left enabled in the version of the program that was distributed by Sun Microsystems, Digital Equipment Corporation, and others.
http://vmyths.com/hoax.cfm?id=213&page=3
http://www.snowplow.org/tom/worm/worm.html
http://dictionary.reference.com/search?q=back%20door
iii. Vendor software errors
b. Fallacious analysis of
system security
i. Incorrect human factors analysis (e.g., irate “VP” calls at
ii. Lack of awareness of
non-software backdoors
c. Mathematical
discoveries which provide new avenue of attack
i. Polish mathematicians lead way in breaking Enigma codes
ii. A breakthrough in
factorization of n=p*q would severely compromise RSA
2. Underestimating the benefit (to the perpetrator) of a security breach
3. Underestimating the determination of the attacker
a. Benefit to attacker is
greater than expected (see above)
b. Rationality (or lack
thereof) of attacker differs from that of the designer
4. Underestimating the potential loss to the owner of the information
system
a. Value of what is
protected is underestimated
b. Effects of security
breach are greater than expected
5. Overestimating the cost of security to the owner of the information
system
Summary:
1. Estimate of where bar should be set is too low (and therefore bar is
set too low)
a. From standpoint of attacks: Attacks more
vigorous than expected
b. From standpoint of
system: Assets more valuable than estimated
2. Estimate of where bar actually has been set are too high
a. Breach of security is
more easily accomplished than expected
Chief
Concerns
According
to Tjaden, the chief concerns of secure systems
relate to the system itself and to its users.
System-oriented concerns:
Protecting
the privacy, integrity and availability of the data.
Privacy:
Ensure
that access to given datum is limited to authorized entities. [p.
4]
Integrity:
Ensure
that access to given datum can be modified only by an authorized principal.
[p. 5]
Availability:
Ensure
that information will be accessible in a timely manner when it is needed.
[p. 5]
User-oriented concerns:
Authentication
and privacy.
Authentication:
Privacy:
A user’s desire to control what information the system collects and makes available to other users. [p. 5]
External
Factors
Compromised
security can be caused by factors external to the hardware/software of the
system. That is why in the M-A-S posting
an information system is defined as being comprised of hardware, software and
personnel. And personnel are not limited
to IT staff, but include all personnel who interact with the information
system. We discuss now problems that can
arise due to personnel.
System designers:
1. Flaws in the information system design.
Administrators:
1. Poorly designed security policy.
a. Too lax
b. Unnecessarily strict
(the Regal Eagle)
c. Unilaterally
formulated
d. Failure to understand
user community
i. Constraints & pressures on users
ii. Deadlines, schedules
and other necessities
iii. Differences between
various user communities
2. Poorly administered security policy.
a. Poorly trained staff
a. Lack of knowledge of
security policy
b. Lack of understanding
of implementation details
b. Inadequately informed
users.
i. Of security policy
ii. Of reasons for
security policy
c. Disconnect between
staff and users
IT Staff:
1. Ignorance of security policies.
2. Failure to carry out security policies.
Users:
1. Failure to make reasonable effort to understand security policy.
2. Disregard for security policy.
3. Failure to understand consequences of actions