and other special types of tool. Then the dissertation shall continue with the exam
of the activities that the implementation of a system for prevention and defence
from risks requires, leaving from the choice of the product up to its management
once set in production.
At last, an available product on market shall be tested and to it, through suitable
tools, some of the attacks previously examined shall be taken, so the effectiveness
of such product shall be checked in a few operating configurations.
The chapter 1 talks about the “Testo Unico sulla Privacy” (tr. Unique Text on
Privacy) examining the law from the point of view of the implications of technical
type resulting from the law obligations. The chapter 2 faces the risk problem under
a methodological point of view. The chapter 3 examines in a special way the risks
connected to the use of the data processing nets. The chapter 4 takes the
hardware and software tools into consideration for the management of the security
on the data processing nets. The chapter 5 faces the problems bound to planning
of a system installation for defence from the risks, starting from choice of the
product up to its management. In the chapter 6 is presented a product for the
management of a few security aspects. In the chapter 7 the product is submitted to
a few representative tests of the most common types of attack in some typical
configurations. Conclusions outline the tendencies for the future.
The Appendix 1 takes into account some normative references concerning the
aspects merely technician of the “Testo Unico sulla Privacy”. In the Appendix 2 are
shown the tools used in the tests of chapter seven.
Chapter 1: THE “TESTO UNICO SULLA PRIVACY”
Introduction.
The first of January 2004 the “Testo Unico sulla Privacy” has entered in operation
in Italy [Government Decree 06/30/2003 no. 196]; commonly called "Code of
Privacy" [DL196] rationalizes and renews in many parts the regulation previously
operating [Law 676/1996], which had already introduced the problem, but pressed
much less in obligations.
The Code imposes to all those who "manage" informations, which fall down
under the definition of "personal datum", to adopt a series of measurements which
protect specific characteristic of security, keeping in mind the following definitions
of the same Code, article 4:
* Personal Datum: any information on physical or legal person, corporation or
association, identified or identifiable, also indirectly, by reference to any other
information, and even a personal identification number.
* Treatment: any operation or complex of operations, made also without the help
of electronic tools, concerning the collection, the recording, the organization, the
conservation, the consultation, the elaboration, the modification, the selection, the
extraction, the comparison, the use, the interconnection, the block, the
communication, the diffusion, the cancellation and the data destruction, even if not
registered in a bank data.
The exam of Code's parts, not having technical consequences, is omitted, but is
still clear that its respect involves most of those who use data processing tools. For
a total exam of the measure look at [GD03].
The safety measures.
The Code's title V "Data and systems safety" shows a series of measurements of
general security, and of minimum measures in particular, to adopt for protecting
not only the informations but also the systems which contain them.
The article 31 imposes also measurements to avoid risks of destruction or loss,
illicit access or treatment, both in voluntary and casual way. The article 32 faces
the problem of nets’ usage and the relative systems of electronic communication.
The article 34 lists the minimum measures of security to be adopted for the
electronic treatment of personal data:
- data processing authentication;
- authentication credential management procedure adoption;
- utilization of an authorization system;
- periodic updating of the identification of allowed treatment ambit to the single
delegates and experts to management or electronic maintenance tools;
- protection of electronic tools and data in front of illicit data processing, not
allowed accesses and certain data processing programs;
- adoption of procedures for the security copy custody, restoration of data and
systems availability;
- keeping of an up-to-date programmatic document on the security;
- adoption of encrypting techniques or id codes for certain data treatments capable
to reveal health state or sexual life performed by sanitary organisms.
The article 36 specifies that all the adopted measurements must follow the
technique evolution and the new experiences performed in the sector, therefore an
effort constant and for long is required in adoption of countermeasures towards
threats, which come from the evolution of technical abilities of those who could
violate the data and the Systems under tutelage.
The disciplinary technical and the programmatic document on security.
Measurements shown in the paragraph preceding (Code’s articles 33-36) must be
adopted with respect to a disciplinary technical (Code’s enclosed B) which specify
the points of the obligations that each of the minimum security measures over list
involves.
A special news is the rule which, at point 17, imposes “periodic updating of the
softwares in order to prevent electronic tool vulnerability and to correct defects”,
the so-called patches. In fact the constant application of the patches regarding
security would allow to avoid almost totality of the intrusions not authorized inside
data processing systems [Rog01] [SANS00], and is remarkable that legislator has
wanted to specify such a a rule.
The point 19 prescribes the obligation to draw up every year the so-called
“Programmatic document on security”, containing “suitable information” on some
problems as these:
- list of treatments;
- distribution of tasks and responsibility;
- analysis of the risks imminent on data;
- measures to adopt for granting data’s integrity and availability, as well as the
protection of areas and places important for their custody and accessibility;
- criteria and modes description for the data availability’s restoration after
destruction or damaging. This point sends to no. 23 in which the concept of
availability restoration is extended to the systems too, and therefore referring to
disaster recovery problems. Moreover, such availability has to be restored in very
narrow technical times;
- formation on the security.
The points 21 and 22 say about the use of the removable supports as tool for
data storing and their destruction in case of not usage. The concept of removable
support is still extensible to the mass storages (hard disk), normally installed inside
processors, keeping in mind that at the end of the System “cycle of life” they shall
be opportunely treated before discharge (together at the System or in independent
way) or other type of recovery.
The risks analysis.
What the law requires is that all the threats imminent on data and on the lodging
systems are identified and therefore all the necessary countermeasures are
consequently adopted for restoring a minimum security level.
For many organizations, the obligation of drawing up the “Programmatic
document on security” has been the reason to do a serious risk analysis and to
program a plan of countermeasures. The risk analysis must take organization to
awareness that their informative resources can undergo to threats, and this
obviously without nothing to do with personal data.
The multiplicity of the implicated areas - management of staff and accesses,
Systems management, net management, disposal - and the involved level of
complexity imply that the analysis process is performed using criteria and
methodologies for not reduce it just to an exercise, or merely for legislative
fulfillment, but so that it becomes an opportunity to take advantage from the
involved organization.
Conclusions.
In this chapter the new law on the privacy has been examined. It has
implications, under the technical point of view, more onerous but also more
innovative with respect to preceding situation, imposing the execution of an in-
depth analysis of risks too. In the next chapter the risk analysis process shall be
examined from a methodological point of view.
Chapter 2: THE RISK IN THE DATA PROCESSING SYSTEMS
Introduction.
Although my dissertation considers principally the technician aspects of the risk
problem and the security in general, for the considerable amount of the involved
aspects requires to take into account a great deal of not technical aspects, such as
the policies, the operating procedures and the staff's formation.
In front of the security problem every organization should follow a series of
general principles, commonly accepted and applied by the data processing
community. Here are listed some of these principles, for a more in-depth treatise
look at [SHF04]:
* The security presuppositions:
- establish a clear policy as basic for the security design;
- treat the security as integral part in the design of every system;
- outline clearly the physical and logical borders ruled by various policies of
security;
- make sure that every involved person is trained on implement safe systems.
* Face the risks:
- reduce the risk at an acceptable level;
- consider the outside systems as uncertain;
- identify the compromises to be accepted between a risk reduction (and an
increase of costs) with respect to decrease of efficiency and other operating
aspects of the organization;
- implement custom-made security management systems for the reality in which
have actually to work;
- protect the information while they are elaborated, memorized or transported;
- protection against the all known attack typologies.
* Usage easiness:
- use always a language common and accepted by all the involved subjects;
- plan the security so to have every time capability of integrations for new
technology adoption or organization evolution;
- prefer use easiness of every adopted tool.
* Impact strength:
- avoid individual points of vulnerability;
- provide that the system is resilient and keeps on working also afterwards real
threats;
- isolate the public accesses from the critical systems;
- establish a border between critical systems and net infrastructure;
- implement a system allowing to trace fraudulent behaviors and supporting
subsequent investigations;
- arrange disaster recovery procedures.
* Reduce the vulnerability:
- prefer the simplicity;
- reduce to minimum the system trusted components;
- implement the use privileges at the minimum necessary level;
- do not implement not necessary security mechanisms;
- establish security procedures for the draining of systems out of production;
- identify and prevent the most common vulnerabilities.
* Plan keeping always in mind the net problems:
- implement the security through the combination of measures physically and
logically distributed;
- implement safety measures which consider the possible overlap among various
dominoes in which different policies are in force;
- authenticate the users so to be able to apply the appropriate controls both inside
and outside the domain;
- give to users unique ids in order to assure possibility of tracing.
During the dissertation shall often merge references to the principles over list.
The cycle of life of a data processing system.
As every complex system even a data processing system is characterized by
several phases that go from the design up to the dismantling, called “cycle of life”.
Each of the phases must be opportunely characterized in order to can make an
aimed type analysis of the risk on each of them. In the table 2.1 is shown a cycle
of life model of a data processing system [SGF04] [WTS03].
In every phase of the cycle of life the person responsible for security is kept to
observance the rules of the law. It is clear that no authority could do any
observations on a System not yet in production (phases 1, 2 and 3 of the cycle of
life), but is also clear that implementation's choices in security shall affect on next
the respect of the law, leaving apart the natural interest that every organization
has on its own security.
The risk evaluation.
It is the first process to be realize in the risk management methodology context.
It is used to evaluate the entity of potential threats and the associated risks to a
data processing system during its cycle of life. Here the risk is considered as the
probability that a determinate source of threat take advantage of a particular
vulnerability with a consequent impact on the violated organization.
To evaluate any unwelcome future event probability, threats must be jointly
analyzed with the potential vulnerabilities and the controls implemented in the data
processing system. The impact level is determined by the potential influences upon
the organization, on its purposes and goods, so it makes spring an evaluation on
data processing system and its depending resources.