Beruflich Dokumente
Kultur Dokumente
With the introduction of the computer, the need for automated tools for protecting the
files and other information stored on the computer became evident. This is especially the
case for a shared system as like internet. Thus, computer security is the generic name for
the collection of tools designed to protect data and to prevent hackers.
Confidentiality:
Integrity:
1
Integrity mechanisms fall into two classes; prevention mechanisms and detection
mechanisms. Prevention mechanisms are responsible to maintain the integrity of data by
blocking any unauthorized attempts to change the data or any attempts to change data in
unauthorized ways. While detection mechanisms; rather than preventing the violations of
integrity; they simply analyze the datas integrity is no longer trustworthy. Such
mechanisms may analyze the system events or the data itself to see if required constraints
still hold.
Availability:
2
Threats:
A threat to a computing system is a set of circumstances that has the potential to cause
loss or harm. It is a potential violation of security, means that it is a possible danger that
might exploit vulnerability.
Attack is an assault on system security that derives from an intelligent threat, i.e. attack is
an intelligent act that is an intentional attempt to evade security services and violate the
security policy of a system.
3
Spoofing / Masquerading- It is an impersonation of one entity by another. E.g.: if a user
tries to log into a computer across the internet but instead reaches another computer that
claims to be the desired one, the user has been spoofed. Delegation is basically authorized
spoofing. The difference is that the ones to which authority is delegated does not
impersonate the delegator; he/she simply asserts authority to act as an agent for the
Denial of receipt- A false denial that an entity received some message or information, is a
form of deception.
Denial of service- It is an infinite delay i.e., a long term inhibition of service. E.g., an
entity may suppress all messages directed to a particular destination. Another form of
service denial is the disruption of an entire network, either by disabling the network or by
overloading it with messages so as to degrade the performance.
Security Policy:
4
To prescribe mechanisms that help identify and prevent the compromise of
information security and the misuse of data, applications, networks and computer
systems.
To define mechanisms that protect the reputation of the organization and allow
the organization to satisfy its legal and ethical responsibilities with regard to its
networks' and computer systems' connectivity to worldwide networks.
To prescribe an effective mechanism for responding to external complaints and
queries about real or perceived non-compliance with this policy.
2. It must be enforceable with security tools, where appropriate, and with sanctions,
where actual prevention is not technically feasible.
3. It must clearly define the areas of responsibility for the users, administrators, and
management.
Confidentiality: Let X be a set of entities and let I be some information. Then I has the
property of confidentiality with respect to X if no member of X can obtain information
about I. Confidentiality implies that information must not be disclosed to some set of
entities. It may be disclosed to others. The membership of set X is often implicit for
example, when we speak of a document that is confidential. Some entity has access to the
document. All entities not authorized to have such access make up the set X.
Integrity: Let X be a set of entities and let I be some information or a resource. Then I
has the property of integrity with respect to X if all members of X trust I. In addition to
trusting the information itself, the members of X also trust that the conveyance and
storage of I do not change the information or its trustworthiness (this aspect is sometimes
5
called data integrity). If I is information about the origin of something, or about an
identity, the members of X trust that the information is correct and unchanged (this aspect
is sometimes called origin integrity or, more commonly, authentication). Also, I may be a
resource rather than information. In that case, integrity means that the resource functions
correctly (meeting its specifications). This aspect is called assurance. As with
confidentiality, the membership of X is often implicit.
Availability: Let X be a set of entities and let I be a resource. Then I has the property of
availability with respect to X if all members of X can access I. The exact definition of
"access" varies upon the needs of the members of X, the nature of the resource, and the
use of the resource. If a book-selling server takes up to 1 hour to service a purchase
request, that may meet the client's requirements for "availability." If a server of medical
information takes up to 1 hour to service an anesthetic allergy information request, that
will not meet an emergency room's requirements for "availability."
Security Mechanism:
- Technical mechanism enforces the policy inside the system. For example, mechanism
that enables a password to authenticate user before using the computer.
6
- Procedural mechanism enforces the policy outside the system. For example, mechanism
that sensor's a disk containing a game program obtained from an unreliable source.
Consider a scenario; suppose a universitys computer lab has a policy that prohibits any
student from copying another students homework files. The computer system provides
mechanisms for preventing others from reading a users file. Suppose, Anna fails to use
these mechanisms to protect her homework files, and Bill copies them. A breach of
security has occurred, because Bill has violated the security policy. If the policy said
students has to read-protect their homework files, then Anna did breach security, as she
didnt do this.
Example: In the preceding example, the policy is the statement that no student may copy
another student's homework. One mechanism is the file access controls; if the second
student had set permissions to prevent the first student from reading the file containing
her homework, the first student could not have copied that file.
Security policies are often implicit rather than explicit. This causes confusion, especially
when the policy is defined in terms of the mechanisms. This definition may be
ambiguous - for e.g., if some mechanisms prevent a specific action and others allow it.
Such policies lead to confusion, and sites should avoid them.
The difference between a policy and an abstract description of that policy is crucial to the
analysis that follows. A security model is a model that represents a particular policy or set
of policies. A model abstracts details relevant for analysis. Analyses rarely discuss
particular policies; they usually focus on specific characteristics of policies, because
many policies exhibit these characteristics; and the more policies with those
characteristics, the more useful the analysis. There is a result that says no single
nontrivial analysis can cover all policies, but restricting the class of security policies
sufficiently allows meaningful analysis of that class of policies.
7
Goals of Security:
Prevention is to prevent the attackers from violating security policy. Prevention means
that an attack will fail. Typically, prevention involves implementation of mechanisms
that users can not override and that are trusted to be implemented in a correct ways so
that the attacker can't defeat the mechanism by changing it.
Recovery is to stop attack and to assess and repair any damage caused by attack. With
recovery, it should be such that the system continues to function correctly, possibly after
a period during which it fails to function correctly, due to attacks.
For example if the attacker deletes a file, one recovery mechanism is to restore the file
from backup tapes.
Protection State:
The state of a system at any instance is defined by the collection of the current values of
all memory locations, all secondary storage, and all registers and other components of the
system. The subset of this collection that deals with protection defines the protection state
of the system. Access control matrix model is the most precise model used to describe a
protection state.
8
subset Q. Any operations like reading, writing, altering and execution of data or
instruction cause the change in state of the system i.e., state transition occurs. We are
concerned with only those state transitions that will lead to the authorized states.
Access to protected information must be restricted to people who are authorized to access
the information. The computer programs, and in many cases the computers that process
the information, must also be authorized. This requires that mechanisms be in place to
control the access to protected information
Access control matrix model is the simplest framework for describing a protection
system. It defines the right of users over files in matrix.
- Set of objects O; the set of all protected entities that are relevant to the protection
state.
- Set of subjects S; set of active objects such as processes and users
Now the access control matrix model designated by a matrix A defines the relationship
between these entities with the rights drawn from a set of rights R in each entry of as, o ,
where s S , o O , and as, o R . The subject s has a set of rights as, o over the
object o. The set of protection states of the system is represented by the triple (S, O, A)
For example:
9
Access Control List(ACL)
Access Control List is the easier way to represent access control matrix and it is most
commonly used implementation of access control matrix. The ACL permits any given
user to be allowed or disallowed access to any object. The columns of an ACL show a list
of users attached to protected objects. One can associate access rights for individuals and
resources directly with each object.
All security policies and mechanisms rest on assumptions specific to the type of security
and the environment in which it is to be employed.
As policies are to define the issue of security, they have to define security correctly for
the particular site. For example, a web site has to be available, but if the security policy
does not mention availability, the definition of security is inappropriate for the site. Also,
a policy may not specify whether a particular state is secure or non-secure. This
ambiguity causes problems. Hence proper assumptions should be made before defining a
concrete policy.
10
The security mechanisms may be secure, precise, or broad. Let P defines set of all
possible states.
Assurance:
Assurance is a measure of how well the system meets its requirements; more informally,
how much we can trust the system to do what it is supposed to do. It does not say what
the system is to do; rather, it only covers how well the system does it. System
specification, design and implementation can provide a basis for determining how
much to trust a system. This aspect of trust is the assurance. It is an attempt to provide a
basis for supporting how much one can trust a system.
11
Specification is a statement of the desired functioning of the system. Specifications arise
from requirements analysis, in which the goals of the system are determined. The
specification says what are the requirements and what the system must do to meet those
requirements. It is a statement of functionality, not assurance, and can be very formal
(mathematical) or informal (natural language). The specification can be high-level or
low-level (for example, describing what the system as a whole is to do vs. what specific
modules of code are to do).
Design architects the system to meet the specifications. The design of a system translates
the specification into the components that will implement them. The design is said to
satisfy the specification if the design will not permit the system to violate those
predefined specifications.
Typically, the design is layered by breaking the system into abstractions, and then
refining the abstractions as we work our way down to the hardware. An analyst also must
show whether the design matches specifications or not.
Implementation is the actual coding of the modules and software components. These
must be correct (perform as specified), and their aggregation must satisfy the design.
Thus, implementation creates a system that satisfies the design. This leads that
implementation will also satisfy the specifications.
Security does not end when the system is completed. Its operation affects security. A
secure system can be breached by improper operation (for example, when accounts
with no passwords are created). The problem is how to assess the effect of operational
issues on security.
Cost-Benefit Analysis: This weighs the cost of protecting data and resources with the
costs associated with losing the data. If the data or resources cost less, or are of less
value, than their protection, adding security mechanisms and procedures is not cost-
12
effective because the data or resources can be reconstructed more cheaply than the
protections themselves.
Similarly other considerations are the overlap of mechanisms effects (one mechanism
may protect multiple services, so its cost is amortized), the non-technical aspects of the
mechanism (will it be impossible to enforce), and the ease of use (if a mechanism is too
cumbersome, it may cost more to retrofit a decent user interface than the benefits would
warrant).
Risk Analysis: Risks are events or conditions that may occur, and whose occurrence, if it
does take place, has a harmful or negative effect. A risk analysis involves identifying the
most probable threats to a system and analyzing the related vulnerabilities of the system
to these threats. The risk analysis also should determine the impact of each type of
potential threat on various functions or units within the system.
What happens if the data and resources are compromised? This tells us what we need to
protect and to what level. Cost-benefit analyses help determine the risk here, but there
may be other metrics involved (such as customs).
Laws and Customs: These constrain what you can do. E.g. Encryption use can be
unlawful. Laws restrict the availability and use of technology and affect procedural
controls. Hence any policy and any selection of mechanisms must take into account legal
considerations. Customs involve non-legislated things, like the all the employees are to
provide their DNA samples in a company for authentication purpose. That is legal for the
company, but it is not socially acceptable, as an alternative to a password. Thus
society/customs distinguish between legal and acceptable practices.
Organizational Problems:
13
With the organizational problems, the question is of who is responsible for security. The
key here is that those responsible for security have the power to enforce security.
Otherwise there is confusion, and the architects need not worry if the system is secure
because they wont be blamed if someone gets in. This arises when system
administrators, for example, are responsible for security, but only security officers can
make the rules. Preventing this problem (power without responsibility or vice versa) is
tricky and requires capable management. Whats worse is that security is not a direct
financial incentive for most companies because it doesnt bring in revenue. It merely
prevents the loss of revenue obtained from other sources.
People problems:
People problems are by far the main source of security problems. Outsiders are attackers
from without the organization; insiders are people who have authorized access to the
system and, possibly, are authorized to access data and resources, but use the data or
resources in unauthorized ways. It is speculated that insiders account for 80-90% of all
security problems, but the studies generally do not disclose their methodology in detail,
so it is hard to know how accurate they are. Social engineering, or two-faced, is quite
effective, especially if the people gulled are inexperienced in security (possibly because
they are new, or because they are tired).
Policy
Specification
Design
14
Implementation
The considerations discussed till now appear to flow linearly from one to the next as
shown in figure above. In addition, each stage of the cycle feeds back to the preceding
stage, and through that stage to all earlier stages. Thus each stage affects all the ones that
come before it. Feedback from operation and maintenance is critical, and often
overlooked. It allows one to validate the threats and the legitimacy of the policy.
15
Types of Security Policy:
With respect to availability, a security policy describes what services must be provided. It
may present parameters within which the services will be accessiblefor e.g., that a
browser may download Web pages but not Java applets. It may require a level of
servicefor example, that a server will provide authentication data within 1 minute of
the request being made. This relates directly to issues of quality of service.
The statement of a security policy may formally state the desired properties of the
system. If the system is to be provably secure, the formal statement will allow the
designers and implementers to prove that those desired properties hold. If a formal proof
is unnecessary or infeasible, analysts can test that the desired properties hold for some set
of inputs. In practice, a less formal type of security policy defines the set of authorized
states. Typically, the security policy assumes that the reader understands the context in
16
which the policy is issuedin particular, the laws, organizational policies, and other
environmental factors. The security policy then describes conduct, actions, and
authorizations defining "authorized users" and "authorized use."
The second student has not, despite her failure to protect her homework. The security
policy requires no action to prevent files from being read. Although she may have been
too trusting, the policy does not ban this; hence, the second student has not breached
security. The first student has breached security. The security policy disallows the
copying of homework, and the student has done exactly that. Whether the security policy
specifically states that "files containing homework shall not be copied" or simply says
that "users are bound by the rules of the university" is irrelevant; in the latter case, one of
those rules bans cheating. If the security policy is silent on such matters, the most
reasonable interpretation is that the policy disallows actions that the university disallows,
because the computer science department is part of the university.
A security policy is a statement of what is and what is not, allowed. This defines security
for particular site/system.
17
Confidentiality is one of the factors of privacy, an issue recognized in the laws of many
government entities (such as the Privacy Act of the United States). Aside from
constraining what information a government entity can legally obtain from individuals,
such acts place constraints on the disclosure and use of that information. Unauthorized
disclosure can result in penalties that include jail or fines; also, such disclosure
undermines the authority and respect that individuals have for the government and
inhibits them from disclosing that type of information to the agencies so compromised.
Some integrity policies use the notion of a transaction; like database specifications, they
require that actions occur in such a way as to leave the database in a consistent state.
These policies, called transaction-oriented integrity security policies, are critical to
organizations that require consistency of databases.
The role of trust in these policies highlights their difference. Confidentiality policies
place no trust in objects. The policy statement states whether that object can be disclosed.
It says nothing about whether the object should be believed. Integrity policies, to the
contrary, indicate how much the object can be trusted. Given that this level of trust is
correct, the policy states what a subject can do with that object. The assignment of a level
of confidentiality is based on what the classifier wants others to know, but the assignment
of a level of integrity is based on what the classifier subjectively believes to be true about
the trustworthiness of the information.
18
Thus, a confidentiality policy is a security policy dealing only with confidentiality. While
an integrity policy is a security policy dealing only with integrity. Both confidentiality
policies and military policies deal with confidentiality; however, a confidentiality policy
does not deal with integrity at all, whereas a military policy may. A similar distinction
holds for integrity policies and commercial policies, where both deal with integrity;
however integrity policy does not deal with confidentiality.
A security policy is a high-level management document to inform all users of the goals of
and constraints on using a system. A policy document is written in broad enough terms
that it does not change frequently. The information security policy is the foundation upon
which all protection efforts are built. It should be a visible representation of priorities of
the entire organization, definitively stating underlying assumptions that drive security
activities. The policy should articulate senior management's decisions regarding security
as well as asserting management's commitment to security. To be effective, the policy
must be understood by everyone as the product of a directive from an authoritative and
influential person at the top of the organization.
Writing a useful and effective security policy, it covers inclusion of following aspects;
- Purpose
Security policies are used for several purposes, including the following:
19
- Audience
A security policy addresses several different audiences with different expectations. That
is, each groupusers, owners, and beneficiariesuses the security policy in important
but different ways.
- Contents
A security policy must identify its audiences: the beneficiaries, users, and owners. The
policy should describe the nature of each audience and their security goals. Several other
sections are required, including the purpose of the computing system, the resources
needing protection, and the nature of the protection to be supplied. We discuss each one
in turn.
If a security policy is written poorly, it cannot guide the developers and users in
providing appropriate security mechanisms to protect important assets. Certain
characteristics make a security policy a good one.
- Coverage
- Durability
A security policy must grow and adapt well. In large measure, it will survive the system's
growth and expansion without change. If written in a flexible way, the existing policy
will be applicable to new situations. However, there are times when the policy must
change (such as when government regulations mandate new security constraints), so the
policy must be changeable when it needs to be.
20
An important key to durability is keeping the policy free from ties to specific data or
protection mechanisms that almost certainly will change. It is preferable to describe
assets needing protection in terms of their function and characteristics, rather than in
terms of specific implementation.
- Realism
The policy must be realistic. That is, it must be possible to implement the stated security
requirements with existing technology. Moreover, the implementation must be beneficial
in terms of time, cost, and convenience; the policy should not recommend a control that
works but prevents the system or its users from performing their activities and functions.
- Usefulness
An obscure or incomplete security policy will not be implemented properly, if at all. The
policy must be written in language that can be read, understood and followed by anyone
who must implement it or is affected by it. For this reason, the policy should be succinct,
clear, and direct.
Risk Analysis:
Risks are events or conditions that may occur, and whose occurrence, if it does take
place, has a harmful or negative effect. Exposure to the consequences of uncertainty
constitutes a risk. In everyday usage, risk is often used synonymously with the
probability of a known loss. In information security, a risk is defined as a function of
three variables:
21
- transferring the risk, by allocating the risk to other systems, people, organizations,
or assets; or by buying insurance to cover any financial loss should the risk become a
reality
- assuming the risk, by accepting it, controlling it with available resources, and
preparing to deal with the loss if it occurs
Good, effective security planning includes a careful risk analysis. Risk analysis is the
process of examining a system and its operational context to determine possible
exposures and the potential harm they can cause.
1. Identify assets.
2. Determine vulnerabilities.
3. Estimate likelihood of exploitation.
4. Compute expected annual loss.
5. Survey applicable controls and their costs.
6. Project annual savings of control.
Access Control:
Access control is the ability to permit or deny the use of a particular resource by a
particular entity. Access control mechanisms can be used in managing physical resources
(such as a movie theater, to which only ticketholders should be admitted), logical
resources (a bank account, with a limited number of people authorized to make a
withdrawal), or digital resources (for example, a private text document on a computer,
which only certain users should be able to read).
In any access control model, the entities that can perform actions in the system are called
subjects, and the entities representing resources to which access may need to be
controlled are called objects.
22
Types of Access Control:
Individual user sets access control mechanism to allow or deny access to an object.
Access control is left to the discretion of the owner. Discretionary access controls base
access rights on the identity of the subject and the identity of the object involved. Identity
is the key; the owner of the object constrains who can access it by allowing only
particular subjects to have access. The owner states the constraint in terms of the identity
of the subject, or the owner of the subject. The owner can pass rights onto other subjects
(discretion). Also their programs can pass their rights and the owner has power to
determine who can access.
EXAMPLE: Suppose a child keeps a diary. The child controls access to the diary,
because she can allow someone to read it (grant read access) or not allow someone to
read it (deny read access). The child allows her mother to read it, but no one else. This is
a discretionary access control because access to the diary is based on the identity of the
subject (mom) requesting read access to the object (the diary).
When a system mechanism controls access to an object and an individual user cannot
alter that access, the control is a mandatory access control (MAC), occasionally called a
rule-based access control. System mechanism controls access to object, and individual
cannot alter that access. The operating system controls access, and the owner cannot
override the controls. Neither the subject nor the owner of the object can determine
whether access is granted. Typically, the system mechanism will check information
associated with both the subject and the object to determine whether the subject should
access the object. Rules describe the conditions under which access is allowed. Subjects
cannot pass the rights and subjects programs cannot pass the right to access. System
controls all accesses, and no one may alter the rules governing access to those objects.
23
EXAMPLE: The law allows a court to access driving records without the owners'
permission. This is a mandatory control, because the owner of the record has no control
over the court's accessing the information.
Role Based Access Control (RBAC), also known as Non discretionary Access Control,
takes more of a real world approach to structuring access control. Access under RBAC is
based on a user's job function within the organization to which the computer system
belongs.
24
Roles differ from groups in that while users may belong to multiple groups, a user under
RBAC may only be assigned a single role in an organization. Additionally, there is no
way to provide individual users additional permissions over and above those available for
their role. The accountant described above gets the same permissions as all other
accountants, nothing more and nothing less.
25
The Biba Integrity Model:
The Biba integrity model was published in 1977 at the Mitre Corporation; one year after
the Bell La-Padula model was published. The primary motivation for creating this model
is the inability of the Bell-LaPadula model to deal with integrity of data. The Biba model
addresses the problem with the star property of the Bell-LaPadula model, which does not
restrict a subject from writing to a more trusted object.
26