Policy references
|
edited by Netiva Caftori
Fall 2003 |
|
|
Policy references
|
written by Alessandro Lofaro |
Computer Security policy
Security Policies
1.1 Definition of a security policy
A security policy can be defined as a codified set of processes and
procedures applied to secure the fulfilment of its obligations and the
continuation of its activities even in presence of possible interferences.
We will see later that although this definition may appear more vague than
others that may be found in technical computer-related publications, it is
actually crafted by choosing each word precisely.
Security policies are most often referred to in the context of Information
Technology (IT), Telecommunications (TC) or Information and Communications
Technologies (ICT) and are often, as we shall see, erroneously associated
exclusively with the deployment of computer hardware or software and its
configuration, to the point of the configuration being called security policy.
The definition given in the ISO (International Standards Organisation)
standard 17799 is a slightly different one: "Management should set a clear
policy direction and demonstrate support for, and commitment to, information
security through the issue and maintenance of an information security policy
across the organisation" . It should be remembered it assumes an implicit
definition of what is a policy, and a separate indication is provided about
the necessity of a policy document including an indication of possible
contents (not reproduced here): "A policy document should be approved by
management, published and communicated, as appropriate, to all employees."
It must be pointed out that the BS ISO/IEC standard, as well as any other
standard , should not be applied or used in a mechanical way like a fixed
formula, but rather interpreted keeping in perspective the needs and working
model of the "entity" (e.g. business, non-profit organization, university,
etc.) in which their application is planned, as well as the ones of the
organization that created them.
1.2 Goals of a security policy
To "secure the fulfilment of its obligations and the continuation of its
activities", any entity using ICT systems needs to be able to guarantee the
confidentiality, integrity and availability of the information treated through
its ICT systems, and the authentication and accountability of the parties
involved in the exchange or treatment of information: this set of conditions
is thus the practical goal of a security policy.
"Confidentiality" indicates only those to whom the information is
destined or who should have access to it to perform their tasks shall have
access to the information.
"Integrity" indicates the fact the information cannot be altered from an
unauthorised party and should such tampering happen there shall be a clearly
visible indication it happened.
"Availability" indicates the fact the information can be accessed when
required by those who need it to accomplish their tasks.
"Authentication" indicates the possibility to verify that a party to an
exchange of information (or anyway someone who is trying to obtain access to
information or ICT systems) is who he/she claims to be; or that information
seemingly coming from one of the parties is indeed coming from that party. In
the first instance since what is verified is effectively the authenticity of
the claimed identity of the party (or parties) involved from a semantics point
of view would be more correct to talk about "identification" or
"authentication of the identity", however "authentication" is normally used.
"Accountability" is the possibility of establishing at any time who did
what, within the technical limits as well as the limits imposed by the
applicable legislation (treated briefly later in this section and more in
depth elsewhere).
To clarify what may seem like a list of abstract definitions, let's look at an
example.
Let's suppose you (the student) have a credit card and are going to buy a
textbook through a web site: you connect to the web site; choose the textbook
from the list; weep at the idea of paying (optional step, can happen later:);
receive an alert from your web browser saying you are going to start a secure
connection (depending on your configuration you may not receive an explicit
message, but in most cases you will see an indication like the picture of
small lock closed in the corner of the browser windows or something similar)
and eventually a message concerning the "certificate" of the web site; on the
neat and (hopefully) clear payment page you introduce your data and shipping
information, the credit card number, its expiration date and eventually the
three digits code on the back ; you click somewhere, the information is sent
and after some "munching" (usually due to the web site contacting the entity
that issued your credit card and verifying they can get the money) you receive
the confirmation that your book is on its way to you.
During this transaction the two parties (you and the bookseller) have
effectively used confidentiality, integrity, availability, authentication,
and accountability. Through the encryption of the communication, you are
reasonably sure the information is kept between you and and the bookseller, or
even better that your data is kept between you and the bookseller and the
credit card information between you and the issuer (confidentiality); the
encryption makes also sure the information you send is not being modified by
a third party (integrity); for you to order the book, the information on the
web site has to be available, and at the same time you must have the required
information available to fill the payment form (availability); the
certificate identifies the web site to you, while data like the billing
address and the name of the cardholder identify you to the web site
(authentication); it assumes YOU did the transaction. In general
this type of web site registers the address on the internet of the computer
you are connecting from as well as other information like the time at which
the transaction occurred (accountability).
A similar categorization of activities can be made on the link between
bookseller and issuer of the card (or the bookseller bank or any other
entity acting as "transaction processor" ).
As was said above, "authentication" is used both to refer to the verification
of the claimed identity of one of the parties and to the verification a message
or information that seems to come from one of the parties is indeed coming
from that party. Examples of the second kind of usage can be seen in movies
like "Crimson Tide" or "The hunt for Red October" when the orders are
"authenticated" (note that in these cases there is still an authentication
of the author of the message, but it is somehow implicit and taken for granted.
Only the military command can have the required codes to prepare a message
that can be "authenticated").
1.3 Scope of a security policy
If you observe with attention the definition of the security policy
we gave, you will see it covers all the "procedures and processes":
in information and communication technology texts written by or for
technical people the two terms are often used as referring
respectively only to human beings (procedures) on one side and only
to computer software (processes) on the other side. In our case,
the two terms are used as follows: "procedures" refers to a fixed
sequence of steps (which may or may not be very detailed)
foreseen by some sort of standard, while "process" refers to how
"things are done" either following the procedures or in absence of
them - both can thus imply human intervention or automatic systems.
Thus we can see a security policy is not limited to software and
hardware, but also considers the human factor. A security policy
should cover everything and anything having an impact on security,
like: computers, their software and the networks connecting them;
the fax machines and the telephone lines; the internet connectivity;
the backups; the safe disposal of printouts; the rules on the access
to buildings; reference to the indications for the maintenance of
material; the security training requirements; an assessment and
indication of what category of people will have access to what
type of information; how responsabilities related with security
will have to be distributed inside the organisation; eventual
background checks on new employees; who will have
responsability for or access to a specific part of the security policy.
In short, a security policy covers all the physical, logical
and organisational factors that have an impact on the usage of
information and the related tools in an entity.
1.4 Structure of a security policy
A security policy covering all the aspects hinted above in detail
could become a document of hundreds of pages, eventually requiring
even the knowledge of a great number of different people, especially
in big structures. This is one of the reasons (another being the
need to limit access to potentially sensitive technical
information) why most security policies are written
as a set of documents in a hierarchy going from the most general
to the most detailed ones dealing with specific aspects and
technical implementation of the security policy. Often when
talking about "security policy" the reference is to a document
giving a general, high level indication of the guidelines
defining the policy, with various other documents describing
aspects like the backup procedures and processes, the disposal
procedure for documents, the login procedure, the procedures
to attribute a login to a new user, the kind of background
checks to be made on new personnel, and so on. In many cases
these various documents are not written by people in charge of
writing the security policy but by people that will actually
implement the procedures they contain (e.g., system
administrators or backup operators may establish and
document the backup procedure including the indication of
how the backup media will be manipulated and by whom), but
they shall nonetheless be reviewed by the people responsible
for writing the security policy or a repected responsible person toverify
the defined guidelines.
1.5 Policy philosophies
The broadest possible type of categorisation of security policy is to examine
their approach to unforeseen activities: specifically, they can be either of
the type "anything not explicitely allowed is forbidden" or of the type "
anything not forbidden is allowed". These two options are the two extremes,
but in practice any given security policy will fit somewhere between the two
extremes.
It must be pointed out the extreme "anything not forbidden is allowed" is not
the same as not having any policy - deciding to follow such a line of action
and write it down in an official document (see previous note) requires an
explicit and supposedly well considered decision.
1.6 Main steps
The definition of a security policy and its codification can be a complex
exercise, a detailed and omnicomprensive description of which (if ever
possible) is outside the scope of this short introductory text: this
notwithstanding, it is possible to provide a list of a few steps that can be
used as generic guideline to write a security policy.
1.6.1 Define responsabilities
The first step necessary is also sometimes considered an obvious one not
needing any clear definition, giving birth to a whole host of problems. To
define an "entity-wide" security policy it is necessary as first step to
establish the responsabilities of each individual involved in defining it.
Specifically, it should be decided at least who is going to be the author or
coordinator of the policy and the support of the management (or any other
directive structure) should be made explicit, by communicating the need for
all departments (or everybody) to collaborate. Depending on the size of the
company, a "security policy review committee" including at least the foreseen
author of the policy and a high ranking manager should be created, provided
with the needed authority to ask for the resources necessary to create the
policy and eventually, after the same is approved, coordinate its
implementation.
1.6.2 Define system boundaries
To define the security policy, it is premordial to have a clear idea to what
the policy will apply, i.e. to tentatively establish what are the boundaries
of the system of interest (14).
When defining the boundaries of the system, care must be taken in relation
with the links and exchanges with outside parties, specifically deciding
who and what is "inside" and "outside".
1.6.3 Identify stakeholders
Once the boundaries of the system of interest are tentatively established,
the stakeholders should be identified, i.e. the people or organisations with
a direct or indirect interest in the security policy. Here, "indirect" refers
to those on which the security policy may have an impact even though they may
not be involved in its definition or application (e.g. students in an academic
environment, customers in a business situation).
1.6.4 Define context
Although it applies to a well defined system, the need to identify the
stakeholders should highlight how the security policy is not something that can
be done as if acting in a vacuum: it is thus important to identify the context,
both internal and external to the organisation, in which the policy is being
defined and will have to be applied.
Examples of factors to be considered in such a context are: the structure of
the organisation; the procedures in force in the organisation; the legal
framework in the country or countries where the company operates (keeping in
mind when internet or other international communication networks are concerned
incidents may include countries in which the organisation does not operate);
who can be interested in stealing or altering data held by the organisation.
1.6.5 Establish baseline
The first "practical" step in defining the security policy should be defining
the actual situation, either through a semi-informal process (in general when
there is no prior security policy) or through a formal "security audit" .
The result of this process shall be an indication of the actual situation in
terms of security approach and status in the organisation: a formal audit will
produce a documented assessment and may also be done in reference with a pre-
defined standard (e.g., BS 7799 part 2 provides a list of checks that can be
used to verify whether the policy in force is in conformance with BS/ISO 17799,
the NIST standard sp800-26 contains a checklist to verify whether the relative
US Federal Government standard is respected and so on).
Although it should be clear from the previous section on the scope of a
security policy, it should be pointed out how a well done and effective
security audit must include both an examination of the contents of the actual
security policy (if any exist) and procedures, and an analysis of the
technical infrastructure with verification of how the security policy is really
implemented.
In the case of entities small or anyway lacking the needed skills internally,
the possibility of using the services of external sources for at least part of
the audit should be considered, although it must be stressed this kind of
operation implies providing third-parties with access to sensitive information
and systems.
1.6.6 Define target
Once assessed the actual situation ("where we are"), should be established the
situation the organisation wants to reach ("where we want to go"), the "target".
The target can be defined either from scratch or by adapting to the situation
and needs of the organisation some of the standards available.
1.6.7 Define path
Once the starting point of the security policy is defined (the "baseline"
resulting from step 5), the next step is to assess the path from the baseline
to the target.
This part of the process is very important, as it can make the difference
between a successful implementation and a failed one. The authors of the
security policy can prepare one or more "high level" proposals concerning the
changes eventually needed to implement the security policy, however the
proposal(s) should be approved by and presented as a proposal of the "security
policy review committee": this could guarantee the support of the management
also for the practical changes needed to implement the policy, as well as
access to the information and skills needed to prepare this kind of proposals
the author of the policy might not have.
Although the presence of at least one manager in the committee could be
interpreted as automatic management approval of any proposal approved by the
committee, in general the proposals of the committee will have to be presented
to and approved by a board of directors, management committee or similar
decisional body, which will approve the relative implementation programme and
its budget (and maybe each of the projects in it with their budget, depending
on the company and the resources needed).
1.6.8 Define responsabilities, part two
Why define again the responsabilities, if they have already been defined
previously? In reality, the "responsabilities" we refer to now are different
and additional to the ones defined in the first steps of this process. The
responsabilities referred to here are the responsabilities for the
implementation of the security policy. They can thus be very detailed and
technical (e.g. installing antivirus software) also known as "low level",
though this label should be used with care, lest the one using it starts to
really believe they are operations of low importance and that can be done in
an approximative way.
While small entities can consider the possibility of assigning
responsabilities in this phase directly to individuals, as a general rule the
responsabilities should be given to departments or other internal divisions,
eventually through their representative in the "security policy committee".
This is done also to avoid the risk of the security policy being perceived as
"interference".
1.6.9 Implementation
Once established "who will do what", it is time to implement the security
policy: this does not mean, however, the "committee" has finished its work.
Especially if previously there was no security policy, the implementation of
it implies the realisation of activities from more than one department, and
the committee can thus have functions of coordination when needed, other than
verifying the projects are indeed consistent (both in their premises and in
their realisation) with the security policy.
1.6.10 go back
Once it's all well done, then we are all set, right? Wrong!
The security policy is not something static. It is something that needs to be
updated in a regular way to reflect changes in things like the entity approach
to its activities, the composition of the personnel, the legal framework, the
changes in technology and so on.
In principle, once established a security policy should be revised at least
every six months, though it is not strange at all to hear of yearly review and
technical documents lower in the hierarchy may need to be updated more often
depending on things like change in backup technology, new software versions
and so on. This is a further reason (another being the already mentioned
principle of the separation of roles) why it is better to have a hierarchy of
documents from the main policy document defining the principles down to the
more focused and limited technical documents, to allow modifications to the
technical document without need to review all the rest of the security policy
and its implementation.
The security policy itself should contain indications on the procedure to
review it (though of course its provisions must be consistent with other
procedures in force in the entity), including the related responsabilities.
1.7 Remember...
We have provided in the previous parts a definition and some guidelines on the
process of writing and applying a security policy, hinting (to the extent
possible in a short introductory course) to various aspects to be considered
during the process. In this section, the goal is to underline some aspects
that either because considered obvious or because "hidden" by other more
visible are unfortunately often underestimated or even forgotten, some
especially in much technical work published in USA, and can have a relevant
impact on the soundness of an otherwise apparently well designed and
technically correct security policy.
We are thus going to examine each of them, explaining their importance and
trying to show why they can have a serious impact.
1.7.1 Business ain't "chips", boys and girls...
The first mistake (which gives the title to this subsection), often made by
people with technical background or in companies with extensive use of ICT, is
to look at the problem exclusively from an ICT point of view. People in such
a position or such an entity often assume that to "secure the fulfilment of
its obligations and the continuation of its activities" is a required and
sufficient condition that from a technical point of view the situation is
safe, thus for instance that the systems with an important role for the
network infrastructure are well protected.
The problem is that although exceptions may be found, often the most critical
systems from a technical point of view are not also the most critical ones
from a point of view of the impact on the "business" (this applies to any kind
of activity, business, university, non-profit and so on). Especially when and
if the person(s) working on the security policy have a strictly technical
background, there is a risk they are going to see the processes inside the
entity only in terms of the computer systems (hardware and software) and
related networks, preparing the security policy accordingly.
To give an example, consider an university in which at the start of the
semester or the academic period (depending in which country and university you
are) you can register for the courses via the internet, using a server
separated from the one in which your records are stored. In such a situation,
an attack resulting in the registration server being temporarily unavailable
would be much more important from the point of view of the "fulfilment of its
obligations and the continuation of its activities" than an attack making the
central server unavailable, however most often someone considering only the
technical side will assume the registration server is less important since it
will typically be on the logical edge of the protected network.
1.7.2 Are you going to use it?
A basic characteristic of a security policy, often taken for granted, is that
it must be used, thus usable. This simple and apparently self-evident fact
represents often a problem, since the focus is often on writing a document
copying the various standards or the "best practices". The result can be at
best a set of theoretically very good rules and procedures which in practice
cannot be implemented in the entity of interest, and at worst an incoherent
patchwork.
The same lack of usability concerns can bring to the creation of a monolithic
document containing everything from the general principles and organisational
descriptions, to the details of every procedure to every detail of the
technical implementation, with the assumption that each and all employee will
read it (something extremely improbable to say the least (16)).
It is in general sufficient to follow relatively simple rules like making sure
the language used in each document is adequate to the audience, have members of
the security policy committee without a strong technical orientation read the
non-technical parts (and specifically the main "security policy" document),
making sure all the information about the procedures and processes followed in
the various departments is kept in mind when writing the documentation, and so
on.
1.7.3 Risk assessment
In indicating the main steps for the definition of a security policy above,
step 6 refers to the definition of the "target", in terms of procedures and
processes but also of the related technical implementation, the entity wants
to reach. A fundamental part of the process to define the target is making a
serious risk assessment.
As the name indicates, a "risk assessment" is an evaluation of the potential
threats, including an estimate of the probability that these threats become
real.
The indication the risk assessment must be "serious" should not be
underestimated. Since security implies the acquisition of a bit of
"professional paranoia", it is often assumed the more paranoic, the more
serious a risk assessment is - a wrong assumption.
While threats should not be underestimated, there are at least three good
reasons why an excess of paranoia can be counterproductive:
1. including in the list of possible threats improbable threats would
lower the credibility of the policy and consequently its effectiveness;
2. trying to obtain a one-hundred percent security by fully addressing all
threats might (and in general does) require too many resources;
3. the ultimate goal of a security policy is "the continuation of its
activities even in presence of possible interferences", excessively strict
rules will impact negatively and could actually block the continuation of the
activities.
The risk assessment must include not only an estimate or evaluation of the
potential impact of each threat, but also an estimate of the probability
(which may not be expressed in numerical terms) it becomes real. This aspect
is important in relation with point 2 of the reasons given above, allowing to
have an indication about the priority to assign to the prevention of each
threat and thus better use the resources.
The risk assessment also allows to realise better what losses can be expected
either by threats that cannot be addressed with available resources, or in the
eventuality that some threats might create damages despite the effort to
prevent them. This can be helpful in preparing countermeasures that, while not
impeding the negative effects, can minimise them.
1.7.4 Company culture
As written in the preceding and this section, an important part of writing a
security policy is the analysis of the way the entity works at the moment. To
be useful this analysis should also consider the "company culture" - factors
like the "mental attitude" in the company.
As an example, if the company puts much emphasis in "vertical" relations, a
manager may be tempted to use his/her position to "bypass" the rules - this
kind of possibility has to be factored in when writing the policy and the
related procedures, especially the ones related with the implementation.
A common mistake is in this case to rely simply on the "official documentation"
like the web site description for potential new employees, or not doing a
sufficiently deep analysis. Very often what is advertised is more like things
are supposed or hoped to be rather than how they really are.
1.7.5 People first
Although the presence of the human factor has been already indicated in the
previous sections, the human factor is not just one of the various factors, but
the first and most important factor to look at to insure the success of any
"would be" security policy.
The human factor impacts the security policy "before","during" and "after",
with example (not an esaustive list) of the possible way this influence acts
being as follows:
o Before the security policy, factors like the company structure, the
internal procedures, the company culture and the decision itself of creating a
security policy often depend heavily on decisions taken based on subjective
factors or subjective interpretation of objective data;
o While establishing a security policy, the way the policy is written
can be influenced also by the perception of the problem by the different
members of the security policy committee, and the amount of collaboration
received by people or departments in the organisation will depend very much on
their subjective perception of the policy and the risk of actively
collaborating or not;
o After the policy has been prepared, its successful implementation will
depend on whether each and all the people involved (which means all employees)
have a sufficient level of awareness about it and are convinced of its
importance and usefulness (or at least "limited damage" to their work).
From what said here and in the previous sections, it should be clear that the
first priority of a successfull security policy implementation is verifying and
providing the necessary level of training for users and technical personnel and
guaranteeing they are suitably informed.
1.7.6 Dura lex, sed lex
Any security policy must fit, as hinted in a previous section, in the legal
framework in force where the policy is to be implemented.
This problem is especially important when the entity's "home base" is in a
country (e.g. USA) with a type of legal framework and its policy is written
there, but it has to be applied in countries where the legal framework is
different (e.g., most Western European countries).
This problem can become even dangerous when the people that have to implement
it are coming from or are formed in the "home base" and have no idea of the
different legal framework elsewhere, as they may find themselves exposed to
both fines and criminal charges.
It is also important to note how involving lawyers or a legal deparment
representative in reviewing part of a security policy may not be the "panacea".
An employee with awareness of the local legal system reading the text of the
laws in force may be more able to ascertain the level of compliance of the
policy with them than an expert lawyer who does not have any experience or
knowledge of dealing with the matters of interest in the local legal framework.
Although another part of the book provides a more detailed examination of the
legal subject, a few examples of problems citing USA may be of interest to the
readership:
o in many countries, the direction cannot simply decide from one day to
the other they will read employees' e-mail and use keyloggers, without doing
some specific steps;
o a provision that personal customer data will be handled to any official
duly authorised by an American judge or American regulation can be valid in USA,
but as soon as it is applied (if not by its simple existence) would be an
immediate violation of the law in most countries in the world (though of course
handing over the data to local law enforcement duly authorised by a local
instance with the appropriate authority would not be a problem for the company,
even if the data was then communicated to USA authorities);
o transferring personal data of employees or customers outside the
country where it is collected without their prior consentment may be a
violation of the law in force.
It should be remembered although there are generic "families" of legal systems
(e.g. common law, Roman or Napoleonic law), neither the systems nor the laws
can be assumed identical, since laws and the legal procedures are often a
consequence of cultural and historical factors - thus for instance the
difference between different models of constitution (e.g. rigid, flexible,
open to subsequent interpretations and clarifications like the American one or
more precise and defined like most European ones) and
legal approaches even inside the same "family".
An example which is outside the security context but can give an idea of the
diffent ways to see the law even inside what is often indicated as being the
same identical ("identical" being the keyword) system: in a case in United
States, a woman received a hefty amount for suing McDonalds after burning her
tongue while drinking hot coffee; a woman who tried to do the same in UK was
not successful, with an argument which from "legalese" translates in plain
English as "if you don't know how to drink something hot, it is not McDonald's
fault".
1.8 Exercises
1. Company XYZ is a small company (20 people) with a manager and a system
administrator below him. The two prepare a security policy, according to which
some operations will have to be authorised by the manager and executed by the
system administrator, and the manager will know all the passwords and commands
needed and how to access and modify the logs. What rule has not been followed?
2. Company WYW in a company based in Oregon, which as part of a recent
decision to create a presence outside USA to has bought the control of small
companies based in France, Germany, Italy, Russia. Part of the process of
integrating the various parts is to create a common security policy, by a
committee which includes a member of their legal department (to verify the
legal compliance). The company plans then to send managers from their
headquarters in each country to make sure the policy is implemented correctly.
What is wrong in this planning?
1.9 Key to Exercises
1. The principle of the separation of responsabilities is not respected -
even though the manager is responsible for the service and can authorise some
operations, since it is not his/her direct responsability he/she should not be
able to do everything by himself/herself. The possibility he/she may also
modify the logs makes the situation even worst, since it excludes any
accountability.
2. The company has never operated outside USA, and the legal compliance
has been checked only by their local legal department, which would probably be
unable to verify compliance with different legal frameworks exactly because the
company has never operated outside the USA. Also, the managers to enforce it
are to be sent from their headquarters in Oregon and can also be assumed (for
the same reason) to be unable to notice and flag at the implementation stage
the potential future problems.
Return to Dr. Caftori's 
Last updated 5/18/03