Chapter

p 8
Administering Security

Ch l P.
Charles P Pfleeger
Pfl & Sh
Sharii LLawrence Pfl
Pfleeger, SSecurity
i ini Computing,
C i
4th Ed., Pearson Education, 2007 1

y In this chapter
y Study
S d off security
i controlsl by
b considering
id i administrative
d i i i andd physical
h i l
aspects. We look at four related areas:
y Planning.
Pl i What
Wh t advance
d preparation
ti andd study
t d lets
l t us know
k that
th t our
implementation meets our security needs for today and tomorrow?
y Risk analysis.
y How do we weigh g the benefits of controls against
g their costs,,
and how do we justify any controls?
y Policy. How do we establish a framework to see that our computer security
needs continue to be met?
y Physical control. What aspects of the computing environment have an
impact on security?
sec rit ?
2
8.1. Securityy Planningg
y Every organization using computers to create and store valuable assets
should
h ld perform
f thorough
h h andd effective
ff i security i planning.
l i
y A security plan is a document that describes how an organization will
address
dd its it security
it needs.
d
y The plan is subject to periodic review and revision as the organization's
security
it needsd change.
h
y A good security plan is an official record of current security practices,
plus
l a blueprint
bl i t ffor orderly
d l change
h to
t improve
i those
th practices.
ti

y Contents of a Security Plan

y A security
i plan
l id
identifies
ifi andd organizes
i theh security
i activities
i i i for
f a
computing system.
y The
Th plan
l iis bboth
th a ddescription
i ti off the
th currentt situation
it ti andd a plan
l ffor
improvement.

4
y Contents of a Security Plan (Cont’d)
y Every
E security i planl must address
dd seven iissues.
y policy, indicating the goals of a computer security effort and the willingness
of the people involved to work to achieve those goals
y current state, describing the status of security at the time of the plan
y requirements, recommending ways to meet the security goals
y recommended controls, mapping controls to the vulnerabilities identified
in the policy and requirements
y accountability, describing who is responsible for each security activity
y timetable, identifying when different security functions are to be done
y continuing attention,
attention specifying a structure for periodically updating the
security plan
5

y Policy
y A security
i plan
l must state the h organization's
i i ' policyli on security.
i
y A security policy is a high-level statement of purpose and intent.
y The
Th policy
li statement
tt t mustt answer ththree essential
ti l questions:
ti
y Who should be allowed access?
y To what system and organizational resources should access be allowed?
y What types of access should each user be allowed for each resource?

6
y Policy (Cont’d)
y The
Th policy
li statement should h ld specify if the
h ffollowing:
ll i
y The organization's goals on security.
y For example,
example should the system protect data from leakage to outsiders
outsiders,
protect against loss of data due to physical disaster, protect the data's
integrity, or protect against loss of business when computing resources
fail?
y What is the higher priority: serving customers or securing data?
y Where the responsibility for security lies.
y For example, should the responsibility rest with a small computer security
group with each employee
group, employee, or with relevant managers?

y Policy (Cont’d)
y The
Th policy
li statement shouldh ld specifyif the
h ffollowing:
ll i (C (Cont’d)
’d)
y The organization's commitment to security. For example, who provides
security support for staff,
staff and where does security fit into the organization's
organization s
structure?

8
y Current Security Status
y To
T be
b able
bl tto plan
l ffor security,
it an organization
i ti mustt understand
d t d theth
vulnerabilities to which it may be exposed.
y The organization can determine the vulnerabilities by performing a risk
analysis: a careful investigation of the system, its environment, and
the things that might go wrong.
y The risk analysis forms the basis for describing the current status of
security.
y The status portion of the plan also defines the limits of responsibility for
security. It describes not only which assets are to be protected but also
who is responsible for protecting them.
9

y Requirements
y The
Th heart
h off the
h security
i plan
l isi its
i set off security
i requirements:
i
functional or performance demands placed on a system to ensure a
d i d level
desired l l off security.
it

10
y Requirements (Cont’d)
y The
Th sixi "requirements"
" i " off the
h U.S.
U S Department
D off Defense's
D f ' TCSEC
There must be an explicit and well‐defined security policy enforced by the 
Security policy
y
system.
Every subject must be uniquely and convincingly identified. Identification is 
Identification
necessary so that subject/object access can be checked.
Every object must be associated with a label that indicates its security level. 
Marking The association must be done so that the label is available for comparison 
each time an access to the object is requested.
The system must maintain complete, secure records of actions that affect 
security. Such actions include introducing new users to the system, assigning 
Accountability
or changing the security level of a subject or an object, and denying access 
attempts.
The computing system must contain mechanisms that enforce security, and it 
Assurance
must be possible to evaluate the effectiveness of these mechanisms
must be possible to evaluate the effectiveness of these mechanisms.
Continuous  The mechanisms that implement security must be protected against 
protection unauthorized change.
11

