Information Technology Reference
In-Depth Information
Rules (e.g. access control rules) are more precise than guidelines and can be repre-
sented formally. Security policies should have a goal and a set of security objectives.
Moreover, security policies are based on a model of the pertinent IS. This model
should include, at least, the main roles associated to security management, the assets
to be protected, and the main activities or processes that utilize those assets.
Security policies do not specify in detail the particular tools and controls to be
used. So, at least in the case of a HIS, security policies could be publicized without
jeopardizing the security of the HIS. On top of that, there are several stakeholders that
need to know the security policies adopted and the means to assess their effectiveness.
These may include data protection authorities, i.e. public authorities that monitor and
regulate the processing of personal information, medical associations, and patient
organizations.
2.1
Reasons for Policies' Differentiation
As each organization develops its own security policy, the resulting policies differ in
the degree of abstraction, granularity, and formality, using different terms and con-
cepts. The reasons causing differentiation of policies are summarized in the sequel:
−
Level of formalization
. Policies can be expressed formally, or they consist of natu-
ral language statements. Translating natural language policy statements to a formal
language looks like a promising solution. However, this translation entails the in-
terpretation of policy statements and the resolution of ambiguities, which are in-
herent in natural language statements. Both actions result in diminishing the flexi-
bility and the adaptability of the policy. This problem is equivalent to formalizing
legislation and thus automating justice.
−
Policy paradigm
. Policies adopt different paradigms. The most common paradigm
is the role-based paradigm. Following this paradigm, the policy provides rules ap-
plying to roles, instead of subjects. Then, additional rules are necessary for assign-
ing roles to subjects under a specific context (e.g. for a specific time-frame). How-
ever, there are cases where this paradigm is not applicable. Consider, for example,
the Chinese Wall security policy [3], which applies directly to subjects and it is
thus not feasible to adapt it to the role-based paradigm. So, the adoption of other
paradigms should not be excluded. These paradigms include subject-oriented poli-
cies (e.g. the Chinese-Wall security policy) and object-oriented policies.
−
Obligation and authorization
. Authorization policies are policies specifying the
activities that a subject is allowed or not allowed to perform, whilst obligation poli-
cies specify the activities that a subject must or must not perform [4].
−
Granularity level
. Differences may, also, arise from the way a policy is defining
the granularity of objects, activities, or roles. Policies may refer to a database or to
a field in a table, to business activities, to read-write actions, to general roles, such
as a 'physician', or to specific roles, such as 'chief pathologist in clinic A'.
The existence of such significant differences in policy formulation and representation
makes the task of comparing and assessing security policies of different IS difficult.
Forcing organizations to adopt a unique type of policy is not considered an option,
since organizations should retain their autonomy. Instead, we provide a common
conceptual model and a structured framework for representing security policies and
thus facilitate the juxtaposition and assessment of policies. This is the basis of the
Security Policies Repository that we shall present in the following paragraphs.