y Requirements
y The
Th requirements
i explain
l i what
h should
h ld be
b accomplished,
li h d not how.
h
y That is, the requirements should always leave the implementation
d t il to
details t th
the ddesigners,
i whenever
h possible.
ibl

12
y Requirements
y the
h security
i planning
l i process must allow
ll customers or users to
specify desired functions, independent of the implementation.
y The
Th requirements
i t should
h ld address
dd allll aspectst off security:
it
confidentiality, integrity, and availability.

13

y Requirements
y The
Th requirements
i have
h these
h characteristics:
h i i
y Correctness: Are the requirements understandable? Are they stated
without error?
y Consistency: Are there any conflicting or ambiguous requirements?
y Completeness: Are all possible situations addressed by the
requirements?
y Realism: Is it ppossible to implement
p what the requirements
q mandate?
y Need: Are the requirements unnecessarily restrictive?

14
y Requirements
y The
Th requirements
i have
h these
h characteristics:
h i i (Cont’d)
(C ’d)
y Verifiability: Can tests be written to demonstrate conclusively and
objectively that the requirements have been met? Can the system or
its functionality be measured in some way that will assess the degree
to which the requirements are met?
y Traceability: Can each requirement be traced to the functions and
data related to it so that changes
g in a requirement
q can lead to easyy
reevaluation?

15

y Recommended Controls
y The
Th security
i plan
l must also
l recommendd what
h controlsl should
h ld bbe
incorporated into the system to meet those requirements.

16
y Responsibility for Implementation
y Identify
Id if which
hi h people
l are responsible
ibl for
f implementing
i l i the
h security
i
requirements.
y The
Th plan
l notes
t who h isi responsible
ibl for
f iimplementing
l ti controls
t l when
h
a new vulnerability is discovered or a new kind of asset is
it d d
introduced.

17

y Responsibility for Implementation (Cont’d)

y Each
E h role
l can take
k some responsibility
ibili for
f one or more aspects off
security. E.g.,
y PPersonall computer
t users may be
b responsible
ibl for
f the
th securityit off th
theiri own
machines.
y Project
j leaders mayy be responsible
p for the securityy of data and
computations.
y Managers may be responsible for seeing that the people they supervise
implement security measures.

18
y Responsibility for Implementation (Cont’d)
y E.g.
E (C (Cont’d)
’d)
y Database administrators may be responsible for the access to and
integrity of data in their databases.
databases
y Information officers may be responsible for overseeing the creation and
use of data; these officers may also be responsible for retention and proper
disposal of data.
y Personnel staff members may be responsible for security involving
employees,

19

y Timetable
y A comprehensive
h i security it plan
l cannott be
b executed
t d instantly.
i t tl
y The security plan includes a timetable that shows how and when the
elements of the plan will be performed.
performed
y These dates also give milestones so that management can track the
progress of implementation.
y The plan should specify the order in which the controls are to be
implemented
p so that the most serious exposures
p are covered as soon as
possible.
y The plan must be extensible.

20
y Continuing Attention
y The
Th security
i plan
l must callll for
f reviewing
i i theh security
i situation
i i
periodically.
y AAs users, data,
d t andd equipment
i t change,
h new exposures may develop.
d l
y In addition, the current means of control may become obsolete or
ineffective
y The inventory of objects and the list of controls should periodically
be scrutinized and updated,
p , and risk analysis
y pperformed anew.

21

y Security Planning Team Members

y A security
i planning
l i team should
h ld represent eachh off the
h following
f ll i
groups.
y computer
t hardware
h d group
y system administrators
y systems
y programmers
p g
y applications programmers
y data entry personnel
y physical security personnel
y representative users

22
y Assuring Commitment to a Security Plan
y After
Af theh plan
l iis written,
i iit must be
b acceptedd andd its
i
recommendations carried out.
y Commitment
C it t to
t the
th plan
l means th thatt security
it ffunctions
ti will
ill be
b
implemented and security activities carried out.

23

y Assuring Commitment to a Security Plan (Cont’d)

y Three
Th groups off people
l must contribute
ib to making
ki the
h plan
l a
success.
y The planning
Th l i tteam mustt bbe sensitive
iti to
t th
the needs
d off eachh group affected
ff t d bby
the plan.
y Those affected byy the securityy recommendations must understand what the
plan means for the way they will use the system and perform their business
activities.
y Management must be committed to using and enforcing the security aspects
of the system.

24
y Business Continuity Plans
y A business
b i continuity
i i plan
l documents
d how
h a business
b i will
ill
continue to function during a computer security incident.
y A bbusiness
i continuity
ti it plan
l ddealsl with
ith situations
it ti hhaving
i two
t
characteristics:
y catastrophic
t t hi situations,
it ti i which
in hi h allll or a major
j partt off a computing
ti
capability is suddenly unavailable
y longg duration,, in which the outage
g is expected
p to last for so longg that
business will suffer

25

y Business Continuity Plans (Cont’d)

y The
Th kkey to coping
i with
i h suchh disasters
di iis advance
d planning
l i andd
preparation, identifying activities that will keep a business viable
when
h th the computing
ti technology
t h l isi di disabled.
bl d
y The steps in business continuity planning are these:
y AAssess th
the bbusiness
i iimpactt off a crisis.
ii
y Develop a strategy to control impact.
y Develop and implement a plan for the strategy

26
y Business Continuity Plans (Cont’d)
y Assess Business Impact
y Begin by asking two key questions:
y What are the essential assets? What are the things that will
prevent the business from doing business?
y What could disrupt use of these assets? The vulnerability is
more important than the threat agent.

27

y Business Continuity Plans (Cont’d)

y Develop
D l Strategy
S
y The continuity strategy investigates how the key assets can be safeguarded.
y In some cases
cases, a backup copy of data or redundant hardware or an
alternative manual process is good enough.
y Sometimes, the most reasonable answer is reduced capacity.
y The result of a strategy analysis is a selection of the best actions, organized
by circumstances.
y The strategy can then be used as the basis for your business continuity plan

28
y Business Continuity Plans (Cont’d)
y Develop
D l Plan Pl
y The business continuity plan specifies several important things:
y who is in charge when an incident occurs
y what to do
y who does it
y The plan justifies making advance arrangements, such as acquiring redundant
equipment, arranging for data backups, and stockpiling supplies, before the
catastrophe.
y The plan also justifies advance training so that people know how they
should react.
react

29

y Incident Response Plans

y An
A incident
i id response plan
l tells
ll the
h staffff hhow to ddeall with
iha
security incident.
y In
I contrast
t t to
t the
th bbusiness
i continuity
ti it plan,
l ththe goall off iincident
id t
response is handling the current security incident, without regard for
th bbusiness
the i iissues.
y An incident response plan should
y ddefine
fi what
h t constitutes
tit t an incident
i id t
y identify who is responsible for taking charge of the situation
y describe the pplan of action

30
y Incident Response Plans (Cont’d)
y The
Th plan
l usually
ll has
h three
h phases:
h
y advance planning,
y triage
ti
y running the incident.
y A ffourth
th phase,
h review,i iis useful
f l after
ft ththe situation
it ti abates
b t so th
thatt
this incident can lead to improvement for future incident

31

y Incident Response Plans (Cont’d)

y Advance
Ad Pl
Planning
i
y Advance planning works best because people can think logically, unhurried,
and without pressure.
pressure
y Response Team
y director: p
person in charge
g of the incident,, who decides what actions to take
and when to terminate the response.
y lead technician: person who directs and coordinates the response.
y advisor(s): legal, human resources, or public relations staff members as
appropriate.

32
y Incident Response Plans (Cont’d)
y Response
R TTeam
y Need to consider certain matters.
y Legal issues: An incident has legal ramifications.
ramifications
y Preserving evidence:
y Records:
y Public relations:

33

y Incident Response Plans (Cont’d)

y After
Af the h IIncident
id IIs RResolved l d
y Eventually, the incident response team closes the case.
y At this point it will hold a review after the incident to consider two things:
y Is any security control action to be taken?
y Did the incident response plan work?

34
 y
8.2. Risk Analysis
y A risk is a potential problem that the system or its users may experience.
y We distinguish a risk from other project events by looking for three things
y A loss associated with an event. This loss is called the risk impact.
y The likelihood that the event will occur.
y The probability of occurrence associated with each risk is measured from 0
(impossible) to 1 (certain).
y The degree to which we can change the outcome.
y Risk control involves a set of actions to reduce or eliminate the risk.

35

y we can quantify the effects of a risk by multiplying the risk impact by

the
h risk
i k probability,
b bili yielding
i ldi the
h risk
i k exposure.
y For example, if the likelihood of virus attack is 0.3 and the cost to
clean
l up th the affected
ff t d files
fil iis $10
$10,000,
000 th
then th
the risk
i k exposure iis
$3,000. So we can use a calculation like this one to decide that a
virus
i checker
h k isi worth th an investment
i t t off $100, $100 since
i it willill preventt a
much larger potential loss.

36
y In general, we have three strategies for dealing with risk:
1. avoiding
idi the
h risk,
i k bby changing
h i requirements
i ffor security
i or other
h
system characteristics
2. transferring
t f i the th risk,
i k bby allocating
ll ti th the risk
i k tto other
th systems,
t people,
l
organizations, or assets; or by buying insurance to cover any
fi i l lloss should
financial h ld theth risk
i k bbecome a realitylit
3. assuming the risk, by accepting it, controlling it with available
resources, andd preparing
i tto ddeall with
ith th
the lloss if it occurs

37

y Thus, costs are associated not only with the risk's potential impact but
also
l withi h reducing
d i it. i
y Risk leverage is the difference in risk exposure divided by the cost of
reducing
d i the th risk.
i k In
I other
th words,
d risk
i k leverage
l isi

38
y Steps of a Risk Analysis
1. Identify
Id if assets.
2. Determine vulnerabilities.
3. E ti t likelihood
Estimate lik lih d off exploitation.
l it ti
4. Compute expected annual loss.
5. S
Survey applicable
li bl controls
t l andd their
th i costs.
t
6. Project annual savings of control.

39

y Step 1: Identify Assets

y Decide
D id what h we needd to protect
y Thus, identify the assets of the computing system
y E.g.,
E
y hardware: processors, boards, communications media, …
y software: source programs,
programs object programs
programs, OS,
OS ….
y data: data used during execution, stored data on various media, …
y people: skills needed to run the computing system or specific programs
y documentation: on programs, hardware, systems, ….
y supplies: paper, forms, laser cartridges, magnetic media, …

40
y Step 2: Determine Vulnerabilities
y Want
W to predict
di what
h damage
d might
i h occur to the
h assets andd from
f
what sources
y can use a matrix
ti
Asset Confidentiality Integrity Availability

Hardware
Software
Data
People
Documentation
Supplies
41

y Step 2: Determine Vulnerabilities (Cont’d)

y In
I thinking
hi ki about
b the
h contents off eachh matrixi entry, we can askk the
h
following questions.
y Whatt are the
Wh th effects
ff t off unintentional
i t ti l errors??
y •What are the effects of willfully malicious insiders?
y •What are the effects of outsiders?
y •What are the effects of natural and physical disasters?

42
 Asset Secrecy Integrity Availability

overloaded destroyed  failed stolen destroyed 
Hardware
tampered with unavailable
impaired by Trojan 
deleted misplaced usage 
d l d  i l d   
Software stolen copied pirated horse modified 
expired
tampered with
damaged ‐ software 
damaged 
disclosed accessed by 
di l d  d b   d l d  i l d 
deleted misplaced 
Data error ‐ hardware error ‐
outsider inferred destroyed
user error
quit retired terminated 
People
l
on vacation
Documentation lost stolen destroyed
Supplies lost stolen damaged

43

y Step 3: Estimate Likelihood of Exploitation

y Determine
D i how
h often
f eachh exposure isi likely
lik l to bbe exploited.
li d
y Several approaches to computing the probability that an event will
occur: classical,
l i l frequency,
f andd subjective.
bj ti

44
 Frequency
q y Rating
g
More than once a day 10
Once a day 9
Once every three days 8
Once a week 7
O  i  t  
Once in two weeks
k 6
Once a month 5
y
Once every four months 4
Once a year 3
Once every three years 2
Less than once in three years 1

45

y Step 4: Compute Expected Loss

y Determine
D i theh likely
lik l lloss if the
h exploitation
l i i does d indeed
i d d occur.
y … include hidden costs
y Think
Thi k off explicit
li it andd hidd
hidden costt related
l t d tto security
it suchh as
y What are the legal obligations for preserving the confidentiality or integrity of
a given data item?
y What business requirements and agreements cover the situation? Does the
organization have to pay a penalty if it cannot provide a service?
y Could release of a data item cause harm to a person or organization? Would
there be the possibility of legal action if harm were done?
y …

46
y Step 5: Survey and Select New Controls

47

y Step 6: Project Savings

y The
Th effective
ff i cost off a given
i controll iis the
h actuall cost off the
h controll
(such as purchase price, installation costs, and training costs) minus
any expected
t d loss
l ffrom using i th
the control
t l ((suchh as administrative
d i i t ti or
maintenance costs).
y Thus,
Th th the ttrue costt off a control
t l may bbe positive
iti if th
the control
t l iis
expensive to administer or introduces new risk in another area of
th system.
the t
y Or the cost can even be negative if the reduction in risk is greater
th the
than th costt off the
th control.
t l
48
 Item Amount
Risks: disclosure of company confidential data, computation based on incorrect 
data

Cost to reconstruct correct data: 
$100,000
$1,000,000 @ 10% likelihood per year

ect e ess o access co t o so t a e:

Effectiveness of access control software: 
‐60,000
6
60%
Cost of access control software +25,000

Expected annual costs due to loss and 
$65,000
controls (100,000 ‐ 60,000 + 25,000)

Savings (100,000 ‐ 65,000) $35,000

49

y Arguments For and Against Risk Analysis

Good reasons to perform Risk  Arguments against using Risk 
Analysis Analysis
Improve awareness False sense of precision and 
confidence
Relate security mission to  Hard to perform
management objectives
  b
Identify assets, vulnerabilities, and  Immutability
controls
Improve basis for decisions Lack of accuracy
Justify expenditures for security

50
 g
8.3. Organizational Securityy Policies
y A security policy must answer three questions: who can access which
resources in what manner?
y A security policy is a high-level management document to inform
all users of the goals of and constraints on using a system.
system
y A policy document is written in broad enough terms that it does not change
frequently.
q y
y The information security policy is the foundation upon which all protection
efforts are built.
y It should be a visible representation of priorities of the entire organization,
definitively stating underlying assumptions that drive security activities.

51

y Purpose
y Security
S i policies
li i are usedd ffor severall purposes, including
i l di theh
following:
y recognizing
i i sensitive
iti information
if ti assets
t
y clarifying security responsibilities
y ppromotingg awareness for existingg employees
p y
y guiding new employees

52
y Audience
y Users
U
y Users legitimately expect a certain degree of confidentiality, integrity, and
continuous availability in the computing resources provided to them
them.
y Users also need to know and appreciate what is considered acceptable use
of their computers, data, and programs.
y Owners
y Each piece of computing equipment is owned by someone, and the owner
may not be a system user.

53

y Audience (Cont’d)
y Beneficiaries
B fi i i
y Beneficiaries depend, directly or indirectly, on the existence of or access to
computers their data and programs
computers, programs, and their computational power
power.
y Balance Among All Parties
y A securityy policy
p y must relate to the needs of users,, owners,, and
beneficiaries.

54
y Contents
y A security
i policy
li must id
identify
if iits audiences:
di the
h bbeneficiaries,
fi i i users,
and owners.
y The
Th policyli should
h ld describe
d ib theth nature
t off eachh audience
di andd their
th i
security goals.
y Several
S l other
th sections
ti are required,
i d iincluding
l di ththe purpose off th
the
computing system, the resources needing protection, and the nature
off th
the protection
t ti to t bbe supplied.
li d

55

y Purpose
y The
Th policy
li should
h ld state the
h purpose off the
h organization's
i i ' security
i
functions, reflecting the requirements of beneficiaries, users, and
owners.
y For example, the policy may state that the system will
y ""protect
t t customers'
t ' confidentiality
fid ti lit or preserve a trust
t t relationship,"
l ti hi "
y "ensure continual usability,"
y "maintain profitability."
p y

56
y Purpose (Cont’d)
y There
Th are typicallyi ll three
h to fifive goals,
l suchh as:
y Promote efficient business operation.
y Facilitate sharing of information throughout the organization.
organization
y Safeguard business and personal information.
y Ensure that accurate information is available to support business processes.
y Ensure a safe and productive place to work.
y Comply with applicable laws and regulations.

57

y Protected Resources
y A risk
i k analysis
l i will
ill hhave id
identified
ifi d the
h assets that
h are to bbe
protected.
y These
Th assets t should
h ld be
b lilisted
t d iin th
the policy,
li iin th
the sense th
thatt th
the
policy lays out which items it addresses.
y For
F example, l
y Will the policy apply to all computers or only to those on the network?
y Will it apply to all data or only to client or management data?

58
y Nature of the Protection
y The
Th asset lilist tells
ll us what
h should
h ld be
b protected.
d
y The policy should also indicate who should have access to the
protected
t t d ititems.
y It may also indicate how that access will be ensured
andd how
h unauthorized
th i d people
l will
ill be
b ddenied
i d access.

59

y Characteristics of a Good Security Policy

y Coverage
C - A security
i policy
li must bbe comprehensive:
h i IIt must either
ih
apply to or explicitly exclude all possible situations.
y Durability
D bilit
y Realism - it must be possible to implement the stated security
requirements
i t with
ith existing
i ti ttechnology.
h l
y Usefulness - An obscure or incomplete security policy will not be
i l
implementedt d properly,
l if att all.
ll

60
y Example
y Government
G Agency
A IT Security
S i Policy
P li : Department
D off Energy
E
(DOE)
y … It isi the
th policy
li off DOE ththatt classified
l ifi d iinformation
f ti andd classified
l ifi d ADP
[automatic data processing] systems shall be protected from unauthorized
access ((includingg the enforcement
f off need-to-know pprotections),), alteration,,
disclosure, destruction, penetration, denial of service, subversion of security
measures, or improper use as a result of espionage, criminal, fraudulent,
negligent, abusive, or other improper actions. The DOE shall use all
reasonable measures to protect …

61

y Example
y Government
G Agency
A IT Security
S i Policy
P li : Department
D off Energy
E
(DOE) (Cont’d)
y The generality
Th lit off the
th hheader
d paragraphh iis complemented
l t d by
b subsequent
b t
paragraphs giving specific responsibilities:
y "Each data owner shall determine and declare the required q protection
p
level of information . . ."
y "Each security officer shall . . . perform a risk assessment to identify and
document specific . . . assets, . . . threats, . . . and vulnerability . . ."
y "Each manager shall...establish procedures to ensure that systems are
contin o sl monitored...to
continuously monitored to detect security
sec rit infractions . . .""
62
 y
8.4. Physical Securityy
y Physical security is the term used to describe protection needed
outside
id the
h computer system.
y Natural Disasters
y Flood
Fl d
y Fire
y Other
Oth NNatural
t l DiDisasters
t
y Power Loss
y Uninterruptible
U i t tibl Power
P SSupply
l
y Surge Suppressor

63

y Human Vandals
y Unauthorized
U h i d AAccess andd Use
U
y Theft
y Preventing
P ti Access
A
y Preventing Portability
y Detecting
D t ti Theft
Th ft

64
y Interception of Sensitive Information
y Shredding
Sh ddi
y Overwriting Magnetic Data
y Degaussing
D i
y Protecting Against Emanation: Tempest
y Computer
C t screens emitit signals
i l thatth t can be
b ddetected
t t d ffrom a distance.
di t
y Tempest is a U.S. government program under which computer equipment is
certified as emission-free ((that is,, no detectable emissions).)

65

y Contingency Planning
y Backup
B k
y Complete backups are done at regular intervals, usually weekly or daily,
depending on the criticality of the information or service provided by the
system.
y Major installations may perform revolving backups, in which the last several
backups are kept. Each time a backup is done, the oldest backup is replaced
with the newest one.
y Selective backup, in which only files that have been changed (or created)
since the last backup are saved.

66
y Contingency Planning (Cont’d)
y Offsite
Off i Backup
B k
y Networked Storage
y Cold
C ld Site
Sit
y A cold site or shell is a facility with power and cooling available, in which a
computing system can be installed to begin immediate operation.
operation
y Hot Site
y A hot site is a computer
p facilityy with an installed and ready-to-run
y
computing system.
y The system has peripherals, telecommunications lines, power supply, and
even personnel ready to operate on short notice.
67

8.5. Summaryy
y Examined four parts of how security is administered.
y Security
S i planning
l i iis a process that
h drives
d i the
h rest off security
i
administration.
y Risk
Ri k assessmentt isi a technique
t h i supporting ti security
it planning.
l i
y An organizational security policy is a document that specifies the
organization's
i ti ' goalsl regarding
di security.
it
y Physical security concerns the physical aspects of computing

68