home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / hacking / general / greenbk.txt < prev    next >
Encoding:
Internet Message Format  |  2003-06-11  |  210.6 KB

  1. Date:    Mon, 30 Aug 1993 19:44:46 +0059
  2. From:    Roland Hueber <100013.1437@CompuServe.COM>
  3. Subject: Green Book, Draft 3.6
  4. Message-Id: <930830174446_100013.1437_BHB54-1@CompuServe.COM>
  5.  
  6. Draft 3.6
  7.  
  8.  
  9. Green Book on the Security of Information Systems - Draft 3.6
  10.  
  11. Table of Contents
  12. 1.    Preface                             1
  13. 2.    Introduction                         3
  14. 3.    Scope                             5
  15. 4.    General issues                         6
  16. 4.1.    Globalisation of the economy and mobility         6
  17. 4.2.    Internal Market ("four freedoms")             6
  18. 4.3.    Human Rights and the protection of communications     7
  19. 4.4.    Social acceptance of identification methods         8
  20. 4.5.    Human Rights and the safety of systems             9
  21. 4.6.    Management of openness and protection            10
  22. 4.7.    Common concerns of commercial and national security    11
  23. 4.8.    Security and law enforcement on international scale    12
  24. 4.9.    Economics of the security of information systems    12
  25. 4.10.    Social recognition of information crime            13
  26. 4.11.    Safety critical environments                14
  27. 4.12.    Embedded systems                    15
  28. 5.    Demand related issues                    16
  29. 5.1.    Agreement on security requirements for enterprises    16
  30. 5.2.    Agreement on security requirements for individual users    17
  31. 5.3.    Security objectives for enterprises            18
  32. 5.4.    Sectoral specifics                    19
  33. 5.5.    Security methodologies                    19
  34. 5.6.    Security domains                    20
  35. 5.7.    Data labelling                        21
  36. 5.8.    Access control and authenticity issues            22
  37. 5.8.1.    Access control                        22
  38. 5.8.2.     The individual right to signature            23
  39. 5.8.3.    Consistency of legal principles                24
  40. 5.8.4.    Signature schemes                    25
  41. 5.8.5.    Key usage                        26
  42. 5.8.6.    Universal acceptance                    27
  43. 5.8.7.    Security of electronically stored  information        27
  44. 5.9.    Privacy enhancement issues                28
  45. 5.9.1.    Perception of requirements for privacy enhancement    28
  46. 5.9.2.    The case for the provision of public confidentiality
  47.     services                        30
  48. 5.9.3.    Interworking of autonomous confidentially services    32
  49. 5.10.    Motivation to acquire evaluated solutions        32
  50. 5.11.    Consistency of procurement practices            33
  51. 5.12.    Information Valuation                    34
  52. 6.    Supply related issues                    35
  53. 6.1.    Supply related Issues - Trusted Third Parties        35
  54. 6.1.1.    Role of Trusted Third Parties                35
  55. 6.1.2.    Operating principles of TTP                37
  56. 6.1.3.    Accreditation and audit of TTPs                38
  57. 6.1.4.    Use of names and certification of credentials        38
  58. 6.1.5.    Key management service                    40
  59. 6.1.6.    Management Services for Names and Credentials        42
  60. 6.1.7.    Legal services                        43
  61. 6.1.8.    Guaranteed date and time stamping            44
  62. 6.1.9.    Negotiable document transaction                45
  63. 6.2.    Supply related issues - Evaluation of trusted solutions    47
  64. 6.2.1.    Perceived Requirements for trusted solutions        47
  65. 6.2.2.    International harmonisation and mutual recognition    47
  66. 6.2.3.    Vendor declarations                    49
  67. 6.2.4.    Evaluation of applications                49
  68. 6.2.5.    Evaluation of communication services            49
  69. 6.2.6.    Trusted network management                51
  70. 6.2.7.    Modifications to evaluated products and re-evaluation    52
  71. 6.2.8.    Performance reporting for trusted products        53
  72. 6.2.9.    Rationalisation of evaluations                53
  73. 6.3.    Supply related issues - technological change        55
  74. 7.    Liability related issues (Consequences of Security
  75.     and Safety Incidents)                    57
  76. 7.1.    Framework for international law relating to IS        57
  77. 7.2.    Legal provisions for liability in global services    57
  78. 7.3.    Insurance issues                    57
  79. 7.4.    Monitoring of compliance                58
  80. 7.5.    Metrics for loss assessment                58
  81. 8.    Spectrum of Measures                    60
  82. 8.1.    Common Framework and Consensus                60
  83. 8.2.    Awareness, education and training            61
  84. 8.3.    Agreements                        62
  85. 8.4.    Common Practices and Codes of Conduct            63
  86. 8.5.    Specifications                        65
  87. 8.6.    Standards                        66
  88. 8.7.    Products and Services                    67
  89. 8.8.    Technology                        68
  90. 8.9.    Regulation and Legislation                70
  91. 8.10.    Accreditation                        72
  92. 8.10.1.    Accreditation of Services                72
  93. 8.10.2.    Accreditation of TTPs                    72
  94.  
  95. Annex: Recalling the Action Lines from the Council mandate    73
  96.     Action line I - Development of a strategic framework
  97.     for the security of information systems            73
  98.     Action line II - Identification of user and service
  99.     provider requirements for the security of information    74
  100.     Action Line III - Solutions for immediate and interim
  101.     needs of users, suppliers and service providers        74
  102.     Action line IV - Development of specifications,
  103.     standardisation, evaluation and certification in
  104.     respect of the security of information systems        75
  105.     Action line V - Technological and operational
  106.     developments in the security of information systems    76
  107.     Action line VI - Provision of security of information
  108.     systems                            77
  109.  
  110. Draft 3.6/Version: July 14, 1993
  111.  
  112. 1.    Preface
  113.  
  114. The Council adopted in May 1992 a Decision in the field of the security
  115. of information systems comprising the development of overall strategies
  116. for the security of information systems (action plan) and setting up a
  117. Senior Officials Group (SOG-IS) to advise the Commission on action to
  118. be undertaken. The action plan having as objective the development of
  119. overall strategies aiming to provide users and producers of
  120. electronically stored, processed or transmitted information with
  121. appropriate protection of information systems against accidental or
  122. deliberate threats.
  123.  
  124. The scope of the Decision foresees the following lines of action:
  125. I.      Development of a strategic framework  for the security of
  126.     information systems
  127. II.     Identification of user and service provider requirements for
  128.     the security of information systems
  129. III.    Solutions for immediate and interim needs of users, suppliers
  130.     and service providers
  131. IV.     Development of specifications, standardisation, evaluation, and
  132.     certification in respect of the security of information systems;
  133. V.      Technological and operational developments in the security of
  134.     information systems; and
  135. VI.    Provision of  security of information systems.
  136.  
  137. The action plan is implemented by the Commission, in close association
  138. with related actions in Member States and in conjunction with related
  139. Community research and development actions.
  140. As a step towards the formulation of the "Action Plan" identified in
  141. the Council Decision and in accordance with the opinion of SOG-IS a
  142. "Green Book on the Security of Information Systems" is being prepared,
  143. which addresses, in accordance with the Annex of the Decision,  an
  144. overall view of the issues involved, and the spectrum of measures that
  145. result from an analysis of the issues.
  146.  
  147. The present document sets out the background to the development of a
  148. consistent approach to Information Security in Europe taking into
  149. account common interests with other countries.
  150.  
  151. The intention of the Commission Services in preparing the present
  152. document is to encourage a better understanding with the sector actors
  153. in the Community on Information Security issues and to develop a
  154. consensus on the requirements to be considered.  It therefore does not
  155. necessarily represent the views of the Commission Services, or of the
  156. Senior Officials Group for Information Security, on the subject, but
  157. rather provides a basis for reflection and concertation with sector
  158. actors and Member States.
  159.  
  160. The "Green Book" represents an intermediate step towards the
  161. formulation of the Action Plan foreseen in the Council Decision. It is
  162. to state the main issues related to the security of information systems
  163. in its context.  A deliberate effort has been made to present the
  164. subject matter in as objective a fashion as possible. By progressively
  165. widening the consultation in the preparation of the document the wish
  166. is, to obtain a representative and balanced view of the issues and the
  167. nature and implications of the options for action one may wish to
  168. consider. In its presentation the document is intentionally avoiding to
  169. voice an opinion on the framework or organisation which might be
  170. adopted to address a given issue or requirement. Such recommendations
  171. are to be included in the Action Plan.
  172.  
  173. Note on Draft 3
  174.     The preparation of the document includes four successive phases
  175.     including iterative steps in the preparation of the document:
  176.     Phase I: Preparation of an Outline and Collection of material
  177.     Phase II: Drafting
  178.     Phase III: Informal Consultation
  179.     Phase IV: Formal Consultation
  180.     In its present form it relates to the result of Phase II of the
  181.     preparation of the Green Book.
  182.  
  183. The present draft document is the result of numerous contributions
  184. received from experts, working in the framework of IBAG, SRI, the
  185. Security Investigations and SOG-IS members (over 60 contributions
  186. received).  To develop the thinking on specific groups of issues, the
  187. Advisory Group reinforced by other experts were consulted and
  188. contributed to the development of the document:
  189.  
  190. G. Axelsson
  191. F. Iribarne Navarro
  192. F. Piau
  193. C. Blatchford
  194. C. Jansen
  195. E. Pimentel Saraiva
  196. L. Cabirol
  197. M. Jones
  198. R. Pizer
  199. D. Cerny
  200. M. King
  201. K. Presttun
  202. B. Collins
  203. S. Kowalski
  204. M. Purser
  205. M. De Soete
  206. H. Kurth
  207. K. Rihaczek
  208. A. Eriksen
  209. P. Landrock
  210. G. Roelofsen
  211. S. Geyres
  212. O. Leiberich
  213. R. Rueppel
  214. A. Hallan 
  215. R. Moses
  216. G. Ruggiu
  217. G. Hardy
  218. P. MAller
  219. M. Tuset
  220. S. Herda
  221. A. Parondo
  222. P. van Dijken
  223. E. Humphreys
  224. A. Peralta
  225. D. Willis
  226.  
  227. Their contribution and valuable advise is gratefully acknowledged.
  228.  
  229. 2.    Introduction
  230.  
  231. Individual, corporate and national wealth is increasingly in the form
  232. of information. The growth and performance of an estimated 2/3 of the
  233. economy relies on manufacturing or services heavily dependent on
  234. information technology, telecommunications and broadcasting, and
  235. therefore depends critically on the accuracy, security and
  236. trustworthiness of information. This is of as great importance and
  237. interest for individuals as for commerce, industry and public
  238. administrations. Correspondingly, the protection of information in all
  239. its aspects, here referred to as Information Security , has become a
  240. central policy issue and a major concern world-wide.
  241.  
  242. The Council Decision of March 31, 1992 in the field of information
  243. systems recognises this situation and calls for the "development of
  244. strategies to enable the free movement of information within the single
  245. market while ensuring the security of the use of information systems
  246. throughout the Community".
  247.  
  248. A consistent approach at European level could help to promote the
  249. interoperability of systems, lower existing barriers and avoid the
  250. formation of new ones between the individual Member States and with
  251. other countries Therefore, there is an urgent need to address
  252. requirements and options for action in the field of security of
  253. information systems at national, Community and international level in
  254. close collaboration with sector actors and national governments. Any
  255. action must take into account both national and international
  256. commercial, legal and technical developments.
  257.  
  258. The key issue is to provide effective and practical security for
  259. information held in an electronic form to the general users, the
  260. business community and administrations without compromising the
  261. interests of the public at large.
  262.  
  263. Since information security is involved in the protection not just of
  264. property and people, but even of society itself, Member States regard
  265. it as a topic which, like defence, touches on national sovereignty.
  266.  
  267. Structure of this document
  268.  
  269. The core of the document is describing issues and requirements for
  270. action. These issues are grouped under the following headings:
  271.  
  272.     General issues. Here some of the basic issues relating to the
  273.     security of information systems are described. These place
  274.     security into a fast evolving world economy and treats issues
  275.     like rights and obligations, human rights, openness and
  276.     protection.
  277.  
  278.     Demand related issues. Issues under this section are concerned
  279.     with requirements, security objectives, Codes of Practice, and
  280.     the needs for digital signature and privacy enhanced
  281.     communications.
  282.  
  283.     Supply related issues. The subjects discussed cover possible
  284.     answers to the demand for security and include Trusted Third
  285.     Parties, evaluation and R&D.
  286.  
  287.     Liability related issues. Under this heading issues relating to
  288.     the consequences of security breaches are dealt with. These
  289.     include civil law and insurance.
  290.  
  291. The diagram below depicts this structure.
  292.  
  293. 3.    Scope
  294.  
  295. 4.    General issues
  296.  
  297. 4.1.    Globalisation of the economy and mobility
  298.  
  299. Issue
  300.  
  301. The internationalisation, diversification, pluralisation and
  302. popularisation of the use of communications and information systems.
  303.  
  304. Discussion
  305.  
  306. The unprecedented increase in mobility and the provision of global
  307. communications has resulted in manufacturing, trade and leisure
  308. activities extending world-wide. Distributed manufacturing, publishing,
  309. and financial operations form the back-bone of the modern economic
  310. system. Travelling and communications for business or pleasure are
  311. common place. This is being supported, and sometimes driven, by a
  312. spectacular development in the field of communications and by the
  313. proliferation of affordable and easy to use information systems. In the
  314. last decade the cost-performance of long-distance transmission has
  315. improved by 5 orders of magnitude. This change is providing the basis
  316. for a rapid diversification of world-wide services customised to
  317. provide access to a full range of information services and utilities
  318. wherever and whenever required. Terrestrial, satellite and mobile
  319. networks provide the physical infrastructure and an unrestrained number
  320. of service applications provide the customised applications.
  321.  
  322. The nature and scope of provision of Information Security in this new
  323. world of open, multi-service and multi-media communications with a
  324. multitude of alternatives to routing, management and access has
  325. profoundly changed the requirements and options for Information
  326. Security (IS).
  327.  
  328. Requirements
  329.  
  330.     Revision of the scope and approach to information security to
  331.     reflect the new conditions, challenges and requirements brought
  332.     about by globalisation
  333.  
  334.     Adaptation of the respective policies and regulations.
  335.  
  336. 4.2.    Internal Market ("four freedoms")
  337.  
  338. Issue
  339.  
  340. Alignment of the national conditions relating to Information Security
  341. with the conditions of the Internal Market
  342.  
  343. Discussion
  344.  
  345. The Internal Market provides for the "four freedoms " within the
  346. Community, ie free movement of goods, capital, services and people. The
  347. legislation of Member States provides for the internal needs for
  348. Information Security, however the requirements in the case of
  349. trans-European communications remains to be addressed. Inconsistent or
  350. incomplete provisions of information security represents a technical
  351. obstacle to the working of the Internal Market.
  352.  
  353. Requirements
  354.  
  355.     Verification of the existing provisions with respect to their
  356.     conformance to the Internal Market Policy of the EC implying
  357.     the removal of existing internal barriers and the avoidance of
  358.     the formation of new technical barriers due to divergent
  359.     application of IS rules, regulations and legislation
  360.  
  361.     Provision of IS to business and the public of solutions freely
  362.     applicable throughout the Community and on a preferential basis
  363.     at the international level.
  364.  
  365. 4.3.    Human Rights and the protection of communications
  366.  
  367. Issue
  368.  
  369. To reconcile the human right to privacy and the obligations of law
  370. enforcement to protect public order.
  371.  
  372. Discussion
  373.  
  374. Privacy and the protection of private information is considered one of
  375. the fundamental human rights of citizens and is protected to varying
  376. degrees in Member States. The European convention on Human Rights
  377. states "Everyone as a right to respect for his private and family life,
  378. his home and his correspondence". Citizens have the legitimate
  379. expectation that this right is respected and that solutions are made
  380. available to him that ensure the safeguard of this right. This applies
  381. to conversation in the home and to a lesser degree when
  382. telecommunications is being used. However, prevailing national
  383. solutions do not, at present, provide for trans-European services and
  384. communications and this lack can be exploited, inter alia, by organised
  385. crime. With the rapid growth and diversification of communication
  386. services the rights and duties of citizens and law enforcement are
  387. being reviewed and redefined, eg FBI supported legislation and the
  388. proposal of the government to provide US business and citizens with
  389. cryptographic devices including explicit provision for intercept by law
  390. enforcement agencies.
  391.  
  392. In this context, it should also be noted that the Maastricht treaty
  393. establishes a citizenship of the Union, and that every person holding
  394. the nationality of a Member State shall be a citizen of the Union.
  395.  
  396. As the safety and security of the citizen provided by the process of
  397. law and order is also related to human rights, reconciling these
  398. objectives represents a delicate political issue.
  399.  
  400. The diagram below gives an overview of international, Community and
  401. national responsibilities for different application categories.
  402.  
  403.  
  404. Requirements
  405.  
  406.     Definition of a common approach defining rights,
  407.     responsibilities and duties of citizens and business on the one
  408.     hand, and that of the authorities on the other hand.
  409.  
  410. 4.4.    Social acceptance of identification methods
  411.  
  412. Issue
  413.  
  414. To reconcile the human right to privacy and protection and the use of
  415. identification methods to control human access to systems, buildings,
  416. offices and other physical environments.
  417.  
  418. Discussion
  419.  
  420. The use of biometric methods is becoming more technically feasible and
  421. cost-effective as an identification technique for access control. Such
  422. methods rely on a system of machine recognition of a set of personal
  423. characteristics to verify the identity of an authorised user in order
  424. to allow access to some physical environment. Such personal
  425. characteristics include hand-written signatures, fingerprints, voice
  426. prints, machine phrenology, lip prints, response of the skeleton to a
  427. physical stimulus, hand geometry and retinal patterns.
  428.  
  429. Many other different personal characteristics and recognition
  430. techniques are being investigated by researchers. Some of these effect
  431. the human right for privacy more than others and some are socially
  432. unacceptable.
  433.  
  434. As an example, the retinal blood-vessel pattern of a human eye (retinal
  435. vasculature) is highly characteristic of the individual. A typical
  436. system might work as follows. The individual is required to look into
  437. an optical device and through a process of optical adjustment fixate on
  438. a crosswire whereby the recognition machine will locate the fovea of
  439. the individual, and scanning with a low intensity infra-red beam detect
  440. the nodes and branches of the retinal pattern falling within the
  441. scanned area. The measured pattern is compared with the stored pattern
  442. of the individual and access is granted or denied depending on the
  443. result of the comparison. This method of machine recognition may or may
  444. not be considered sociably acceptable on the grounds of hygiene, due to
  445. the type of information being stored about the individual (a record of
  446. which may be built up which may reveal other information relating to a
  447. persons health condition) or the general problem of protection of
  448. medically relevant information.
  449.  
  450. There are systems under trial for the recognition of human profiles eg
  451. the human face. Again these systems may not in general be socially
  452. acceptable and the issue of privacy and human rights may come into
  453. play.
  454.  
  455. Progress in bio-technology raises new questions as to the definition of
  456. privacy and as to the rights of the individual over information
  457. relating to his person and the assurances required for its use.
  458. Information relating to genetic defects are of obvious sensitivity and
  459. implies corresponding measures for protection. Work may need to be
  460. undertaken to set out a clear definition between things that are
  461. biometric and things that are medical.  At the present time there is
  462. low confidence by the general public in the honesty of commerce or
  463. government in the field of bio-technology.
  464.  
  465. Requirements
  466.  
  467.     Clarification of the ownership and privacy issues surrounding
  468.     biometric data
  469.  
  470.     Development of an agreed classification of biometric data and
  471.     conditions requiring secure handling of such data
  472.  
  473.     Development of a common approach defining the rights of and
  474.     responsibilities of citizens, business users, corporations and
  475.     administrations using biometric techniques.
  476.  
  477. 4.5.    Human Rights and the safety of systems
  478.  
  479. Issue
  480.  
  481. To reconcile the human right to an expectation of the supply of goods
  482. and services that are not life threatening with the vendors commercial
  483. needs to supply goods and services that exploit information systems in
  484. safety critical functions.
  485.  
  486. Discussion
  487.  
  488. Security critical systems differ from security critical ones in that if
  489. they fail death or serious injury to people may result. The law treats
  490. the liability of suppliers in this situation differently from that
  491. where information is lost or property damaged. Suppliers are held
  492. strictly liable. Codes of practice for the development of safety
  493. critical systems exist in order to reduce the chance of failure and
  494. design techniques are invoked to analyse all possible hazards.
  495. Nevertheless risks remain.
  496.  
  497. At a community level, harmonisation of such codes of practice and
  498. design techniques would enable citizens to have greater expectations of
  499. their own safety in any member nation, and it would reduce the costs of
  500. development of codes of practice and design techniques in each nation.
  501. Furthermore, pan-community procurement would be facilitated, as would
  502. the development of safety critical systems by community wide
  503. consortia.
  504.  
  505. Requirements
  506.  
  507.     Review of current design practices and codes of conduct with
  508.     the aim of generating a community wide standard for such
  509.     processes
  510.  
  511.     Study the legal environment within which vendors and users of
  512.     safety critical systems work, with the objective of harmonising
  513.     that environment.
  514.  
  515. 4.6.    Management of openness and protection
  516.  
  517. Issue
  518.  
  519. Openness and protection are partially contradictory user requirements,
  520. which need to be reconciled depending on the specific circumstances.
  521. The user must be able to define the security controls based on need,
  522. consistent with national, international and regulatory constraints.
  523. These controls need to managed in a way that provides protection in an
  524. open environment.
  525.  
  526. Discussion
  527.  
  528. In considering management, one must introduce the concept of a user of
  529. an Information System, and the role that they perform in using that
  530. system.  At any time the user of an Information System will be
  531. performing a role, which could be one of: system owner, administrator,
  532. auditor, investigator, data provider, reviewer/collator. It is quite
  533. possible for the requirements of these roles to be logical in conflict
  534. with each other. Openness of access may be in conflict with protection
  535. from general availability. There may also be national, international or
  536. regulatory constraints which impose role requirements beyond those
  537. needed to satisfy the operational use of the Information System.  An
  538. Open environment must be provided with controls that are capable of
  539. providing protection without technical limitations.
  540.  
  541. A single, isolated computer may be effectively protected, as far as
  542. confidentiality is concerned, against threats from outside by physical
  543. separation and human administration. This does not apply in the context
  544. of telematics. Telecommunications and telematics applications are
  545. increasingly being designed for maximum openness and inter-operability
  546. since the utility of ITT&B-based services and applications depends
  547. largely on the possibility of users world-wide being able to freely
  548. inter-operate over communication links. Major international efforts are
  549. underway to establish standards permitting this, in particular through
  550. OSI (Open System Interconnection), (ODP) Open Distributed Processing
  551. and ONP (Open Network Provision).
  552.  
  553. The acceptance and use of telematics services depends on meeting the
  554. justifiable interests of all parties: in particular to be able to chose
  555. trade-offs between "openness" and "protection".
  556.  
  557. In recognition of this, increasing attention is being given to the
  558. provision of Information Security Services and Techniques.
  559.  
  560. The comparison with the way this dilemma is traditionally addressed
  561. leads to some observations which most likely will also apply when
  562. information is handled electronically. These include, for example
  563.  
  564.     The User/Originator requires the freedom to decide over the
  565.     degree of openness/protection depending on his appreciation of
  566.     the requirement or the applicable rules of conduct for the
  567.     given activity.
  568.  
  569.     Profiles exist setting out the needs of both openness and
  570.     protection that need to be supported.  A single level profile
  571.     will not support the requirements of all the users involved,
  572.     and there may need to be mechanisms which allow for negotiation
  573.     between profiles to determine temporarily agreed common
  574.     profiles.
  575.  
  576.     Infrastructure, services, applications and organisation have to
  577.     be adapted to provide the openness/protection.
  578.  
  579.     To the role holders, both the visibility of and the
  580.     transparency of the degree of openness/protection is crucial.
  581.  
  582.     Accountability for the application of appropriate levels of
  583.     openness/protection require objective records, which are
  584.     themselves protected.
  585.  
  586.     The management of the openness and the protection of
  587.     Information Systems requires the definition of security
  588.     domains.  These correspond to the security policies which are
  589.     in force for the Information Systems in use, as modified by the
  590.     constraints of the role holders.  It should be remembered that
  591.     computers which are not directly under human supervision may
  592.     form part of the security domains involved.
  593.  
  594. Requirements
  595.  
  596. Development of a generic framework for the management of open and
  597. protected communications in a user/business oriented environment:
  598.  
  599. 1.    Reinforcement of the options to define security domains 
  600.     Terminal users, servers and other computer based resources link
  601.     into business processes to provide information domains which
  602.     require corresponding security domains.  Such facilities must
  603.     not only promote the correct degree of openness , but must also
  604.     provide filters against unauthorised access. This needs to be
  605.     possible not only at one site eg on LAN-Based applications, but
  606.     also via MANs and other communication-links. The definition and
  607.     management of such security domains needs to be possible either
  608.     from within the user group or provided by a trusted third
  609.     party. Virtual Private Networks have some of the features, but
  610.     these would also need to be available in the context of public
  611.     network based applications.
  612.  
  613. 2.    User Interface for the management of openness/protection
  614.  
  615.     The normal usage requires the ability to communicate either
  616.     with specific correspondents, a select group, an open group or
  617.     indiscriminately. The choice being determined by the nature of
  618.     the information, its function and the applicable rules. The
  619.     user-interface needs to cater for this as well as the
  620.     underlying services and applications.
  621.  
  622. 3.      Objective records and procedures for the accounting of
  623.     open/protected transactions
  624.  
  625.     Processes must be available that provide non-refutable evidence
  626.     of the origin of, and delivery of, information to all involved
  627.     partners.
  628.  
  629. 4.7.    Common concerns of commercial and national security
  630.  
  631. Issue
  632.  
  633. Information Security is a common concern of business, administrations,
  634. citizens, law enforcement and defence.
  635.  
  636. Discussion
  637.  
  638. Though not to the same degree, commercial and personal information
  639. security shares many aspects with the defence and other classified
  640. governmental affairs. This provides an opportunity for commercial and
  641. personal applications to build on experience and expertise from the
  642. defence and classified government area.
  643.  
  644. The reverse is also true. As commercial security advances and becomes
  645. available at a large scale, governments and defence organisations are
  646. well advised to take into account this body of experience. In addition
  647. governments themselves are, of course, in the need of adequate
  648. protection of their non-classified information and will wish to make
  649. use of public services of this kind.
  650.  
  651. Requirements
  652.  
  653.     Concerted effort to address the common requirements of
  654.     business, citizens and authorities to adequately protect
  655.     commercial and personal information and its communication
  656.  
  657.     definition of common rules and procedures distinguishing the
  658.     handling of classified and commercial and personal
  659.     information.
  660.  
  661. 4.8.    Security and law enforcement on international scale
  662.  
  663. Issue
  664.  
  665. Crime is exploiting weak information security to further its ends.
  666. Strong information privacy may also be used to escape investigation by
  667. law enforcement.
  668.  
  669. Discussion
  670.  
  671. Crime, and here organised crime and terrorism in particular, are
  672. relying on weak information security to prepare and execute their
  673. operations. As quite powerful means for information security have been
  674. published and are freely available, their increased use in protecting
  675. such operations is a growing problem. Public authorities have in the
  676. past used legal and regulatory powers to restrict the use and
  677. dissemination of related technologies. With the growing availability of
  678. computing power and open networks, this approach is getting less
  679. effective, as organised crime, contrary to the legitimate user, is not
  680. concerned with the use of products that are not authorised. The overall
  681. result is that business is seriously constrained in meeting its
  682. security requirements, particularly in international communications and
  683. in its relations with other organisations. If business requires the
  684. legal and regulatory powers to relinquish total control over these
  685. security related technologies, business has a "duty of care" to manage
  686. and control their use for their commercial and business purposes,
  687. including the policing and auditing of management environments.
  688.  
  689. Requirements
  690.  
  691.     An effective, internationally agreed, economic, ethical and
  692.     usable solution to meet business, administration and personal
  693.     needs including mechanisms for authorised interception and
  694.     reporting of incidents and crimes adjusted to the conditions of
  695.     the Internal Market, and to include the necessary equipment and
  696.     software, but also an infrastructure of Trusted Third Parties.
  697.     This will discourage "home-made" or other solutions.
  698.  
  699. 4.9.    Economics of the security of information systems
  700.  
  701. Issue
  702.  
  703. The use of information security impacts on costs, performance and
  704. availability.
  705.  
  706. Discussion
  707.  
  708. The cost of security is an integral part of cost of ownership of an
  709. information system, ie namely that without security the users system is
  710. at risk. The cost of protection against breaches of security needs to
  711. be commensurate with the costs (both direct and indirect) that may be
  712. incurred from a breach in security. A security breach may have short
  713. term (and perhaps, localised) implications such as loss of sales and
  714. revenue or fraud or theft. It may also have longer term (and wider)
  715. impacts on business communities through loss of confidence and
  716. consequential loss of business.
  717.  
  718. The costs of detection, resistance and recovery can be both tangible
  719. and high, and although there are techniques available to quantify risks
  720. there are no generally applicable methods for estimating the potential
  721. costs arising for example from denial of service or loss of integrity.
  722. The provision of security measures may also make it harder to use and
  723. may constrain overall performance. However, where the security risk is
  724. high enough to cause an unacceptable level of compromise, leading to
  725. considerable commercial and financial loss, then security measures must
  726. be given high priority commensurate with the nature and value of the
  727. business in question.
  728.  
  729. If IS is to expensive, clumsy, not effective in the context of actual
  730. usage or not available in time its use is avoided and high risks are
  731. taken until something drastic happens. The issue for IS is therefore,
  732. not only to be effective but also to address other requirements which
  733. impact the acceptability and application of IS.
  734.  
  735. In particular, countermeasures may have to be put in place that meet
  736. specific regulatory or legislative requirements, with associated
  737. mandatory assurance needs.
  738.  
  739. To a business, securing information can be thought of as being like an
  740. insurance policy - the cost of protection must be balanced against the
  741. likely consequences of the perceived threat occurring. This cost is
  742. made up of a number of elements, including:
  743.  
  744.     the life-cycle costs of implementing the countermeasures in
  745.     relation to likely and worst case
  746.  
  747.     impact on business performance
  748.  
  749.     liability of management for incidents and relationship with
  750.     customer confidence.
  751.  
  752. Requirements
  753.  
  754.     Development of an approach to a "cost of Security" model for a
  755.     business and the private user. This includes, among other
  756.     potential costs, the cost of installation, operation,
  757.     maintenance, up-grade and insurance premiums as well as direct
  758.     financial losses due to breaches of security.
  759.  
  760.     Definition of IS as business and marketing factor.
  761.  
  762.     Codes of practice and other recognised regulatory norms need to
  763.     be developed which identify to a level acceptable to both
  764.     insurers, regulators and the commercial courts specific duties
  765.     and responsibilities of the parties to the use of Information
  766.     Systems and their security requirements.
  767.  
  768. 4.10.    Social recognition of information crime
  769.  
  770. Issues
  771.  
  772. Negligence, ignorance and recklessness are the some of the causes of
  773. many security events and create the opportunity for information
  774. crimes.
  775.  
  776. Discussion
  777.  
  778. IS-incidents, like failures to observe safety rules, can in many
  779. instances be attributed to a lack of motivation. This is compounded by
  780. the fact that the loss of immaterial goods, for example information, is
  781. not considered as serious as the loss of material goods. This is due in
  782. part to the fact that electronically stored information can be
  783. reproduced at close to zero costs without the loss of the original.
  784. Stealing information is therefore often considered as a gain for the
  785. thief without a loss to the owner. It is perceived by many to be a game
  786. rather than a real problem because people are unable to relate the
  787. electronic world to the real one. This has the double effect of
  788. enciting negligence by the owner of the information and little concern
  789. for the illegal acquisition of information. Because of the widely
  790. practised back-up of information resources, this applies even to the
  791. intentional or accidental destruction of information.
  792.  
  793. There is much work in establishing and reinforcing "ethical principles"
  794. as applied to specific actions of information ownership, creation,
  795. dissemination, etc. These need to be related to sector actors, their
  796. control perspective and the assets over which they exercise either
  797. explicit or implicit authority. This needs to be related to codes of
  798. practice and conduct, legislation and regulation to establish the
  799. extent to which protection is dependent upon a formal or informal
  800. control environment or can rely on the enhancement of ethical and
  801. professional standards. At the moment there are no effective
  802. professional standards in IT, anyone can do IT by buying a PC and
  803. taking a bulletin board subscription.  Changes to traditional
  804. programming techniques have made it possible for non-IT professionals
  805. to deliver programming and systems analysis methods.  In many SMEs such
  806. work would often be done by non-IT professionals.]
  807.  
  808. Two examples of computer crime illustrate the diversity of situations
  809. which may arise:
  810.  
  811. Example 1
  812. In a German company (belonging to the "Association for Security") a
  813. programmer - unsatisfied with his salary - caused damage by a specific
  814. computer-programme. This program modified the data of a data bank by
  815. randomly controlled accesses. The programme was intricately hidden
  816. among other programme-parts. Within two years the data-bank became more
  817. and more defective and damaged. The costs of damages and of
  818. reconstructing the data bank were about 500 000 ECU.
  819.  
  820. Example 2
  821. In an office of the German Government a huge computer-system,
  822. comprising various storage means and terminals was installed. Suddenly
  823. the computer-execution-times and the response times became much longer
  824. than expected. After a difficult investigations it turned out, that a
  825. programmer, who had founded together with his wife a shop for sending
  826. out photo-equipment, has done his complete accounting, mailing, etc.
  827. for his shop on the computer in a hidden area. He had camouflaged or
  828. suppressed the protocolling of this programme. He caused damage of
  829. about 100 000 ECU.
  830.  
  831. Requirements
  832.  
  833.     Development into basic education of the Information Security
  834.     requirements and concepts needed to operate safely in the
  835.     Information Age
  836.  
  837.     Clarification of "Info-Ethics" for the professional and
  838.     individual user in its relationship to Information Security
  839.  
  840.     Clarification of responsibilities of the sector actors in
  841.     general and in their relations within each other, with
  842.     particular reference to open and distributed applications.
  843.  
  844. 4.11.    Safety critical environments
  845.  
  846. Issue
  847.  
  848. Protection of information in safety critical environments.
  849.  
  850. Discussion
  851.  
  852. Safety is defined in terms of hazards and risk. A hazard is a set of
  853. conditions (a state) that can lead to an accident, given certain
  854. environmental conditions. The analysis of the safety environment
  855. involves identifying the hazards within a safety critical environment
  856. and then either verifying that hazardous states cannot be reached or
  857. that the risk is acceptable. Risk is defined as a function of the
  858. probability of a hazard occurring, the probability that the hazard will
  859. lead to an accident, and the worst potential loss associated with such
  860. an accident. You can diminish risk by reducing any or all of these
  861. factors, and there are environmental-safety techniques that focus on
  862. each.
  863.  
  864. There is an increase in the use of information systems within various
  865. areas of application which are considered as part of a safety critical
  866. environment. For example in the area of healthcare (eg medical
  867. databases), air traffic control, transportation of hazardous and
  868. dangerous goods, industrial processes etc. The increased reliance on
  869. electronic information in these various areas of application
  870. specifically related to the control and management of safety, has
  871. resulted in an increased need for the protection of the information
  872. system supplying such information. Therefore the protection of
  873. information systems used in safety critical environments is factor to
  874. be addressed when considering hazards and associated risks in such
  875. environments.
  876.  
  877. Consideration needs to be given to the common requirement of security
  878. and safety, common methods for analysing the threats, vulnerabilities
  879. and hazards, and the role of security evaluation for safety-critical
  880. systems.
  881.  
  882. Requirements
  883.  
  884.     Development of a common approach to the handling of security
  885.     and safety critical requirements
  886.  
  887.     Development of a common methodology for threat, vulnerability
  888.     and hazard analysis for the protection of information systems
  889.     used in safety-critical environments
  890.  
  891.     Generation of common methodology for the design, development
  892.     and procurement of safety critical systems, covering project
  893.     management, development environment, auditing of process,
  894.     configuration management and change control
  895.  
  896.     Development of a common approach to security evaluation of
  897.     information systems in safety-critical environments.
  898.  
  899. 4.12.    Embedded systems
  900.  
  901. Issue:
  902.  
  903. Increasing use of computers and information processing is occurring in
  904. a manner that incorporates information/computers into other products to
  905. make those products more usable, flexible, etc. These embedded systems
  906. depend upon the accuracy of the programs they contain and the
  907. information inputs/outputs to preserve the usefulness of the products
  908. in which they are placed. Failure of the processor or corruption of the
  909. programs or information contained may cause failure or destruction of
  910. the device or hazard to the user.
  911.  
  912. Discussion:
  913.  
  914. Embedded systems are already being used in automobiles for controlling
  915. ignition and carburetor systems or braking systems, in television sets
  916. and VCRs, in microwave ovens, and so on. As embedded systems
  917. proliferate they create potentials for physical hazard to users beyond
  918. simple loss of the functionality of the devices in which they are
  919. embedded. The potential will also exist that such embedded systems
  920. could constitute a hazard to the well-being of bystanders or property.
  921. For example, one scenario of embedded systems would have them in
  922. household appliances and include the capability to communicate
  923. potential failure information to maintenance providers. The potential
  924. exists that such a device could fail in a mode that would put household
  925. or service providers' telephone systems at risk.
  926.  
  927. To some extent, liability laws will cover product failures which create
  928. damage to users. However, there may need to be some added means of
  929. ensuring the reliability of embedded systems and the integrity of the
  930. systems as they leave the factory. These means may include:
  931.  
  932. Requirements
  933.  
  934.     Development of methods of testing that enable standards of
  935.     reliability to be ensured, including tests to destruction where
  936.     appropriate
  937.  
  938.     Development of an approach for the certification of samples
  939.  
  940.     Definition of requirements for fail-safe system architectures
  941.     and implementations
  942.  
  943.     Definition of anti-tampering and protection specifications and
  944.     standards.
  945.  
  946. 5.    Demand related issues
  947.  
  948. 5.1.    Agreement on security requirements for enterprises
  949.  
  950. Issue
  951.  
  952. Identification of real world security requirements and objectives for
  953. business and administration.
  954.  
  955. Discussion
  956.  
  957. The protection of information systems must be all embracing.
  958. Consideration must be given to requirements from the view point of the
  959. enterprise, taking into account corporate and organisation plans, goals
  960. and strategies of the business or administration. Requirements at this
  961. level can be then translated into "Security Objectives" - why the
  962. security functionality is required as it applies to the operation of
  963. the business or administration environment.
  964.  
  965. These security objectives need then to be supported by a definition of
  966. the security functionality and related services required necessary to
  967. support the user/business.
  968.  
  969. The security model has not included legal, accounting or regulatory
  970. requirements which may be imposed upon enterprises rather than forming
  971. any integral part of the Enterprise requirements.
  972.  
  973. Given the complexity and diversity of user/enterprise requirements for
  974. such protection it is necessary to classify the requirements in some
  975. structured way consistent with real world business and operational
  976. environments.
  977.  
  978. The protection of information systems needs to consider the enterprise
  979. requirements of the "business". These requirements not only include
  980. functionality that is "owned" by the enterprise but must include
  981. inter-enterprise requirements as well. It must consider the
  982. functionality and assurance of IT building blocks, end user
  983. applications, integration enablers (such as electronic mail), operating
  984. systems, communication services and protocols, and basic hardware and
  985. software platforms.
  986.  
  987. The balance of functionality (what it does) and assurance (how well it
  988. does it), both generic and application specific, will determine the
  989. extent to which electronic information systems are accepted as an
  990. integral part of both the public and corporate IT infrastructure to
  991. underpin business actions.
  992.  
  993. The prime requirement for any secure system must be a set of
  994. architectural principles that can be effectively translated into an
  995. overall design framework. Secure systems must be created at different
  996. "grades of assurance" from a set of policies, standards and
  997. procedures.
  998.  
  999. Specific security requirements relating to open systems will come from
  1000. a threat assessment and risk analysis which will form part of the
  1001. overall system security policy process.
  1002.  
  1003. The cost of security is an integral part of the cost of ownership of an
  1004. IT system ie namely that without security the users system is at risk.
  1005. The cost of protection against breaches of security needs to be
  1006. commensurate with the costs (both direct and indirect) that may be
  1007. incurred from a breach in security. A security breach may have short
  1008. term (and perhaps, localised) implications such as loss of sales and
  1009. revenue or fraud. It may also have longer term (and wider) impacts on
  1010. business communities through loss of confidence and consequential loss
  1011. of business.
  1012.  
  1013. The costs of detection, resistance and recovery can be both tangible
  1014. and high, and although there are techniques available to quantify risks
  1015. there are no generally applicable methods for estimating the potential
  1016. costs arising for example from denial of service or loss of integrity.
  1017. The provision of security measures may also make it harder to use and
  1018. may constrain overall performance. However, where the security risk is
  1019. high enough to cause an unacceptable level of compromise, leading to
  1020. considerable commercial and financial loss, then security measures must
  1021. be given high priority commensurate with the nature and value of the
  1022. business in question. Sectoral requirements vary widely, as do
  1023. requirements by size of enterprise within a sector.  Sectoral
  1024. requirements may be varied by regulation, bilateral international
  1025. agreements, general trading agreements or conventions.
  1026.  
  1027. Increased demand for Electronic trading from all kinds of businesses,
  1028. both public and private sector, will place requirements for security on
  1029. the communal service infrastructure that provides the capability for
  1030. such business activities. The regulatory and legal environment within
  1031. which such service organisations work will become a factor for economic
  1032. growth in the community, and security of service provision an element
  1033. of such services.
  1034.  
  1035. Requirements
  1036.  
  1037.     Development of a taxonomy and directory of user requirements
  1038.     and security objectives derived from real world business
  1039.     applications.
  1040.  
  1041. 5.2.    Agreement on security requirements for individual users
  1042.  
  1043. Issue
  1044.  
  1045. Identification of security requirements and objectives for individual
  1046. users.
  1047.  
  1048. Discussion
  1049.  
  1050. The individual user, in their role as a private citizen or as a member
  1051. of a liberal profession (eg a lawyer or medical doctor), has a natural
  1052. interest, and sometimes a legal requirement, to protect some of their
  1053. information. Unlike in the case of the enterprise, the individual user
  1054. will not normally go through a systematic process of establishing
  1055. goals, definition of security objectives, etc, unless they are subject
  1056. to professional standards of conduct.
  1057.  
  1058. The individual normally has at his disposal a PC (or small network of
  1059. PCs) and some communication links, eg telephone, fax, e-mail. Physical
  1060. security is likely to be weak.
  1061.  
  1062. Most liberal profession work under some codes of practice or conduct.
  1063. These codes are of a general nature and do not normally specify
  1064. particular security arrangements.
  1065.  
  1066. The common and specific requirements of individual users, with regard
  1067. to the protection of their computer installation (physical and
  1068. electronic), the protection of their data (against accidental and
  1069. deliberate loss) and the protection of their communications (eg signed
  1070. communications, privacy enhanced communications) must be established.
  1071.  
  1072. Requirements
  1073.  
  1074.     Development of user profiles identifying standard types of
  1075.     users together with typical requirements.
  1076.  
  1077. 5.3.    Security objectives for enterprises
  1078.  
  1079. Issue
  1080.  
  1081. Definition of Security Objectives for enterprises.
  1082.  
  1083. Discussion
  1084.  
  1085. Security objectives are related to confidentiality, integrity,
  1086. availability, legality and auditability. Controls are related to
  1087. segregation of duties and methods for obtaining independent audit of
  1088. the achieved results of an Information System.  Controls may also
  1089. relate to the reasonableness or plausibility of information or an
  1090. activity.
  1091.  
  1092. A security objective is a description of what security the enterprise
  1093. is trying to achieve eg why this security control/function is wanted.
  1094. It is a mission statement of the user/enterprise which describes why an
  1095. aspect of security is needed. It is a user/business target or purpose
  1096. to which security is being addressed. For example, consider the subject
  1097. of data integrity and the objective "Prevent unauthorised modification
  1098. to data". The security objective has the objective "Appropriate
  1099. mechanisms should exist to preserve the integrity of data". For example
  1100. this may be related to data held on a medical database, on a company
  1101. financial database, in airline reservation system or a geography
  1102. information system.
  1103.  
  1104. Security objectives are thus concerned with the preservation of
  1105. information with regard to its utility, availability, authenticity,
  1106. integrity and confidentiality within the enterprise and between
  1107. enterprises or concerned with some user environment. These are
  1108. dependent upon more detailed definitions of business control being
  1109. made. The structure and organisation of the specialist accounting
  1110. functions in a business are examples of business controls.
  1111.  
  1112. The organisation of security within enterprises in terms of business
  1113. control structures or in the case of some user environment (eg legal,
  1114. accounting, audit etc) and functions (eg IT, human resources,
  1115. insurance) needs to be integrated with a set of security policies,
  1116. standards (both public and in-house), and made compliant with laws and
  1117. regulations (eg computer crime manual), guidelines and codes of
  1118. practice etc.
  1119.  
  1120. The process of producing a security policy requires the use of a set of
  1121. security methodologies, tools and evaluation criteria. For example risk
  1122. analysis methods, baseline controls, and evaluation criteria (eg ITSEC,
  1123. Federal Criteria etc.).
  1124.  
  1125. Security objectives thus encompasses a set of objectives (and possibly
  1126. sub-objectives) and a set of related issues that reflect specific
  1127. points of concern, problems, questions relative to business
  1128. requirements, controls and applications.
  1129.  
  1130. The diagram below shows the relationship between Security objectives,
  1131. Security organisation, and Security methodologies. Laws apply to the
  1132. user environment directly.  Their presence generates some of the
  1133. security objectives.  Standards may be both mandatory and
  1134. discretionary, and may incorporate methodologies.  The final box covers
  1135. security methods and techniques.
  1136.  
  1137. 5.4.    Sectoral specifics
  1138.  
  1139. Issue
  1140.  
  1141. Beyond the normal requirements common to different business sectors and
  1142. user environments there may also be additional requirements and
  1143. priorities specific to the operational nature and commercial mission of
  1144. a particular business. These specific requirements can be normally
  1145. expressed in terms of codes of practice and baseline controls.
  1146.  
  1147. Discussion
  1148.  
  1149. Legal and regulatory provisions can be supported by Codes of Practice
  1150. to achieve due care and diligence. There are those of general
  1151. application and those that are industry specific. A general Code of
  1152. Practice may achieved by  the establishment of a security management
  1153. handbook, maybe based upon the approach taken for achieving a Quality
  1154. code of practice (ISO9000). The application of IS is a prerequisite for
  1155. the successful conduct of business for particular sectors, especially
  1156. when these sectors a highly interactive. The most prominent among them
  1157. are:
  1158.     Finance
  1159.     Trade
  1160.     Medical
  1161.     Telecommunications
  1162.     Administrations.
  1163.  
  1164. Requirements
  1165.  
  1166.     Development of a set of codes of practice and baseline controls
  1167.     addressing specific business sector requirements.
  1168.  
  1169. 5.5.    Security methodologies 
  1170. Issue
  1171.  
  1172. Selection of security requirements analysis methodologies (eg risk
  1173. analysis methods, codes of practice etc.) and related safety hazard
  1174. analysis methods relevant and applicable to the user/enterprise
  1175. business policies and controls.
  1176.  
  1177. Discussion
  1178.  
  1179. Any security policy formulation must derive its requirements statement
  1180. from an assessment of the potential threats against the business and
  1181. the supporting service infrastructure of the IT and telecommunication
  1182. processes. This will allow an eventual implementation with clearly
  1183. understood trade-offs, administrative and technical measures against
  1184. human malefactors, and a balance between security cost and level of
  1185. operational fitness; these are components of a Risk Management
  1186. strategy. The risk management strategy on a European level should be
  1187. based on a rigorous and consistent approach to the analysis of the
  1188. threats to and vulnerabilities of the system and its components, and
  1189. where appropriate safety hazards. This approach should be based as far
  1190. as possible on existing, and, possibly, standardised, risk/hazard
  1191. analysis modelling techniques and products. The issues include:
  1192.  
  1193.     adequacy of present risk assessment techniques
  1194.  
  1195.     awareness about current trends, and modelling
  1196.  
  1197.     awareness of the responsible security officers about security 
  1198.  
  1199.     security breach incidents
  1200.  
  1201.     safety hazards as they impact on or are related to the security
  1202.     of a system and vice versa.
  1203.  
  1204. Requirements
  1205.  
  1206.     Development of evaluation criteria and guidelines applicable to
  1207.     the selection of security requirements analysis methodologies
  1208.     (eg risk analysis and management methods, products etc)
  1209.  
  1210.     Harmonisation and standardisation of a European and
  1211.     international approach
  1212.  
  1213.     Integration of security and safety methodologies where
  1214.     appropriate to provide a coherent framework for the analysis of
  1215.     assured systems.
  1216.  
  1217. 5.6.    Security domains
  1218.  
  1219. Issue
  1220.  
  1221. Openness and protection.
  1222.  
  1223. Discussion
  1224.  
  1225. In practice, the level of IS is dynamically adapted to a given
  1226. situation. This leads to the concept of Dynamic IS Management and the
  1227. need to be able to define domains, in which IS is applied
  1228. homogeneously.
  1229.  
  1230. Security Domain Concept
  1231.  
  1232. Domains are user groupings sharing some of their functions and support.
  1233. For some activities they operate as virtually closed user groups, but
  1234. have the possibility to interwork with other domains as long as certain
  1235. minimum requirements ensure no loss of trust or a transparent
  1236. downgrading.
  1237.  
  1238. The notion of a security domain is therefore important for two reasons.
  1239. Namely,
  1240.     It can be used to describe how security is managed and administered, and
  1241.     It can be used as a building block in modelling security
  1242.     relevant activities that involve elements under distinct
  1243.     security authorities.
  1244.  
  1245. Examples of domain activities are:
  1246.  
  1247.     accesses to elements (eg a database for network management)
  1248.     a communications link
  1249.     operations relating to a specific management function
  1250.     non-repudiation operations involving a notary.
  1251.  
  1252. Security Policy
  1253.  
  1254. The organisation of security within enterprises in terms of business
  1255. control structures or in the case of some user environment (eg legal,
  1256. accounting, audit etc) and functions (eg IT, human resources,
  1257. insurance) needs to be supported by a set of security policies,
  1258. standards (both public and in-house), laws and regulations (eg computer
  1259. crime manual), guidelines and codes of practice etc.
  1260.  
  1261. The security policy defines what is meant by security within the
  1262. domain, the rules by which security may be obtained to the satisfaction
  1263. of the security authority, and the activities to which it applies. The
  1264. security policy may also define which rules apply in relations with
  1265. other security domains in general, and in relations with particular
  1266. other security domains.
  1267.  
  1268. Requirements
  1269.  
  1270. The management of inter-domain openness and protection may be different
  1271. depending on similarities in purpose, and agreements will be needed to
  1272. achieve appropriate levels of assurance. Mechanisms by which TTPs
  1273. achieve efficient, coherent management of policies, procedures and
  1274. controls between domains need development:
  1275.  
  1276.     generation of guidelines for domain creation, management and
  1277.     control
  1278.  
  1279.     development of a common framework for domain interworking
  1280.  
  1281.     agreement on management, TTPs, accreditation, auditing and
  1282.     relations with law enforcement agencies.
  1283.  
  1284. 5.7.    Information labelling
  1285.  
  1286. Issue
  1287.  
  1288. Transfer of information between domains requires agreement on the
  1289. syntax and semantics of information labels, and of the procedures and
  1290. mechanisms for handling labelled information.
  1291.  
  1292. Discussion
  1293.  
  1294. The information label is a short hand way of expressing the protective
  1295. measures that should be applied to the labelled information.
  1296.  
  1297. Information labelling is an essential part of ensuring that information
  1298. objects receive the appropriate level of security protection both
  1299. within and between security domains.
  1300.  
  1301. Trust between organisations depends on the assurance that information
  1302. will be handled in a way consistent with its security requirement in
  1303. terms of confidentiality, integrity, availability and non-repudiation.
  1304.  
  1305. The need for comprehensive labels has become acute because of the
  1306. increasing degree to which organisations interoperate electronically.
  1307. This has led to increased reliance on technical measures to achieve
  1308. adequate security. It is quite feasible for trusted systems to switch
  1309. on or off technical measures automatically providing that the label
  1310. adequately expresses the security requirement associated with a piece
  1311. of information. Labels could then be used to make decisions on
  1312. information routing, transmission enveloping, requirements for
  1313. confirmation and so on.
  1314.  
  1315. Organisations have to agree on the range of options that do meet any
  1316. particular security requirement. Part of the solution to the handling
  1317. of labelled information lies in the development of Codes of Practice
  1318. specifying procedures and mechanisms. There is also a need for
  1319. accreditation and audit of communicating partners. The introduction of
  1320. independent third parties avoids the pairwise interactions that would
  1321. otherwise be necessary to establish trust.
  1322.  
  1323. Requirements
  1324.  
  1325.     Code of Practice for information labelling.
  1326.  
  1327. 5.8.    Access control and authenticity issues
  1328.  
  1329. 5.8.1.    Access control
  1330.  
  1331. Issue
  1332.  
  1333. Access control procedures to many systems are not standardised or well
  1334. managed.
  1335.  
  1336. Discussion
  1337.  
  1338. Computer systems and services impose control procedures on persons (or
  1339. other systems) attempting to access them directly or over local or
  1340. wide-area networks. These access control procedures apply to
  1341. "connections"; that is, they determine whether or not a connection,
  1342. association or session is allowed to be established. These control
  1343. procedures have been often primitive and relatively insecure, as the
  1344. occurrence of "hacking" demonstrates. For example, the only protection
  1345. afforded may be by a password, transmitted over the network "in clear"
  1346. so that any wiretapper with physical or electro-magnetic access can
  1347. read it.
  1348.  
  1349. The requirement for secure access control is not confined to access to
  1350. host computers by persons at terminals. Reciprocal (mutual) access
  1351. control is often needed between two (or sometimes more) systems. Access
  1352. control can apply across general telecommunication networks,
  1353. determining (for example) who may call whom by telephone; or who may
  1354. receive which programme on a cable TV network. In addition to applying
  1355. to end-to-end (trans-network) communications, access control also
  1356. applies to users and (even more importantly) operators accessing the
  1357. network and to access by human users to terminal devices.
  1358.  
  1359. Although the importance of access control is widely recognised, the
  1360. practical application of security techniques to solving the problem is
  1361. more limited. This is for a variety of reasons including technical
  1362. complexity, lack of agreed standards, lack of user acceptability and
  1363. lack of supporting infrastructure (such as TTPs).
  1364.  
  1365. Secure access control relies on a mixture of:
  1366.  
  1367.     identification mechanisms (authentic naming) identifying the
  1368.     remote person or system
  1369.  
  1370.     authorisation mechanisms, determining the authority of the
  1371.     remote person or system to carry out different types of actions
  1372.  
  1373.     random (unpredictable) components, affording protection against
  1374.     the re-use of once-valid access control messages under invalid
  1375.     circumstances (replay)
  1376.  
  1377.     cryptographic techniques to protect the above from
  1378.     modification, copying, etc.
  1379.  
  1380. Without some analysis of access control scenarios, followed by some
  1381. outline standardisation work, users and systems are going to find
  1382. themselves having to implement and use (depending on their current
  1383. application) a range of incompatible techniques, which in turn rely on
  1384. only partially interoperable infrastructures (such as naming and
  1385. identification authorities, certification authorities, key management
  1386. systems, directory services, etc.).
  1387.  
  1388. Requirements
  1389.  
  1390. There is a need for widely accepted solutions to the most common access
  1391. control scenarios. There is a need to:
  1392.  
  1393.     identify and group access control scenarios, to determine
  1394.     levels of commonality
  1395.  
  1396.     identify techniques, products, specifications and standards
  1397.     addressing access control, and associate them with the
  1398.     identified scenarios
  1399.  
  1400.     identify parameters common to most or all of the above
  1401.     techniques, products, specifications and standards and
  1402.     investigate the feasibility of establishing common formats for
  1403.     them
  1404.  
  1405.     identify the key features for coherence in the supporting
  1406.     infrastructure
  1407.  
  1408.     define a limited number of basic access control mechanisms for
  1409.     pilot implementation.
  1410.  
  1411. 5.8.2.     The individual right to signature 
  1412.  
  1413. Issue
  1414.  
  1415. Individuals have the right to sign any information.
  1416.  
  1417. Discussion
  1418.  
  1419. Like with hand-written signatures, anybody is entitled to use a digital
  1420. signature. Therefore, the distribution of keys for the purpose of
  1421. signature must be non-discriminatory and non-restrictive. Separate from
  1422. the signature is the question of authority, ie if a certain person is
  1423. entitled to sign a certain element of information, document or
  1424. transaction.
  1425.  
  1426. Signature verification is therefore a two step process: formal
  1427. verification of the signature and verification of the authority of the
  1428. sender. This process is depicted below.
  1429.  
  1430. It is assumed in this simple model, that the sender adds his
  1431. certificate (name plus his public key) to the signed document. The
  1432. formal verification then establishes that a person with a certain name
  1433. has correctly applied his signature and that the document has not been
  1434. modified in transfer. Verification of authority checks that the name
  1435. has the legal authority to sign a particular document.
  1436.  
  1437. Note that as a consequence, the authority given to a person should not
  1438. be included in the attributes of the certificate, otherwise any change
  1439. in authority would invalidate the certificate.
  1440.  
  1441. The situation maybe further complicated by the fact that several
  1442. signatures maybe required for certain documents, eg husband and wife
  1443. plus notary, two company directors.
  1444.  
  1445. Requirements
  1446.  
  1447.     Clarification of the right to signature and the attached authority.
  1448.  
  1449. 5.8.3.    Consistency of legal principles
  1450.  
  1451. Issue
  1452.  
  1453. The legal functions have to be clearly identified for the authority of
  1454. digital signatures, before a code-of-practice can be developed and
  1455. introduced.
  1456.  
  1457. Discussion
  1458.  
  1459. In legal practice security and functional requirements for hand-written
  1460. signatures differ widely. In some cases a hand-written signature is
  1461. only to indicate that the signer has concluded his train of thought or
  1462. his expression of will; under the given circumstances its authenticity
  1463. may be obvious and need not be provable. In other cases, for evidence,
  1464. the signature must be provably authentic. In yet other cases
  1465. authenticity requirements may demand attestation or even ask for more
  1466. than one person's signature or for public notification.
  1467.  
  1468. The spectrum of legal requirements can be matched by the spectrum of
  1469. technical realisations which may differ with respect to security
  1470. provisions just as widely as legal requirements. Yet the signing
  1471. process must be transparent to the signer. For this reason it must
  1472. follow standardised rules; specific man-machine interfaces must be
  1473. familiar to the signer; i.e. they must follow a standardised layout
  1474. principle.
  1475.  
  1476. For ease of transition (in judicial thinking) from hand-written to
  1477. digital signatures traditional functional requirements for hand-written
  1478. signatures should be met by the technical implementation of digital
  1479. signatures as closely as possible.
  1480.  
  1481. A particular problem is the validity period of a digital signature. One
  1482. must distinguish the validity period of the signature itself and the
  1483. validity period of the authorisation.
  1484.  
  1485. The validity period of the digital signature itself may have to be
  1486. limited for technical reasons. These reasons include:
  1487.  
  1488. 1.      Insufficient key length. One may discover that some years from
  1489. now, new progress in mathematics and technology makes it plausible that
  1490. keys of the originally chosen limited length can be broken. (For
  1491. instance, several European banks have introduced remote banking with
  1492. RSA keys of length 512 bits. One cannot guarantee that this will be
  1493. safe in 10 years, or even less, from now.)
  1494.  
  1495. 2.      Poor key generation. One cannot be sure that programs at the
  1496. desired quality level will be used by all key management centres. Hence
  1497. users of those key management centres may find that their keys are
  1498. breakable, and they have to cancel their certificates.
  1499.  
  1500. 3.      Weak protection of workstation. The secret key of a user may be
  1501. compromised accidentally or through negligence. It may also be possible
  1502. to tap the password of a user through a Trojan horse on his PC and
  1503. subsequently get access to the secret key. (Fraudulent users may even
  1504. claim this happened, and give away their key on purpose, in order to
  1505. dispute that a certain signature did originate from them.)
  1506.  
  1507. Taking the necessary precautions, and taking a differentiated approach
  1508. to the validity period of signatures, then most digital signatures
  1509. would fall inside the scope of applicability of hand written signatures
  1510.  
  1511. The authority attached to a signature normally changes much faster. The
  1512. authority given to a person should therefore not be included in the
  1513. attributes of the certificate, otherwise any change in authority would
  1514. invalidate the certificate.
  1515.  
  1516. However, in all the work that has been carried out so far, there is no
  1517. solution offered to the following problem: If messages have been signed
  1518. with a key and needs to be kept for a number of years, and that key is
  1519. denounced by the user as being compromised, how can the value of the
  1520. already calculated signature be left intact? One possibility might be
  1521. to use a TTP for time stamping, but further study into this problem
  1522. seems in place. An example may illustrate this point.
  1523.  
  1524. If a user A signs a message in 1993, which has legal consequences to
  1525. user B until 2003, and A then cancels his certificate in year 1995,
  1526. claiming that his key has been compromised, he will probably claim that
  1527. the signed document from 1993 was falsified in 1995 by B, who could
  1528. have bought a copy of A's secret key. However, if B upon receipt in
  1529. 1993 had gone to a TTP and had the signature of A time stamped and
  1530. signed by the TTP, or even registered, he can prove that A in fact did
  1531. produce the said signature back in 1993.
  1532.  
  1533. For some sectors and/or applications the granularity of the time
  1534. stamping will be critical. It is conceivable that trusted time down to
  1535. one second accuracy will be needed.
  1536.  
  1537. Requirements
  1538.  
  1539.     The legal functions of signatures need to be agreed
  1540.     EC-wide/internationally. Once this is achieved, it is possible
  1541.     to determine to what extent a code-of- practice will suffice.
  1542.     One issue to be addressed is the intended use of the digital
  1543.     signature, and the legal responsibility and liability of the
  1544.     signing entity with regard to the signed information.
  1545.  
  1546.     Clarification of the conditions of acceptance of the authority
  1547.     of an digital signature, eg for legally binding purposes, ie as
  1548.     substitute for hand-written original signatures.
  1549.  
  1550.     Recommendation for the implementation for a public digital
  1551.     signature scheme for use by business, administrations and the
  1552.     general public.
  1553.  
  1554.     Legislative rules and, where appropriate, liabilities, for
  1555.     keys, certificates and TTPs need to be developed to cover
  1556.     revocation of any or all the entities involved in the "chain of
  1557.     proof" needed in the signature technique.
  1558.  
  1559. 5.8.4.    Signature schemes 
  1560.  
  1561. Issue
  1562.  
  1563. Introduction of an international digital signature and identification
  1564. schemes.
  1565.  
  1566. Discussion
  1567.  
  1568. Open communication requires standardised publicly available algorithms.
  1569. It is possible, however, to develop a scheme for digital signatures, to
  1570. get laws, regulations or directives in place, to develop supporting
  1571. profile standards and to develop fully implementable models for TTPs,
  1572. without specifying in detail the underlying algorithms.
  1573.  
  1574. The characteristics required of a digital signature mechanism include
  1575. that it
  1576.  
  1577.      is practically unbreakable
  1578.  
  1579.     has a sufficiently large key space, performance (time and space
  1580.     requirements for signing and verification), reasonable size of
  1581.     key, etc.
  1582.  
  1583.     includes key generation.
  1584.  
  1585. In order to allow for world-wide, unrestricted use of a digital
  1586. signature scheme, the mechanism should not be usable for the
  1587. concealment of message content.
  1588.  
  1589. The minimum requirement should include
  1590.  
  1591.     an estimate of error probability if probabilistic methods are used
  1592.  
  1593.     an estimate of probability of occurrence of weak keys (perhaps
  1594.     completely improbable)
  1595.  
  1596.     a guarantee of sufficiently high degree of uniform
  1597.     distribution.
  1598.  
  1599. In so-called identification schemes (for access control), which do
  1600. require public key techniques rather than conventional schemes,
  1601. practical zero-knowledge protocols must be developed and standardised
  1602. that fit a corresponding digital signature standard.
  1603.  
  1604. Requirements
  1605.  
  1606.     Development of specifications and standards along the lines
  1607.     described above
  1608.  
  1609.     Development of specifications and standards for application
  1610.     oriented integration
  1611.  
  1612.     Development of a general application programming interface
  1613.     (API) for integration of security services which could be
  1614.     easily integrated into most application (This could as well
  1615.     include codes which explain the intention of the applied
  1616.     signature.)
  1617.  
  1618.     Development of transaction-oriented multiple signature schemes
  1619.  
  1620.     Solution to the specification, standardisation and licensing
  1621.     problem of cryptographic algorithms.
  1622.  
  1623. 5.8.5.    Key usage
  1624.  
  1625. Issue
  1626.  
  1627. Digital signatures imply the specification of a full set of procedures
  1628. dealing with the three phases of key management - user enrolment, key
  1629. and certification distribution, and operational maintenance
  1630. (revocation, blacklist, destruction), which must be agreed and
  1631. accepted.
  1632.  
  1633. Discussion
  1634.  
  1635. In order to apply security to any message or process, four logical
  1636. layers are relevant:
  1637.  
  1638. 1.    Legal intentions and implications
  1639.  
  1640. 2.      The definition and identification of the relevant security
  1641.     service to be applied.
  1642.  
  1643. 3.    The underlying mechanisms.
  1644.  
  1645. 4.    The algorithm and protocols.
  1646.  
  1647. Without standardising or agreeing on the 4th layer, it will not be
  1648. possible to communicate.
  1649.  
  1650. In order to adopt electronic versions of negotiable and
  1651. quasi-negotiable documents, such as bills of lading, new security
  1652. services have been identified to meet business requirements, in
  1653. particular claim of ownership for exchange of values. This needs to go
  1654. through a standardisation process.
  1655.  
  1656. But also for more " classical" services, the current standards do not
  1657. reflect the granularity of eg non-repudiation needed by business
  1658. requirements. ISO 7489-2 only addresses non-repudiation of origin and
  1659. delivery (sometimes called receipt). However, one needs at least
  1660. origin, submission, delivery and receipt, where submission and delivery
  1661. would correspond to the services required when a registered letter is
  1662. mailed.
  1663.  
  1664. For hand-written signatures , a person typically knows what he is
  1665. signing, which is important for legal implications. This is not so easy
  1666. to achieve with electronic data. In particular it must be clarified to
  1667. what extent the system must indicate to the user what he is actually
  1668. signing.
  1669.  
  1670. Requirements
  1671.  
  1672.     Develop standards and profiles as described above, especially
  1673.     the development of profile - or functional - standards to
  1674.     support CCITT X.509.
  1675.  
  1676. 5.8.6.    Universal acceptance
  1677.  
  1678. Issue
  1679.  
  1680. For digital signatures to become a full alternative to hand-written
  1681. signature universal acceptance is required.
  1682.  
  1683. Discussion
  1684.  
  1685. All functions of the hand-written signature should also apply to
  1686. digital signatures.
  1687.  
  1688. Where legal functions are carried out by digital signature, consensus
  1689. with the legal profession is essential.
  1690.  
  1691. Requirements
  1692.  
  1693.     Development, together with the legal profession, of
  1694.     recommendations for the practical use of digital signatures as
  1695.     a full equivalent to hand-written signatures in legal
  1696.     transactions
  1697.  
  1698.     Demonstration, through pilot projects, that digital signatures
  1699.     can be used as equivalent to hand-written signatures
  1700.  
  1701.     Inclusion in the curriculum of relevant educational institutes
  1702.     (eg engineering, law and business schools) the use of digital
  1703.     signature.
  1704.  
  1705. 5.8.7.    Security of electronically stored  information
  1706.  
  1707. Issue
  1708.  
  1709. As legally and commercially significant information is transferred and
  1710. stored electronically, the implications of this on long-term (10's of
  1711. years) secure storage and retrieval must be properly understood.
  1712.  
  1713. Discussion
  1714.  
  1715. Industry is moving increasingly towards electronic trading in all its
  1716. aspects. Governments are encouraging the use of electronic
  1717. communication of commercially and legally significant information. As a
  1718. result, there is a need both to establish irrefutably the origin of,
  1719. and the delivery of, such information and, particularly, that the
  1720. information has been signed and stored in an unforgeable way. This
  1721. unforgeable electronic signature must be trusted for at least 10's of
  1722. years for some information, and the associated information must be
  1723. retained in a secure manner that is capable of human interpretation at
  1724. any time during that period. Any system proposed for electronic
  1725. signature storage must be as secure and robust as that currently used
  1726. for hand-written signatures.
  1727.  
  1728. Any such system must allow for not just technical evolution, but also
  1729. social change and other factors (e.g. the continued existence of
  1730. trusted public key directory centres, or the way businesses merge,
  1731. change or collapse).It is not currently clear that the way this can be
  1732. achieved is yet accepted legally, or the full implications are even
  1733. properly understood.
  1734.  
  1735. Requirements
  1736.  
  1737.     Build on the digital signature experience to consider the
  1738.     long-term implications of the unforgeable secure storage and
  1739.     retrieval of legally and commercially significant information,
  1740.     with access by any authorised person or organisation
  1741.     internationally.
  1742.  
  1743. 5.9.    Privacy enhancement issues
  1744.  
  1745. 5.9.1.    Perception of requirements for privacy enhancement
  1746.  
  1747. Issue
  1748.  
  1749. Confidentiality is, at times, essential for the good functioning of
  1750. administrations, business and human relations.
  1751.  
  1752. Discussion
  1753.  
  1754. Business user of telecommunications and information systems cannot
  1755. obtain full business benefit without confidentiality services being
  1756. available. There is a clear need for confidentiality services in the
  1757. exchange of information in the business as well as in the private use.
  1758. Today the exchange of sensitive information requiring confidentiality
  1759. is often done in non-electronic form because for electronic
  1760. transmission "confidentiality" is either not available or its use not
  1761. permitted. With the increasing demand for fast exchange of all kind of
  1762. data, demand for "confidentiality" will become pressing.
  1763.  
  1764. Most business and private users of communication systems are aware of
  1765. the conflict between their confidentiality requirements and national
  1766. security issues which require the possibility to intercept the
  1767. communication in a way regulated by national laws. They accept the
  1768. national authorities ability for this interception provided there are
  1769. adequate safeguards to prevent unauthorised interception even by
  1770. government employees.
  1771.  
  1772. Expectations of confidentiality of electronic message services can
  1773. currently not be met in the absence of international standards or
  1774. internationally accepted methods. Uptake of these services by
  1775. commercial users to support business processes will therefore have a
  1776. natural limit, ie to those messages that someone usually writes on a
  1777. postcard. Examples of commercially sensitive information includes
  1778. pricing and bidding strategies, mergers and take-overs, or from a
  1779. privacy point of view (transmission of personnel and medical data).
  1780.  
  1781. User needs for confidentiality
  1782.  
  1783. In analogy with confidentiality offered by existing physical mail and
  1784. archiving services, ie envelopes, registration, courier services, etc.,
  1785. there is a need for confidentiality in the situation of electronic
  1786. interchange and storage of data. Even more so because electronic data
  1787. can much more easily be copied or disclosed in its usual form, eg only
  1788. channel coding and formatting as the "envelope", than its physical
  1789. counterpart.
  1790.  
  1791. At present certain unclassified but sensitive information on physical
  1792. media such as paper, microfilm, or photograph, of business enterprises
  1793. or medical centres are protected against unauthorised disclosure by
  1794. physical and procedural methods.
  1795.  
  1796. Today the trend is towards more electronic communication and storage of
  1797. data and hence there is a need for appropriate confidentiality services
  1798. in an agreed or standardised form to be readily available for all users
  1799. of electronic information systems.
  1800.  
  1801. Service provision
  1802.  
  1803. The extent to which confidentiality services are provided for a
  1804. specific business or citizen could depend on a system of licenses or
  1805. certificates.
  1806.  
  1807. A particular business might qualify for a confidentiality license
  1808. depending on its internal procedures and activities. A general
  1809. (minimum) level of confidentiality could be provided to all users.
  1810.  
  1811. It should be possible for certain user groups or businesses to use
  1812. other confidential services (egproprietary) than the standard ones
  1813. provided.
  1814.  
  1815. There are strong indications of emerging "bottom up" solutions for
  1816. these needs (eg the Pretty Good Privacy offering on Internet, beginning
  1817. 1993).
  1818.  
  1819. Other initiatives (eg the announcement of the "Clipper Chip", 16April
  1820. 1993) illustrate the growing awareness of governments of the needs of
  1821. their citizens for confidentiality services.
  1822.  
  1823. Awareness 
  1824.  
  1825. In general users of electronic data processing systems are not aware of
  1826. the threats involved in using those systems. Only after they have
  1827. noticed (the consequences of) an unwanted or unauthorised disclosure of
  1828. their information will they start to think of the inherent
  1829. vulnerability of the system they are using. In view of this one should
  1830. try to create more security awareness. Users, service providers,
  1831. operators and authorities should achieve a certain minimum level of
  1832. awareness of the issues involved in using confidentiality services
  1833. before embarking on their use.
  1834.  
  1835. Granularity (meeting differentiated needs)
  1836.  
  1837. Confidentiality services at different granularity and for different
  1838. types of telecommunication services are needed. Based on his risk
  1839. analysis the user can then decide which level of confidentiality he
  1840. needs and then use the services which provides this required level.
  1841.  
  1842. Some users may want a range of services of different assurance levels
  1843. (analogy of courier services, registered mail, ordinary mail). Some
  1844. users may want visibility of assurances to different extents.
  1845.  
  1846. Impact of loss of information and Impact of theft of information
  1847.  
  1848. By its nature, actual risks and impacts of disclosure are hard to
  1849. quantify. But the absence of a baseline of protection of
  1850. confidentiality will undoubtedly have a negative impact on commercial
  1851. (and other) usage of international electronic communications in a wide
  1852. range of business processes.
  1853.  
  1854. Actors and roles
  1855.  
  1856. Individuals may have a number of roles in more than one organisation -
  1857. these need defining or clarifying. Their "role" as a private citizen is
  1858. an important case. The organisations that act as custodians of roles
  1859. need to be classified also. These are essential ingredients for domain
  1860. management.
  1861.  
  1862. Mutual confidence and TTPs
  1863.  
  1864. Users and mechanisms to ensure that they get assurance of compliance to
  1865. agreed "rules of procedure" from their trading partners, or other
  1866. private citizens, with whom they are interacting using confidentiality
  1867. services. TTPs are one mechanism for achieving this, but other lower
  1868. assurance, lower cost solutions may also need to be considered.
  1869.  
  1870. Requirements
  1871.  
  1872.     Proposal for a frameworks and architectures which are accepted
  1873.     as well by the business users as by the national security
  1874.     agencies and the service providers
  1875.  
  1876.     Standards for services and service provision. Ensure that the
  1877.     confidentiality services are compatible with existing
  1878.     communication standards and practices where possible
  1879.  
  1880.     Verification of practicability of proposed solutions through
  1881.     suitable pilot projects
  1882.  
  1883.     Model contracts for confidentiality services
  1884.  
  1885.     Awareness of sector actors of the potential losses due to the
  1886.     absence of confidentiality services.
  1887.  
  1888. 5.9.2.    The case for the provision of public confidentiality services
  1889.  
  1890. Issue
  1891.  
  1892. The provision of public confidentiality services have to reconcile the
  1893. needs of the business sector and general public with the obligation of
  1894. public authorities to provide adequate protection while at the same
  1895. time maintaining its capability to fight organised crime, maintain
  1896. public order and national security.
  1897.  
  1898. A well developed public confidentiality service would provide for the
  1899. obligations in a transparent manner.
  1900.  
  1901. Discussion
  1902.  
  1903. Business operates increasingly in an international and open
  1904. environment. The communications take place via private and public
  1905. networks. Modern network management techniques use alternative routing
  1906. depending on traffic conditions. This implies that the physical
  1907. communication is under the control of a variety of intermediaries
  1908. working under different regulatory and legal conditions for data
  1909. protection and privacy, and therefore one must consider the network as
  1910. inherently risky. This means that end-to-end protection is required.
  1911. This applies also to the general public using international public
  1912. telephone networks.
  1913.  
  1914. It is a fact that business and the general public have been addressing
  1915. their needs with public domain solutions (published algorithms and
  1916. freely available software). However, the approach is awkward and its
  1917. utility therefore limited, since, for example, there is no public
  1918. directory and he has to manage the keys himself. A public solutions
  1919. open to all users requiring electronic signature and confidentiality
  1920. would remove the need for the use of ad hoc solutions. It would also
  1921. provide for a transparent solution to the need for legally authorised
  1922. intercepts.
  1923.  
  1924. If a public confidentiality scheme is offered, organised crime could
  1925. also subscribe to such a scheme, but as it would include provisions for
  1926. legal intercept, it would hardly be attractive. One would expect that
  1927. such users would continue to find their own solutions as will the
  1928. classified domain.
  1929.  
  1930. An open and public service offering a credible level of confidentiality
  1931. would therefore provide for the honest user, while not worsening the
  1932. situation with respect to public order or national security.
  1933.  
  1934. The combination of international communication and national security
  1935. regulations require a common framework for confidentiality services,
  1936. which on the one hand interoperate within all Community Member States
  1937. as well as with countries outside the Community which themselves may
  1938. establish their confidentiality services. This requires either an
  1939. overlay approach or gateways which link the different national or
  1940. regional services. These gateways are only required where multinational
  1941. agreements for co-operation on national security concerns is not yet
  1942. established. In this case these gateways may provide at least an
  1943. interim solution.
  1944.  
  1945. In order to fulfil its function and eliminate the need for "home-made"
  1946. solutions, the public confidentiality service must be open to
  1947. world-wide use and provide its service in a non-discriminatory way.
  1948.  
  1949. Confidentiality services should ensure that
  1950.  
  1951.     Users are protected and obtain assurance against non authorised
  1952.     interception and disclosure.
  1953.  
  1954.     The confidentiality service is of high (technical, procedural)
  1955.     quality and evaluated as such by all Member States.
  1956.  
  1957.     Authorised disclosure of the protected user information (undo
  1958.     the confidentiality service) is under certain well-defined
  1959.     circumstances possible, eg by secret-sharing.
  1960.  
  1961. With this approach, confidentiality mechanisms details (description) do
  1962. not need to be published or disclosed to the public in general.
  1963.  
  1964. While the use must be largely unrestricted, the systems and sub-systems
  1965. or equipment for the independent implementation of aforementioned
  1966. confidentiality services can be made subject of export controls, eg
  1967. export is possible if:
  1968.  
  1969.     The users comply with the rules of the exporting nation
  1970.     (end-user declaration) with respect to the disclosure
  1971.     mechanism.
  1972.  
  1973.     Multinational business users form EC countries with "central"
  1974.     organisations.
  1975.  
  1976.     Other countries on a bilateral agreement liaise with EC if they
  1977.     comply with the rules.
  1978.  
  1979. Export restrictions are, inter alia, based on the concern that
  1980. cryptography may be used by hostile governments or other organisations
  1981. for the concealment of subversive information. The same concern does
  1982. not apply to the use of cryptography for integrity and authenticity
  1983. enhancing service.
  1984.  
  1985. There are technical solutions to provide only integrity, integrity plus
  1986. signature, and integrity, signature and confidentiality.
  1987. Confidentiality enhancement is de facto only meaningful in
  1988. communications with also the two other functions being provided.
  1989.  
  1990. The problem remains that organised crime and hostile governments are
  1991. not restrained from adopting public domain solutions or from developing
  1992. "home-made" mechanisms. Furthermore they are able to exploit legitimate
  1993. users of systems and solutions to their own ends by use of
  1994. "traditional" criminal mechanisms of bribery, blackmail or threats to
  1995. personal safety. Legislation could discourage non-authorised use, but
  1996. cannot be expected to prevent it, particularly in the case of organised
  1997. crime. Restrictive legislation impacts the "law-abiding user" much
  1998. stronger than others.
  1999.  
  2000. Choice versus interoperability
  2001.  
  2002. The users and service providers may feel the need to choose solutions
  2003. to achieve the assurance levels they require. But interoperability will
  2004. dictate a limited set of possible choices being available, and costs of
  2005. service provision will also focus debate onto efficient solutions.
  2006.  
  2007. Advice and instruction / prohibition
  2008.  
  2009. This may vary from country to country, however certain minimum-rules
  2010. will need to be adhered to between parties offering interworking public
  2011. schemes which includes beyond simply usage also systems and sub-systems
  2012. or equipment for the independent implementation of such confidentiality
  2013. services
  2014.  
  2015. Requirements
  2016.  
  2017.     Choice of architecture that minimises service vulnerability
  2018.     (The confidentiality that users enjoy will depend upon the
  2019.     robustness of the service that is offered. This in turn will
  2020.     depend upon the robustness of the architectures available to
  2021.     perceived threats: key theft, masquerade, deliberate denial of
  2022.     service, inadequate disaster recovery are examples of threats
  2023.     the vulnerability to which may be different for alternate
  2024.     architectures.)
  2025.  
  2026.     framework for the provision of trans-domain confidentiality
  2027.     services (Mechanisms are needed that provide for a defined way
  2028.     to pass from one domain to another. This will require
  2029.     collective or multilateral agreements for interoperation.)
  2030.  
  2031.     Guidelines for pan-European confidentiality service providers
  2032.  
  2033.     Model contract for relationship between service providers
  2034.     across national boundaries
  2035.  
  2036.     Assurance criteria for service providers and operators
  2037.  
  2038.     Accreditation process for mutual recognition.
  2039.  
  2040.  
  2041. 5.9.3.    Interworking of autonomous confidentially services 
  2042.  
  2043. Issue
  2044.  
  2045. Till such time that a universal service is being offered, interworking
  2046. between autonomous confidentiality services is likely to be the normal
  2047. situation because of the differentiated requirements. This implies the
  2048. need for generally accepted rules for the relationship between these
  2049. services.
  2050.  
  2051. Discussion
  2052.  
  2053. For quite a time the conflict between national security issues and the
  2054. business need for international communications has blocked significant
  2055. progress in the area of confidentiality services in telecommunications.
  2056. With the recent US initiatives, pressure from European companies will
  2057. grow to have access to equivalent services. But within Europe we have
  2058. the situation that neither the legal situation in the different EC
  2059. countries nor their national security policies are harmonised enough to
  2060. have a single confidentiality service scheme with a single algorithm
  2061. established within the foreseeable future. Therefore it is necessary to
  2062. have a framework, which enables user-transparent interoperability
  2063. between different national or regional schemes and which do not block
  2064. the way for a single scheme which may be established in the far future.
  2065. Interoperability is also required with non-European schemes like the
  2066. US. scheme. To provide this interoperability the way information is
  2067. passed from one national security domain to another has to be specified
  2068. and the national schemes have to be compatible with this specified way.
  2069. The establishment of such a framework for interoperability is therefore
  2070. a subject which needs international harmonisation. Aspects related to
  2071. this are requirements for the cryptographic algorithms and for key
  2072. management issues.
  2073.  
  2074. Requirements
  2075.  
  2076.     Definition of minimum requirements to ensure interoperability,
  2077.     including standards, specifications, rules of procedure and
  2078.     operating practices
  2079.  
  2080.     Demonstration of trans-European confidentiality services using
  2081.     a suitable application , eg the realisation of administrative
  2082.     telematics applications.
  2083.  
  2084. 5.10.    Motivation to acquire evaluated solutions
  2085.  
  2086. Issue
  2087.  
  2088. The advantage of the use of evaluated/certified solutions is not
  2089. generally accepted for commercial applications.
  2090.  
  2091. Discussion
  2092.  
  2093. Formal security evaluations have been carried out at a national level
  2094. by a comprehensive, costly and time consuming process. The investment
  2095. in the evaluation process by the vendor has resulted in higher prices
  2096. for the resulting secure IT product. The duration of the evaluation
  2097. process, has resulted in many secure products falling behind the
  2098. technical state of the art.
  2099.  
  2100. Up to now, this has detracted from their broader relevance in the
  2101. commercial market. Users have often preferred lower cost, more
  2102. functionality rich products unless forced to purchase evaluated and
  2103. certified products through some public procurement policy.
  2104.  
  2105. Vendors, historically, had products evaluated separately by each
  2106. national market and their supporting criteria. The resulting limited
  2107. revenue opportunity did not justify the high cost of getting products
  2108. evaluated.
  2109.  
  2110. It is necessary to change this view by convincing users of the
  2111. advantages of purchasing evaluated/certified solutions. Rapid adoption
  2112. of Common evaluation and certification criteria is essential to reduce
  2113. cost and speed-up mutual recognition of the resulting certificates.
  2114.  
  2115. Requirements
  2116.  
  2117.     Rapid adoption of common criteria
  2118.  
  2119.     Rapid agreement on common evaluation method
  2120.  
  2121.     Portability of test results and mutual recognition
  2122.  
  2123.     Work sharing between vendors, test centres and users to speed
  2124.     up the evaluation process
  2125.  
  2126.     Establishment of the "value-added" for the use by
  2127.     administrations and business, eg in terms of liability
  2128.     protection
  2129.  
  2130.     Consistent use in public procurement.
  2131.  
  2132. 5.11.    Consistency of procurement practices
  2133.  
  2134. Issue
  2135.  
  2136. National procurement guidelines for the purchase of
  2137. evaluated/non-evaluated products are not consistent throughout the EC,
  2138. nor is there a general agreement on when there is an obligation to use
  2139. evaluated products, and when it is recommended but discretional.
  2140.  
  2141. Discussion
  2142.  
  2143. Some security evaluated IT and communications products are purchased as
  2144. a result of a risk analysis where it is determined that the evaluated
  2145. communications product better suits the organisation's security needs
  2146. than a non-evaluated product.
  2147.  
  2148. However, a survey conducted of over 200 organisations indicated that,
  2149. to a large extent, evaluated products are purchased today by
  2150. organisations in the EC because of the expectation they will be
  2151. required by law to use certified products. This type of legislated
  2152. market is occurring especially in those Member States that were
  2153. involved in the development of ITSEC.
  2154.  
  2155. Unless common procurement policies are established in the EC, the IT
  2156. market will become a patchwork of evaluated and unevaluated products.
  2157. This may create new barriers to the efficient flow of information.
  2158.  
  2159. Requirements
  2160.  
  2161.     Identification of categories of application for evaluated
  2162.     solutions
  2163.  
  2164.     Alignment of national procurement policies concerning evaluated
  2165.     products
  2166.  
  2167.     Investigation of to assist those member states not involved in
  2168.     the early stages of ITSEC to develop and test procurement
  2169.     policies that are based on evaluated communications products.
  2170.  
  2171. 5.12.    Information Valuation
  2172.  
  2173. Issue:
  2174.  
  2175. For insurance purposes and for tort law cases a common means of
  2176. valuation of information and information processing resources is
  2177. needed.
  2178.  
  2179. Discussion:
  2180.  
  2181. In the case of information processing resources, the valuation may be
  2182. as straightforward as estimating the replacement value of computers or
  2183. the value of computer time in the case of denial of service (eg:
  2184. through virus attacks or other penetration). However, in the case of
  2185. destruction or theft of information, the problem is less
  2186. straightforward.
  2187.  
  2188. Obviously, it is not possible to set a standard for the value of
  2189. information, so what appears to be a potential solution is to establish
  2190. standards for valuation.
  2191.  
  2192. Requirements
  2193.  
  2194.     Definition of the classes of information used and the types of
  2195.     damage that could be caused to the information owners
  2196.  
  2197.     Definition of the rights and duties of information ownership
  2198.  
  2199.     Development of guidance for owners of information as to the
  2200.     actions that they would have been expected to take to protect
  2201.     their assets and avoid negligence charges
  2202.  
  2203.     Development of the methods and procedures that should be used
  2204.     to establish information value.
  2205.  
  2206. 6.    Supply related issues
  2207.  
  2208. 6.1.    Supply related Issues - Trusted Third Parties
  2209.  
  2210. 6.1.1.    Role of Trusted Third Parties
  2211.  
  2212. Issue
  2213.  
  2214. The public and generalised use of digital signature and of
  2215. confidentiality services and the conformance with the needs of law
  2216. enforcement implies the availability of Trusted Third Party (TTP)
  2217. services to provide essential functions.
  2218.  
  2219. Discussion
  2220.  
  2221. TTPs will have to inter-communicate internationally and thus form a
  2222. network of Trusted Third Parties , based on an international framework
  2223. for their operation.
  2224.  
  2225. Trusted Third Party services can be considered as value-added
  2226. communication services available to users wishing to enhance the trust
  2227. of the services he uses. Therefore TTPs have to be able to offer value
  2228. added with regard to availability, integrity, confidentiality and
  2229. assurance. Although TTPs may be set up on a national basis within
  2230. national law, they must be trusted internationally.
  2231.  
  2232. There are different types of functions which may all or in part be
  2233. fulfilled by TTPs. The exact nature and extend to which these functions
  2234. are provided by TTPs will be dictated by practical considerations and
  2235. may vary considerably.
  2236.  
  2237. In general the TTPs operate on the basis of information provided by the
  2238. user. Certification of information is carried out on the basis of
  2239. evidence of correctness provided by the user or generated by the TTP
  2240. itself, eg the keys.
  2241.  
  2242. The major services a TTP may offer include some or all of the following:
  2243.  
  2244.     Name assignment, ie the function of assigning individuals' and
  2245.     enterprises' unique names and addresses. Individuals may
  2246.     possess several different distinguished names, according to
  2247.     their role, eg as private citizen and as employee of a
  2248.     corporation.
  2249.  
  2250.     Certification, ie the function to validate that a name and
  2251.     address has certain credentials, eg a public key for
  2252.     signature.
  2253.  
  2254.     Key Management for signature, ie the generation, distribution,
  2255.     establishment, and administration of public and private keys.
  2256.  
  2257.     Key Management for confidentiality, ie the function to
  2258.     generate, distribute and administer keys used for confidential
  2259.     communications.
  2260.  
  2261.     Management Services for Names and Credentials, ie the function
  2262.     to establish, administer and make available registers with the
  2263.     names of individuals and their certified credentials.
  2264.  
  2265.     Legal services, ie functions usually performed by the legal
  2266.     profession, mostly concerned with non-repudiation.
  2267.  
  2268.     Guaranteed Date and Time Stamping, ie the function to provide
  2269.     exact date and time on request, to support non-repudiation.
  2270.  
  2271.     Management of Negotiable Document Transactions, ie unforgeable
  2272.     non-personalised tokens (eg electronic Bills of Lading,
  2273.     electronic shares).
  2274.  
  2275.     Storage of Electronic Information for clients with appropriate
  2276.     guarantees of confidentiality and integrity.
  2277.  
  2278. Common to Trusted Third Party service providers is that they have to be
  2279. accredited and audited, and that they have to operate under the law of
  2280. the country using common guidelines. The figure below provides an
  2281. analysis of the different functions involved in the establishment and
  2282. operation of TTPs.
  2283.  
  2284. The diagram identifies four functions in this process. The functions are:
  2285.  
  2286.     the provision of the required good practices, rules and
  2287.     regulations for the accreditation and operation of TTPs
  2288.  
  2289.     the accreditation, re-accreditation and audit of TTPs
  2290.  
  2291.     the TTP functions themselves
  2292.  
  2293.     the use of communications and of the TTP.
  2294.  
  2295. This diagram does not imply any particular allocation of responsibility
  2296. for the functions indicated.
  2297.  
  2298. The information flow contains the following major elements:
  2299.  
  2300.     National Laws. The operation of TTPs will take place within the
  2301.     laws of the country in which they are located. It is
  2302.     conceivable that some legislation has to be updated to allow
  2303.     TTPs to operate in an international environment.
  2304.  
  2305.     Good practices, rules and regulations for the accreditation,
  2306.     operation and audit of TTPs.
  2307.  
  2308.     Standards for communications.
  2309.  
  2310.     Good practices, regulations and laws for the use of
  2311.     communication services.
  2312.  
  2313. 6.1.2.    Operating principles of TTP
  2314.  
  2315. Issue
  2316.  
  2317. The need for common operating principles for TTPs.
  2318.  
  2319. Discussion
  2320.  
  2321. To be effective, TTPs must:
  2322.  
  2323.     operate securely
  2324.  
  2325.     operate within a consistent legal framework across the Community
  2326.  
  2327.     offer a range of services, with a defined minimum
  2328.  
  2329.     conform to European or international standards, where available
  2330.  
  2331.     follow accepted good practice
  2332.  
  2333.     allow for independent arbitration, without compromising security
  2334.  
  2335.     be monitored by a supervisory board
  2336.  
  2337.     be independent in its operation within accreditation rules
  2338.  
  2339.     have a public policy on service refusals, if applicable
  2340.  
  2341.     assume responsibility of liability within defined limits for
  2342.     availability and quality of service.
  2343.  
  2344. The key questions include:
  2345.  
  2346.     Has the TTP a contractual obligation of results in terms of
  2347.     availability, integrity and confidentiality?
  2348.  
  2349.     How and by whom are the loss and penalty determined in cases of
  2350.     fraud, negligence or failure of the TTP?
  2351.  
  2352.     What assurance to the final user is offered by the
  2353.     accreditation of the TTP?
  2354.  
  2355. Requirements
  2356.  
  2357.     Harmonised legislation to provide an appropriate framework for
  2358.     arbitration, supervision and litigation
  2359.  
  2360.     Model for TTPs meeting the requirements of users and
  2361.     authorities.
  2362.  
  2363.     Baseline for accepted good practice including a study of the
  2364.     level of availability, privacy and security required for the
  2365.     TTP by the final users and how much they are ready to pay for
  2366.     it
  2367.  
  2368.     Definition of quality of service, including availability,
  2369.     confidentiality, response-time, rules of disclosure to law
  2370.     enforcement agencies
  2371.  
  2372.     Operational guidelines, including descriptions of minimum set
  2373.     of services and standards to conform to
  2374.  
  2375.     Standard clauses for the contract between the TTP and the user,
  2376.     concerning the liability of the TTP.
  2377.  
  2378. 6.1.3.    Accreditation and audit of TTPs
  2379.  
  2380. Issue
  2381.  
  2382. The need for harmonised procedures for the accreditation and audit of
  2383. TTPs.
  2384.  
  2385. Discussion
  2386.  
  2387. Although the accreditation and audit of TTPs may be a local or national
  2388. responsibility, the procedures to be followed must be harmonised and
  2389. have a common basis in order to ensure mutual trust.
  2390.  
  2391. It is assumed that national governments will be responsible for
  2392. approving accrediting bodies. This may require to create new national
  2393. laws or to adapt existing laws.
  2394.  
  2395. From the TTP point of view, timely and fair responses to requests for
  2396. accreditation will be important.
  2397.  
  2398. From the user point of view, the agreed terms of the accreditation need
  2399. to be properly documented and inspectable.
  2400.  
  2401. To maintain public trust in TTPs, an audit process must be put in place.
  2402.  
  2403. Other issues are related to the
  2404.  
  2405.     requests for accreditation from service providers in other EC
  2406.     and non-EC countries
  2407.  
  2408.     certification of certificates
  2409.  
  2410.     authority and accreditor signatures.
  2411.  
  2412. Existing Community rules for accreditation (eg of test centers) should
  2413. be used as a basis for this work.
  2414.  
  2415. Requirements
  2416.  
  2417.     Development of international guidelines for the accreditation
  2418.     and audit of TTPs
  2419.  
  2420.     Adaptation of applicable legislation or regulations to provide
  2421.     an appropriate legal framework for use throughout the Community
  2422.     and in the relations with third countries.
  2423.  
  2424. 6.1.4.    Use of names and certification of credentials
  2425.  
  2426. Issue
  2427.  
  2428. Use of names and of credentials (eg the public key) in international
  2429. communications.
  2430.  
  2431. Discussion
  2432.  
  2433. Name Assignment and Certifications Authorities are Trusted Third
  2434. Parties. They have been defined and, to some degree, specified by CCITT
  2435. X.509 "Directory - Authentication Framework". Their purpose is to allow
  2436. for individual and authentic addressing of communication system users
  2437. by means of their authenticated Distinguished Names. A user may ask a
  2438. Naming Assignment Authority for a Distinguished Name. The Naming
  2439. Authority will give him a Relative Distinguished Name and supplement it
  2440. by its own Distinguished Name to the user's Distinguished Name. Thus,
  2441. although a person may ask several Naming Authorities for the same
  2442. Relative Distinguished Name, each of his Distinguished Names will be
  2443. unique, because the Distinguished Names of the Naming Authorities, by
  2444. definition, will be unique. The concept of an agent that handles the
  2445. interfaces between the end-user and the naming authorities is important
  2446. in providing a user friendly interface to this process.
  2447.  
  2448. The two functions of name assignment (or identification) and
  2449. certification are "binding" operations. Name assignment binds a
  2450. particular name to an entity (a person or device), and certification
  2451. binds certain credentials to a name. The diagram below shows the double
  2452. binding process.
  2453.  
  2454. A Distinguished Name and a unique cryptographic Public Key are made
  2455. part of the user's Credentials. The Public Key can be used to verify a
  2456. (ciphertext) signature which has been effected by the user's
  2457. complementary Secret Key (not contained in the Credentials).
  2458. Credentials are signed/certified by the Certification Authority. Thus
  2459. the user's Certificate consists of the Credentials, their signature by
  2460. the Certification Authority and, if necessary, the Certification
  2461. Authority's own Certificate. The user is given his certificate,
  2462. preferably in a tamper resistant chipcard.
  2463.  
  2464. After signing a message with his Secret Key the user concatenates his
  2465. Certificate to the message and its signature. The receiver of the
  2466. signed message can use the Certification Authority's widely available
  2467. Public Key to verify the signer's Certificate and Public Key. With the
  2468. latter the authenticity and integrity of the message can be verified.
  2469.  
  2470. The security services related to name assignment and certification need
  2471. further standardisation as well as legal recognition, both preferably
  2472. on an international level.
  2473.  
  2474. The United States have already begun to apply relevant US national
  2475. standards. Therefore, corresponding standardisation action should be
  2476. started on a European level. Its results should be made the basis for a
  2477. European contribution to international standardisation. At the same
  2478. time an interface toward a legal usage of naming and certification
  2479. services should be defined to ease the adaptation to and to provide for
  2480. the compatibility of the various EC legal systems.
  2481.  
  2482. Other related issues are pseudonyms and anonymity, for which a business
  2483. requirement has been identified. Different degrees of anonymity should
  2484. be provided for according to the specific needs in digital cash,
  2485. tele-shopping, registration in data bases for statistical purpose etc.
  2486.  
  2487. As described above, the ability to sign a piece of data is to be
  2488. distinguished from the authority an entity possesses.  This
  2489. relationship is depicted below:
  2490.  
  2491. Requirements
  2492.     Development of guidelines covering the use of names, by specifying:
  2493.  
  2494.     o naming principles (hierarchy of naming authorities)
  2495.     o format of Distinguished Name/Relative Distinguished Name
  2496.     o requirements to meet by naming authorities
  2497.     o requirements to meet by the user
  2498.     o requirements for the protection of the name against changes
  2499.     o handling protocol between naming authorities, user and
  2500.       certification authority
  2501.     o change of names
  2502.     o recording of information pertinent to de-referencing of names
  2503.       (by the Directory).
  2504.  
  2505.     Development of guidelines covering the  use of certificates, by
  2506.     specifying:
  2507.     o certificate semantics and format
  2508.     o certificate handling (production, issuance)
  2509.     o signature and its certification (method, process)
  2510.     o authentication of certificate owner (method, process)
  2511.     o expiry dates
  2512.     o renewal of certificates (periodical)
  2513.     o renewal of TTP public key (periodical)
  2514.     o handling compromises of secret information (secret keys, PIN etc.)
  2515.     o revocation of certificates and notification
  2516.     o black listing and execution of certificates
  2517.     o security requirements to meet by certification authorities.
  2518.  
  2519. 6.1.5.    Key management service
  2520.  
  2521. Issue
  2522.  
  2523. Key management services for signed and privacy enhanced communications
  2524. between organisations and individuals.
  2525.  
  2526. Discussion
  2527.  
  2528. General
  2529.  
  2530.     Definition of responsibilities and obligations for services
  2531.     that provide trust in the integrity of communications and those
  2532.     that provide confidentiality.
  2533.  
  2534.     Development of codes of practice for the generation,
  2535.     distribution and storage and destruction of keys for both
  2536.     purposes (integrity and confidentiality) in environments that
  2537.     have varying levels of assurance.
  2538.  
  2539.     Definition of escrow services. Some of the secrets may be of
  2540.     paramount importance and may have to be distributed among
  2541.     trusted parties (distributed-secret-escrow agents) so that none
  2542.     of the parties know the complete secret and not less than a
  2543.     defined minimum of those trusted parties must contribute their
  2544.     part of the secret in order to produce the complete secret.
  2545.  
  2546.     Mechanisms and criteria for assessing applicants suitability
  2547.     for the use of TTP services. Not all potential users of TTPs
  2548.     may have the necessary attributes (eglegal status, financial
  2549.     viability, etc.). This essentially applies to TTP services for
  2550.     closed user groups.
  2551.  
  2552. Integrity and digital signatures
  2553.  
  2554.     Relationship between the key management functions, directory
  2555.     management and certification needs to be clarified.
  2556.  
  2557.     Timeliness of issuing signatures when an application is made -
  2558.     verification of "signature worthiness" of applicant - periodic
  2559.     review of "worthiness" of existing constituency of signature
  2560.     holders.
  2561.  
  2562.     Removal of signatures from "active list" and initiation of
  2563.     "attempted illegal use" audit. This is a "certificate
  2564.     management" - "key management" interface management issue.
  2565.  
  2566. Privacy Enhancement
  2567.  
  2568.     Management of the domain within which the confidentiality keys
  2569.     are valid. The identity of authorised subjects within the
  2570.     domain: Key distribution to those authorised subjects (people
  2571.     and automated processes.).
  2572.  
  2573.     Should the TTP define the domain as well as manage it: if not
  2574.     should another TTP hold the definition (ietable of authorised
  2575.     subjects).
  2576.  
  2577.     Assessment of the assurance level of the domain within which
  2578.     the confidentiality keys are to be used, ranging from vetted,
  2579.     cleared people with physical and logical access controls to
  2580.     un-cleared people in open environments.
  2581.  
  2582. Domains are an important concept in confidentiality provision. The
  2583. following questions require an answer:
  2584.  
  2585. 1.      What is the scope of validity of a domain for certification and
  2586. the scope of validity for a confidentiality mechanism? Who manages the
  2587. domains? Who manages inter-domain issues? Does each domain need a
  2588. different TTP?
  2589.  
  2590. 2.      Who determines the scope of a domain? Who is authorised to
  2591. change it? (for both certification and confidentiality.) Is a domain a
  2592. "contract", and under which circumstances?
  2593.  
  2594. 3.      What are the assurance criteria for domain management? Who
  2595. audits a domain manager? Who maintains the principles of domain
  2596. management as technology changes?
  2597.  
  2598. 4.      Should domains for certification and confidentiality be
  2599. different in view of the fact that a confidentiality domain will be
  2600. transitory and that therefore key management principles are different?
  2601.  
  2602. 5. When should the use of escrow services be mandated to ensure domain
  2603. integrity.
  2604.  
  2605. Requirements
  2606.  
  2607.     Single digital signature mechanism and specifications
  2608.     preferably consistent with other leading countries
  2609.  
  2610.     Adoption of a confidentiality algorithm standard and
  2611.     specification, and a key distribution mechanism based on an
  2612.     asymmetric public key algorithm
  2613.  
  2614.     Establishment of "domain assurance" levels and criteria for
  2615.     TTPs to use for confidentiality key management purposes
  2616.  
  2617.     Codes of practice for TTPs engaged in key management
  2618.     activities, and the provision of escrow services and the
  2619.     methods by which those codes of practice would be audited
  2620.  
  2621.     Set of criteria for mutual recognition between TTPs acting on
  2622.     behalf of organisations who wish to communicate securely.
  2623.     Merging of signature directories and secure inter-domain
  2624.     communications are fundamental issues.
  2625.  
  2626. 6.1.6.    Management Services for Names and Credentials
  2627.  
  2628. Issues
  2629.  
  2630. Whenever parties engage in bi- or multi-lateral electronic
  2631. transactions, they need beforehand some non-transient information on
  2632. their partners (such as identity, legal representatives or any other
  2633. kind of credentials eg public keys). This does not imply permanent
  2634. recording of such information.
  2635.  
  2636. Discussion
  2637.  
  2638. Management Services for Names and Credentials are established to
  2639. facilitate access to this type of information, whereby service
  2640. subscribers are provided with up-to-date data pertaining to the parties
  2641. listed in there. Because partners may conclude the transactions on the
  2642. basis of the information (at the minimum, the authenticated identity of
  2643. their partners) they are provided with, and because some of the
  2644. information stored by such a service may be protected by privacy
  2645. legislation, the service itself must be trustworthy and the data it
  2646. provides correct.
  2647.  
  2648. Management Services for Names and Credentials keep objects which are
  2649. referred to by "Distinguished Names". A Distinguished Name is unique to
  2650. a communication subject. A subject may have a number of (unique in the
  2651. above sense) "Alias Names". It is required that the service can
  2652. reference Alias Names to their subject's natural names. An Alias Name
  2653. may be a pseudonym. Whether or not the service is allowed to reference
  2654. a pseudonym and let inquirer know the result will depend on the
  2655. subject's data privacy rights.
  2656.  
  2657. If, as is likely going to be the case, there is more than one provider
  2658. and certifier of information, the Management Services for Names and
  2659. Credentials must be part of a network of information suppliers. Network
  2660. can be organised according to either geographical distribution or
  2661. business sector or information taxonomy or all three of them. Users may
  2662. have to subscribe to more than one such service or service type (eg
  2663. "Public Key directory for the banking sector"). Users may have a number
  2664. of different roles in an enterprise, each of which needs access to a
  2665. set of different services. In the case of a multiple service and
  2666. network of providers, one can speak of a system of Management Services
  2667. for Names and Credentials.
  2668.  
  2669. Because of the damages that could be caused by the distribution of
  2670. false information, the Management Services for Names and Credentials
  2671. must apply due care in its operations. In the case of proven negligence
  2672. the service could be held liable if inaccurate information were
  2673. provided. The creation, update and destruction (eg in the case of
  2674. certificate revocation) of information is either mandatory or
  2675. forbidden. In critical cases (eg; certificate revocation), the update
  2676. may have to be notified to subscribers without request.
  2677.  
  2678. The management of the Management Services for Names and Credentials
  2679. must thus be accountable. There must be legislation, rules and
  2680. regulations governing it.
  2681.  
  2682. Obviously, the service must cover and be available on an international
  2683. level.
  2684.  
  2685. Obviously there is the issue of standardisation of the service at the
  2686. user end (external interface) and between service providers (internal
  2687. interface).
  2688.  
  2689. Since international Management Services for Names and Credentials are
  2690. akin to internationally distributed data bases, they face the same
  2691. legal questions: who is legally responsible for the information
  2692. (between the creator, the storer, the distributor)?
  2693.  
  2694. Market pressures are bound to promote the advent of sectorial
  2695. Management Services for Names and Credentials, and possibly their
  2696. subsequent interconnection or integration into larger network. In order
  2697. to avoid fragmentation among proprietary services, there may be a need
  2698. to lay down base rules for naming, binding, certificates and the
  2699. associated IPR rules.
  2700.  
  2701. Requirements
  2702.  
  2703. The basic issue is the provision of efficient Management Services for
  2704. Names and Credentials, supplying various types of information is a
  2705. requirement that needs rapid and efficient satisfaction.
  2706.  
  2707.     Provision of Management Services for Names and Credentials, to
  2708.     include:
  2709.  
  2710.     o Identity (cf. issues on name authentication and referencing
  2711.       of Alias Names)
  2712.     o Name information (to enable the correct forwarding of
  2713.       messages (eg static digital network or GSM communications)
  2714.     o Credentials such as public keys or any signature-verification
  2715.       data.
  2716.  
  2717.     Interoperability specifications and standards.
  2718.  
  2719.     Harmonisation of legislation , rules and regulations concerning
  2720.     Management Services for Names and Credentials, intra-Community
  2721.     and extra-Community.
  2722.  
  2723. 6.1.7.    Legal services
  2724.  
  2725. Issues
  2726.  
  2727. Legal TTP services are offered essentially to prevent disputes, or
  2728. resolve them in a structured, efficient, accepted by all parties
  2729. involved and non-controversial way.
  2730.  
  2731. Discussion
  2732.  
  2733. Prevention of disputes arises essentially from the very ability of
  2734. legal services to assign responsibility and fault, should one occur.
  2735.  
  2736.     Thus, legal services must essentially be able to verify the
  2737.     application or non-application of rules and the evidence
  2738.     pertaining to them.
  2739.  
  2740.     Legal services may or may not generate the evidence itself. In
  2741.     other words the question is whether a third party offering a
  2742.     trusted service also arbitrates litigations pertaining to its
  2743.     principal service. For example, does a signature generation
  2744.     service also provides signature-verification services?
  2745.  
  2746. Two issues arise in this topic:
  2747.  
  2748.     What is the legal status of evidence generated by TTPs ? Does
  2749.     it imply liability? What is the legal status of decisions made
  2750.     par legal services when they are not judicial but private(and
  2751.     corollary, what are the rules of appeal)?
  2752.  
  2753.     If evidence is not generated by the arbiter, how is the
  2754.     evidence acquired and authenticated and how is responsibility
  2755.     assigned? One is faced with the general problems of TTPs :
  2756.     operating rules and legislation, standardisation,
  2757.     inter-operability and accreditation.
  2758.  
  2759. Requirements
  2760.  
  2761. In addition to the ones concerning operation legislation,
  2762. standardisation, inter-operability and accreditation, Community actions
  2763. specifically aimed at legal TTP services could focus on
  2764.  
  2765.     the harmonisation of legislation on the legal status of
  2766.     evidence generated by any TTPs and especially on the intra- and
  2767.     extra- community recognition thereof. This probably implies the
  2768.     settlement of the accreditation question
  2769.  
  2770.     the promotion of community-level information technology
  2771.     litigation services modelled after existing international
  2772.     bodies such as the International Chamber of Commerce
  2773.  
  2774.     Essentially focus on - and restrict actions to the problems
  2775.     created by the fastest-growing services based on Public Key
  2776.     cryptography, eg verification of signatures, certificates,
  2777.     etc.
  2778.  
  2779. 6.1.8.    Guaranteed date and time stamping
  2780.  
  2781. Issue
  2782.  
  2783. Guarantee of unambiguous date and time of submission and receipt.
  2784.  
  2785. Discussion
  2786.  
  2787. In electronic communications, a digital equivalent is required for the
  2788. date and time stamp in the paper world. Such a time stamp must be
  2789. issued by an organisation that is trusted. If time stamps are simply
  2790. attached internally by the sender or receiver of a message, then, in
  2791. case of litigation, it will be difficult to establish if these were
  2792. erroneous or have been forged.
  2793.  
  2794. In direct communications, both parties may agree on a mutual time
  2795. reference, but in store-and-forward type communications time stamping
  2796. by a third party is particularly important.
  2797.  
  2798. Depending on sectoral differences, different granularities of time
  2799. stamps may be needed. Some sectors may be content with the date, some
  2800. with the nearest second.
  2801.  
  2802. The third party must be trusted by both parties, or at least the
  2803. dispute resolution mechanism, for the correctness of the date and time
  2804. supplied, but also for the confidentiality with which they handle the
  2805. contents of the correspondence.
  2806.  
  2807. The time stamping schemes proposed so far are impractical, because they
  2808. require the recording of the time stamp and the document (or at least
  2809. its digest).
  2810.  
  2811. Requirements
  2812.  
  2813.     Development of an approach to date and time stamping for
  2814.     time-critical transactions and applications, including a range
  2815.     of granularities of timing.
  2816.  
  2817.     International harmonisation of rules and services for time
  2818.     stamping, with the objective of achieving general recognition
  2819.     and acceptance of time stamps and their provision by suitably
  2820.     accredited service providers.
  2821.  
  2822.     International harmonisation of rules and services for time
  2823.     stamping, with the objective to achieve general recognition and
  2824.     acceptance of time stamps issued from different service
  2825.     providers.
  2826.  
  2827. 6.1.9.    Negotiable document transaction
  2828.  
  2829. Issue
  2830.  
  2831. Some conventional physical documents, such as eg the bill of lading and
  2832. the bill of exchange, must be negotiable. The possession of the
  2833. document must allow to give title to anybody who can present it. The
  2834. electronic equivalent is also needed.
  2835.  
  2836. Discussion
  2837.  
  2838. Negotiable documents entail that their physical uniqueness must be
  2839. protected against duplication; it must be easy to distinguish a copy
  2840. from its original. This is the case with hand signed paper documents;
  2841. the hand-written signature cannot be copied such that the copy could
  2842. not be distinguished from the original. True, a digital signature does
  2843. protect the integrity of the signed electronic document; however, it
  2844. can be easily copied so that the physical original cannot be discerned
  2845. from its copies.
  2846.  
  2847. This impedes the usage of electronic communication eg in maritime
  2848. trade. The sender of a cargo produces a unique document, the bill of
  2849. lading, hands a copy to the shipper and sends the protected original to
  2850. the receiver. The receiver may trade the original and its title or keep
  2851. it. Whoever presents the original to the shipper will be handed over
  2852. the cargo.
  2853.  
  2854. The shortcoming of the paper bill of lading is the fact that it takes
  2855. time to transport it, particularly as it is a piece of value and must
  2856. be well protected. Therefore, an electronic substitute should be found
  2857. that protects its originality and can be transacted in
  2858. telecommunication systems.
  2859.  
  2860. The Document originality can be provided by the use of chipcards. A
  2861. chipcard can store a secret and protect it. The secret is essential to
  2862. authenticate the signature of the document. As the chipcard cannot be
  2863. explored, the secret cannot be transacted into another chipcard. Thus
  2864. it is practically impossible to duplicate the original chipcard. Such a
  2865. chipcard can be made a substitute of the negotiable paper document.
  2866.  
  2867. In order to produce and to transact chipcard documents via
  2868. telecommunication trusted equipment is needed. It Should be operated by
  2869. trusted third parties, eg by public notaries. They may be bestowed with
  2870. the responsibility to produce chipcard documents and to transact and
  2871. receive them by means of their trusted equipment. Transaction may be
  2872. performed by depleting the original chipcard at the sending end,
  2873. securely transmitting its information and feeding it into another
  2874. chipcard at the receiving end. This process must be protected for its
  2875. integrity and confidentiality. Not even the "public notary" must be in
  2876. a position to alter the information.
  2877.  
  2878. Beside issuing negotiable documents there are other ways of securing
  2879. correct title to property. Instead of a person proving his claim by the
  2880. presence of a token, the claim may be addressed to a distinct person
  2881. who then is expected to prove his identity.
  2882.  
  2883. This - continuing with the above example - is the case with the freight
  2884. bill, which is another way to deliver a cargo to the authentic
  2885. receiver. However, the freight bill cannot be traded as effectively as
  2886. the bill of lading, although, by omission of additional chipcards and
  2887. other trusted equipment, it makes it easier to design the electronic
  2888. substitute process.
  2889.  
  2890. One should expect that, unless proper electronic documents will be
  2891. available, the use of paper for negotiable documents will be continued
  2892. at the expense of effectivity and more paper.
  2893.  
  2894. Requirements
  2895.  
  2896.     Development of techniques for the establishment, handling and
  2897.     recording of Electronic Negotiable Documents.
  2898.  
  2899. 6.2.    Supply related issues - Evaluation of trusted solutions
  2900.  
  2901. 6.2.1.    Perceived Requirements for trusted solutions
  2902.  
  2903. Issue
  2904.  
  2905. Need of users for trusted components, products, systems, services and
  2906. applications
  2907.  
  2908. Discussion
  2909.  
  2910. The trustworthiness of a given information system and its use imply an
  2911. evaluation process. Depending on the needs of the customer, either
  2912. vendor declarations or formal certification procedures may be needed.
  2913. The choice of either of these mechanisms will depend, inter alia, on
  2914. costs and delays involved in formal certification processes. A major
  2915. factor is also the recognition of certificates in other markets and
  2916. their utility, eg in protecting the user or vendor against liability
  2917. claims, where it is possible to do so. In the safety related area, the
  2918. trustworthiness of the development process and its execution are also
  2919. critical factors and need not only evaluation but also auditing. The
  2920. qualifications and experience of project managers and safety auditors
  2921. are also factors which affect the resultant level of trust in the
  2922. system.
  2923.  
  2924. Requirements
  2925.  
  2926.     International agreement on criteria and evaluation methods, and
  2927.     mutual recognition of test results
  2928.  
  2929.     Clarification of the commercial value of "certified products",
  2930.     eg in terms of liability limitation
  2931.  
  2932.     Clarification of the status and implied liability of vendor
  2933.     declarations
  2934.  
  2935.     Development of principles for liability definitions for
  2936.     multi-level, distributed services
  2937.  
  2938.     International agreement on the methods for evaluating safety
  2939.     critical system development processes, and the qualifications
  2940.     and experience needed for individuals to become managers and
  2941.     auditors of such activities.
  2942.  
  2943. 6.2.2.    International harmonisation and mutual recognition
  2944.  
  2945. Issue
  2946.  
  2947. At the moment different evaluation criteria and evaluation schemes are
  2948. in use. These are especially the US, TCSEC, the European ITSEC and the
  2949. Canadian CTCPEC. Other countries like Japan have first drafts of
  2950. criteria. This situation is not acceptable to international
  2951. manufacturers who would have to perform different evaluations against
  2952. different criteria and schemes for a single product. This will
  2953. unnecessarily increase the cost of the product without enhancing the
  2954. security features.
  2955.  
  2956. Discussion
  2957.  
  2958. Different activities have already been taken or are currently on the
  2959. way to harmonise evaluation criteria and evaluation schemes. The ITSEC
  2960. and ITSEM are a result of such a harmonisation process within Europe,
  2961. and the United Kingdom, France, Germany and the Netherlands are
  2962. discussing the mutual recognition of each other's certificates based on
  2963. ITSEC and ITSEM, with the intention of achieving agreement in 1994.
  2964.  
  2965. In North America, the US and Canada co-operated in the production of
  2966. the first draft of the Federal Criteria. Following publication of the
  2967. Federal Criteria in early 1993, it has been decided to make all effort
  2968. to align the ITSEC and the Federal Criteria to produce a joint
  2969. European/North American set of Criteria compatible with existing
  2970. practices in both North America and Europe in 1994. This is the first
  2971. step towards international harmonisation between the two groups.
  2972.  
  2973. Based on these activities, ISO/IEC JTC1/SC27, Working Group 3 is
  2974. working on an ISO standard for evaluation criteria.
  2975.  
  2976. But harmonisation of the criteria is only the first step to reach
  2977. mutual recognition of evaluation results. It will need to be
  2978. accompanied by agreement on methodology, schemes and certification
  2979. bodies. Only then will mutual recognition between North America and
  2980. Europe be possible.
  2981.  
  2982. Even within the European Community mutual recognition has turned out to
  2983. be an arduous task and mutual recognition of certificates is not yet
  2984. achieved, mainly for legal reasons. This indicates that world-wide
  2985. mutual recognition of certificates requires many, yet unknown, problems
  2986. to be solved.
  2987.  
  2988. Some activities for international harmonisation of evaluation criteria
  2989. and evaluation processes are currently in progress but only one result
  2990. of such a process which seems to be stable and widely accepted has
  2991. until now been achieved. This is the ITSEC. But even in Europe the
  2992. subject of harmonising the evaluation process turns out to take much
  2993. more time than the harmonisation of the criteria. The reason for this
  2994. is that the ITSEC could be adopted by different countries quite easily
  2995. without significant changes to their existing evaluation processes (and
  2996. almost no changes to the certification schemes). The real changes to
  2997. the established practices come up when you try to harmonise these two
  2998. topics, since this results in significant changes to evaluation and
  2999. certification practices and may even have legal consequences.
  3000.  
  3001. Looking into the international arena, the only evaluation process and
  3002. certification scheme in the area of communications-security which is in
  3003. place for a significant time is (beside the European one) the US TCSEC
  3004. evaluation scheme. But the focus of this scheme is mainly to evaluate
  3005. and certify commercial operating system products suitable for
  3006. government applications. Currently the US are trying to widen this
  3007. scope with the Federal Criteria and the accompanying trust technology
  3008. programme of NIST whose main goal is to establish a more commercially
  3009. oriented evaluation and certification scheme with industrial evaluation
  3010. facilities like the ITSEF's in Europe. Both the Federal Criteria as
  3011. well as the trust technology program look like a much better basis for
  3012. international harmonisation but nevertheless a considerable amount of
  3013. work is necessary to achieve this goal. But since both the new criteria
  3014. as well as the commercial evaluation process are not yet established in
  3015. the US there is an opportunity to influence this process. The fact that
  3016. the US sponsors two parallel ITSEC evaluation of their TMach operating
  3017. system show clearly that the US side watches the European activities in
  3018. this area very carefully and tries to get as much information as
  3019. possible (both positive and negative!) about the European evaluation
  3020. process.
  3021.  
  3022. Even for the old TCSEC evaluation scheme the US showed great interest
  3023. in comparing this scheme with the European ones. Joint tasks between
  3024. the CEC and the US side represented by NIST and NSA material about the
  3025. various evaluation processes was presented. This shows a will for
  3026. co-operation which is clearly based on the fact that US manufacturers
  3027. sell more communications-products in Europe than vice versa. Other
  3028. countries like Sweden, Australia and Japan watch this process very
  3029. carefully.
  3030.  
  3031. Requirements
  3032.  
  3033.     Establishment of conditions and procedures for mutual
  3034.     recognition of evaluations
  3035.  
  3036.     Establishment of conditions and procedures for
  3037.     EC-wide/international evaluations
  3038.  
  3039.     International and EC standardisation of evaluation criteria and
  3040.     methods.
  3041.  
  3042. 6.2.3.    Vendor declarations
  3043.  
  3044. Issue
  3045.  
  3046. For applications that need security, but not the kind requiring formal
  3047. evaluations, vendor declarations are used. These are, however, at
  3048. present not defined in terms of what they cover and what assurance they
  3049. offer compared to formal evaluation.
  3050.  
  3051. Discussion
  3052.  
  3053. Between the requirements of governments for formally evaluated
  3054. solutions and no evaluation at all, there is a large part of
  3055. applications used by business and the general public. Vendors do
  3056. address security and provide some level of assurance, but its
  3057. significance, particularly in an open environment is not obvious.
  3058.  
  3059. Requirements
  3060.  
  3061.     Development of an agreed definition of scope and liabilities of
  3062.     vendor declarations for secure solutions.
  3063.  
  3064. 6.2.4.    Evaluation of applications
  3065.  
  3066. Issue
  3067.  
  3068. The user interest is finally with the security of his application. The
  3069. use of secure products and services is a necessary but not a sufficient
  3070. condition to meet the user requirements for the protection of the
  3071. application.
  3072.  
  3073. Discussion
  3074.  
  3075. At present, evaluations and certification schemes address primarily
  3076. products and systems. Communication services are only partially
  3077. addressed and applications running on the products and via networks (in
  3078. particular public networks) are left to the user to address. However
  3079. with the restrictive handling of confidentiality mechanisms and
  3080. opposition against end-to-end encryption, the user is left exposed.
  3081.  
  3082. Requirements
  3083.  
  3084.     Extension of ITSEC criteria and methods to cover services and
  3085.     applications.
  3086.  
  3087. 6.2.5.    Evaluation of communication services 
  3088.  
  3089. Issue
  3090.  
  3091. With the ITSEC and ITSEM Europe has already a scheme for the
  3092. independent security evaluation of IT-products and (to some extent)
  3093. IT-systems. At the moment this scheme does not fully cover the aspect
  3094. of the evaluation of telecommunication services, but extensions to this
  3095. scheme seem possible which are able to address the items not yet
  3096. covered by the current ITSEC/ITSEM scheme.
  3097.  
  3098. Discussion
  3099.  
  3100. The main item where communications security is considered in the public
  3101. is in the area of telecommunication services. Especially when people
  3102. send sensitive information to others using telecommunication services
  3103. they are interested that this information
  3104.  
  3105.     gets to the intended recipient(s) in time
  3106.  
  3107.     is not altered by the service
  3108.  
  3109.     it not received by anyone else than to the intended recipient(s).
  3110.  
  3111. Not all these aspects are of the same importance for each kind of
  3112. communication. The level of importance is highly dependent on the kind
  3113. of information one wants to transfer.
  3114.  
  3115. The use of telecommunication services grows rapidly as more powerful
  3116. equipment and services become available. A lot of companies and
  3117. especially administrations have policies which forbid the use of
  3118. specific telecommunication services for highly sensitive information
  3119. since they do not trust the communication services providers that some
  3120. of the above mentioned security issues are enforced adequately. They
  3121. use conventional techniques for the exchange of sensitive information
  3122. with conventional security measures (eg sending sealed letters by
  3123. registered mail or by courier).
  3124.  
  3125. In a time where industrial success depends on the fast exchange of all
  3126. types of information these conventional techniques become more and more
  3127. unacceptable. So the service providers will incorporate security
  3128. provisions within their services. But nevertheless a lot of companies
  3129. (and the national governments) will continue to use the conventional
  3130. techniques since they do not trust those security services unless they
  3131. are under their own control or being verified by independent experts.
  3132.  
  3133. Providing a security service as part of a telecommunication service
  3134. will normally result in all entities involved in the provision of the
  3135. telecommunication service being involved in providing the security
  3136. service. Additional entities may even be necessary (like eg a trusted
  3137. third party for key management issues or authentication services).
  3138. These entities use systems and products to provide their part of
  3139. telecommunication (and security) service. The total service is
  3140. therefore provided by an interaction of all the entities.
  3141.  
  3142. The current ITSEC/ITSEM scheme is aimed at the technical evaluation of
  3143. security measures within products and systems. It does not cover
  3144. organisational, personnel, administrative or non-IT related physical
  3145. security measures. Still many security services for telecommunication
  3146. will heavily rely not only on IT-security measures but also on the
  3147. above mentioned other security controls. For example a trusted third
  3148. party will surely need extensive organisational, personnel and non-IT
  3149. physical control. So it is clear that an extension to the ITSEC/ITSEM
  3150. evaluation scheme is necessary to cover these aspects. The following
  3151. section tries to identify how this can be done and which areas are not
  3152. yet covered.
  3153.  
  3154. Looking at communication services one can easily identify several
  3155. different types of communications-products and systems which have to
  3156. co-operate to provide the service. This includes for example
  3157.  
  3158.     the end user equipment (telephone, modem or even his computer)
  3159.  
  3160.     digital dialling switches
  3161.  
  3162.     data concentrators
  3163.  
  3164.     conventional computer systems with databases for eg user
  3165.     profiles, directory information
  3166.  
  3167.     conventional computer systems providing mailbox services
  3168.  
  3169.     the communication media
  3170.  
  3171.     gateways etc.
  3172.  
  3173. For a specific telecommunication service one can identify the task each
  3174. of these products or systems has to fulfil to provide this service. The
  3175. same is true for security services. Each component involved contributes
  3176. for one aspect of the security objectives or functions. These will then
  3177. differ significantly in the functionality as well as in the assurance
  3178. level required. Various topics regarding this may lead to problems, for
  3179. instance:. assumptions on the security provisions to be taken in the
  3180. environment of the product or system. Some of the security measures
  3181. will heavily depend on hardware features. Evaluation of non-IT security
  3182. features, like effectiveness of personnel and administrative security
  3183. measures has to be established. The integration of all security
  3184. measures has to be checked for consistency, completeness and
  3185. effectiveness. For the evaluation of a communication service,
  3186. therefore, different evaluations of systems involved in providing the
  3187. service are necessary before the whole service can be evaluated.
  3188.  
  3189. Requirements
  3190.  
  3191.     Extension of ITSEC to cover more explicitly evaluation of
  3192.     hardware security features
  3193.  
  3194.     Establishment of a formal accreditation scheme for secure
  3195.     communication services
  3196.  
  3197.     Development of accreditation guidelines for the
  3198.     telecommunication sector
  3199.  
  3200.     Trial service evaluations for existing telecommunication
  3201.     services
  3202.  
  3203.     Articulation of the requirements of service evaluation.
  3204.  
  3205. 6.2.6.    Trusted network management
  3206.  
  3207. Issue
  3208.  
  3209. Trusted Network Management systems need to maintain a given assurance
  3210. level while optimising the use of communication assets to achieve good
  3211. economics and quality of service.
  3212.  
  3213. Discussion
  3214.  
  3215. There is a growing dependence in the security of network management
  3216. systems for managing and controlling the provision of
  3217. telecommunications. This is due to an increased reliance on distributed
  3218. systems, the provision of new value added services and operations, and
  3219. on the increased sophistication and richness of network and service
  3220. functionality. Such dependency is placing greater demands on
  3221. performance and quality of service. Tomorrow's electronic highways
  3222. should be managed networks that should ideally interoperate in a
  3223. seamless way to ensure efficient "self-healing" network operations and
  3224. flexible creation and provision of a broad range of services, including
  3225. those supplied by third party suppliers. The management of
  3226. telecommunications systems security is thus growing in complexity
  3227. commensurate with the growth in communications systems and the
  3228. associated services and business use.
  3229.  
  3230. The major network management issues involve the protection of
  3231. electronic information in storage, in transmission and being processed.
  3232. Information used and applied to the controlling and maintenance of
  3233. networks and services. Information that is used as input to the process
  3234. of decision making and operational support, and which is also used as
  3235. input to the emerging new wave of intelligent systems and
  3236. communications. The provision of appropriate and effective network
  3237. management solutions is fundamental to the success of the future
  3238. telecommunications infrastructure for Europe.
  3239.  
  3240. Given the complex telecommunication systems that are evolving, the
  3241. interrelationships that are needed for multi-domain working, grade of
  3242. service requirements against a future European framework for
  3243. legislation and regulation needed to maintain multi-domain working, the
  3244. provision and maintenance of network management security the question
  3245. of security evaluation is a key issue. What is the alternative if
  3246. evaluation of network management security is not carried out ?
  3247.  
  3248. There are a number of constraints imposed by end users, service
  3249. providers and network operators on the provision of security for
  3250. network management eg concerning the employment of intelligence in
  3251. networks and the idea of securing shared resources, dealing with
  3252. different threat analysis and the responsibility for service
  3253. liability.
  3254.  
  3255. Requirements
  3256.  
  3257.     Methods for network management evaluation
  3258.  
  3259.     Extension of ITSEC to cover the evaluation of network
  3260.     management systems
  3261.  
  3262.     Definition of Functionality Classes (or Protection Profiles)
  3263.     suitable for systems, products and services used in network
  3264.     management systems
  3265.  
  3266.     Accreditation guidelines for the trusted network management
  3267.  
  3268.     Trial evaluations for existing network management systems.
  3269.  
  3270. 6.2.7.    Modifications to evaluated products and re-evaluation
  3271.  
  3272. Issue
  3273.  
  3274. The shortening life cycle of products and the rapid evolution of
  3275. services and applications due to competitive pressures implies the need
  3276. for frequent adaptations and therefore re-evaluation.
  3277.  
  3278. Discussion
  3279.  
  3280. The impact of Open System, with its emphasis on portability and
  3281. interoperablity, has resulted in many new products being incremental
  3282. releases of existing products, for new operational platforms,
  3283. applications, etc.  There may be multiple releases or versions of a
  3284. hardware or software solution in a short period of time. The
  3285. maintenance issues of many similar and homogeneous configurations
  3286. making up a product line is being understood.
  3287.  
  3288. The evaluation and certification of the product may take longer than
  3289. the period between releases or updates to the solution. A certificate
  3290. currently applies to a specific release or version. Changes may
  3291. invalidate the certificate.
  3292.  
  3293. There is a need to devise a method to cope with these product or system
  3294. changes so that the certified status of a product may be maintained.
  3295.  
  3296. Particular concerns include:
  3297.  
  3298.     Scope of the evaluation - Is an evaluation necessary for every
  3299.     single platform-dependent configuration of a product already
  3300.     certified?
  3301.  
  3302.     Assurance - Is it necessary to have an entire new release
  3303.     evaluated again in which only a small modification occurred (eg
  3304.     a spelling mistake in the user interface)?
  3305.  
  3306.     Re-use of previous evaluation work and results - Must the
  3307.     evaluation of sensitive and relevant but unmodified components
  3308.     of a product be repeated?
  3309.  
  3310. ITSEC and ITSEM have created a good basis on which to identify the key
  3311. issues of re-evaluation and subsequent re-certification.
  3312.  
  3313. Practical experience of re-evaluation is limited but the problem may be
  3314. mitigated by identifying key requirements. One approach is to
  3315. categorise code in the security Target of Evaluation (ITSEC-TOE). This
  3316. "Traffic Light" approach includes:
  3317.  
  3318. a)      GREEN code that has no bearing on the security functionality of
  3319. the product or system and that may be modified in future releases
  3320. without impact on the security of the product or system.
  3321.  
  3322. b)      YELLOW code that might impact the security of the product or
  3323. system and that must be inspected by an independent party (such as an
  3324. INSEF) before re-certification can be considered.
  3325.  
  3326. c)      RED code that is critical to the security functionality of the
  3327. product or system for which may modifications may require re-evaluation
  3328. of the whole product or system.
  3329.  
  3330. This structure will assist developers, evaluators and certifiers in
  3331. containing the level of necessary re-evaluation commitment following
  3332. any modifications.
  3333.  
  3334. Experience is available on the parallel field of quality evaluation of
  3335. software products. A framework for re-evaluation is outlined in ISO9126
  3336. and associated processes. It is likely that the impact of software
  3337. quality on "operational" correctness of security products will force
  3338. alignment of the various processes.
  3339.  
  3340. Requirements
  3341.  
  3342.     Effective feedback from existing Community schemes, both
  3343.     national and ITSEC related, on the problem of re-evaluation
  3344.  
  3345.     Product-line structuring, understanding the current strategic
  3346.     development of IT products and how this is likely to change
  3347.     product cycles
  3348.  
  3349.     Closer harmonisation of the evaluation process of all system
  3350.     and product "qualities" (performance, reliability, security)
  3351.     and how these may re-enforce each other in any re-evaluation
  3352.     actions
  3353.  
  3354.     Development of criteria for re-evaluation decisions
  3355.  
  3356.     Development of "critical event" approach to re-evaluation
  3357.  
  3358.     development of self-diagnostic techniques and procedures for IS
  3359.     maintenance.
  3360.  
  3361. 6.2.8.    Performance reporting for trusted products
  3362.  
  3363. Issue
  3364.  
  3365. Obligation to take corrective action in the case of faults found in
  3366. evaluated products.
  3367.  
  3368. Discussion
  3369.  
  3370. Despite the successful evaluation and certification of a product or
  3371. system, there is a small chance, smaller with the higher assurance
  3372. levels, that a security related fault will be detected. The Developer
  3373. is likely to have this fault reported to him and ought to take steps to
  3374. correct this fault as quickly as possible and issue a new release of
  3375. the software or hardware. The Certification Body needs to be informed
  3376. of the fault and the steps the Developer intends to take to correct the
  3377. fault. The Certification Body and the Developer need to discuss the
  3378. need for any re-evaluation work and agree a timescale for this. Where a
  3379. Developer is unwilling to correct the fault, the Certification Body
  3380. needs to decide whether to withdraw the certified status and publish
  3381. the fact that a fault exists, although not necessarily the details of
  3382. the fault.
  3383.  
  3384. Requirements
  3385.  
  3386.     Incident reporting system for Certification Bodies
  3387.  
  3388.     Definition of user and supplier obligations to report incidents.
  3389.  
  3390. 6.2.9.    Rationalisation of evaluations 
  3391.  
  3392. Issue
  3393.  
  3394. Speeding up and lowering cost of evaluation and thereby improve
  3395. attractiveness of security evaluations.
  3396.  
  3397. Discussion
  3398.  
  3399. Two key factors to the success of a security market enhancement are
  3400. that evaluations are approachable and that the products or systems are
  3401. developed in a way that is meant to meet the ITSEC requirements
  3402. beforehand. It must also be understood that in many industrial cases,
  3403. security, while indeed an important feature of a product or service, is
  3404. only one aspect of an even larger target which is product quality or
  3405. the quality of service.
  3406.  
  3407. Considerable work has been carried on in the broad field of software
  3408. quality and its engineering which might be valuable to the security
  3409. community.
  3410.  
  3411. Three standards address quality through an evaluation and certification
  3412. approach, namely ISO 9000, SEI CMM and ISO 9126, at the organisation
  3413. level, at the process level and at the product level, respectively.
  3414. Those standards are well established and the demand for certificates
  3415. based on them is growing rapidly.
  3416.  
  3417. There is an urgent need to consider the harmonisation of the ITSEC and
  3418. ITSEM contents, to take into account to a much larger and clearer
  3419. extent the benefits brought by those standards to security and to help
  3420. reduce costs and needs of several, disconnected or even conflicting
  3421. evaluations and certificates. The ITSEC approach seem to be
  3422. sufficiently well accepted today to consider its integration into a
  3423. broader context.
  3424.  
  3425. A closer technical look at quality standards and ITSEC/ITSEM taken
  3426. together shows that, although they are all basically based on the same
  3427. fundamental ideas and principles, there are residual conflicts when
  3428. evaluations are to be carried out, either due to different requirements
  3429. or to different evaluation approaches.
  3430.  
  3431. There are many ways in which the ITSEC could be turned more compatible
  3432. with the quality certification domain. The following steps seem
  3433. relevant:
  3434.  
  3435.     While preserving the current technical principles and
  3436.     requirements, a better distinction between specifically
  3437.     security related requirements and more quality related should
  3438.     be made so that it becomes clearer, if not explicit, what the
  3439.     various other evaluation systems and associated requirements
  3440.     can cover or contribute to.
  3441.  
  3442.     As all standards evolve, the ITSEC and ITSEM will have to be
  3443.     updated, at the level of the actual required deliverables for
  3444.     instance, to be directly compatible with what the other domains
  3445.     require, while still keeping its specificity.
  3446.  
  3447.     As the certification bodies of the quality fields become
  3448.     Trusted Third Parties for the ITSEC community, parts of the
  3449.     current ITSEC requirements might eventually be replaced by
  3450.     requirements for relevant quality certificates, and hopefully
  3451.     vice versa.
  3452.  
  3453. This plan suggests that the first step is one to consider directly today.
  3454.  
  3455. Few people involved today in security and its evaluation have a
  3456. software quality background, which has impeded until now the
  3457. harmonisation of the ITSEC with the other standards. Awareness raising
  3458. actions on this topic should be considered with a fairly high priority
  3459. level.
  3460.  
  3461. Requirements
  3462.  
  3463.     Alignment of security evaluation criteria and methods with
  3464.     those for quality and safety
  3465.  
  3466.     Establishment of portability of results between quality of
  3467.     service, safety and security evaluations.
  3468.  
  3469. 6.3.    Supply related issues - technological change
  3470.  
  3471. Issue
  3472.  
  3473. Changes in the way in which technology is used throughout society will
  3474. result in demands for new  technological approaches to information
  3475. security.
  3476.  
  3477. Discussion
  3478.  
  3479. Over the next decades it is to be expected that the macro economic
  3480. climate will change dramatically.  This is mainly driven by the shift
  3481. in geographic location of the generation of the worlds GDP from North
  3482. America  and Europe to a more even spread, with the Pacific rim
  3483. countries producing a larger share. The health and nutrition problems
  3484. that will face the developing world will become more acute as a greater
  3485. fraction of their population enters adulthood.
  3486.  
  3487. Information underpins these processes in a number of ways. The
  3488. financial aspects of global businesses will become vital to their
  3489. survival and the timely, accurate and where appropriate private
  3490. communication of  financial information on a global and adaptable scale
  3491. will be critical. Health care information will need to be routinely
  3492. available as health carers deal with the health problems of an
  3493. increasing number of mobile people. Transportation of food to areas in
  3494. need will require logistic information to be available in remote and
  3495. underdeveloped parts of the world quickly and accurately.
  3496.  
  3497. The developed world will make increasing use of their less structured
  3498. employment patterns to earn money in a variety of ways and in
  3499. performing a range of tasks, less and less to do with manufacturing.
  3500. Success will only be possible by the exploitation of mobility and wide
  3501. bandwidth telecommunications services. It has the potential to provide
  3502. quality of life together with high productivity. The effectiveness of
  3503. this approach, in providing a method of revenue generation, will
  3504. depend, inter alia, upon the performance, reliability and security of
  3505. the information and transportation infrastructures.
  3506.  
  3507. Driving technologies within this scenario are:
  3508.  
  3509.     Wide bandwidth telecommunications, including
  3510.     o Multi media applications and communications
  3511.     o Global teleconferencing
  3512.  
  3513.     Mobile services for all applications
  3514.  
  3515.     Gigabyte storage in portable systems
  3516.  
  3517.     Robotically controlled transportation mechanisms.
  3518.  
  3519. It will be essential for a range of security and safety features to be
  3520. embedded as a matter of design in all infrastructures, services and
  3521. applications for them to deliver the benefits that are expected by
  3522. their users.
  3523.  
  3524. Requirements
  3525.  
  3526.     Wide bandwidth telecommunications.
  3527.  
  3528.     Bandwidth will become a commodity on telecommunication systems.
  3529.     The added value in using it comes from the quality of service
  3530.     provided. One aspect of such quality is that of security. To
  3531.     provide security on wide band  public switched networks,
  3532.     investment is needed that is  focused on those aspects of
  3533.     security that are required by a) the telecoms service provider
  3534.     for his own purposes and b) the end user to support his
  3535.     application. Community wide and international specifications on
  3536.     security in ATM, SDH and associated signalling structures will
  3537.     be necessary.
  3538.  
  3539.     Multi media applications and communications
  3540.  
  3541.     Multi media applications will integrate all known
  3542.     representations of information into files, documents, messages
  3543.     and displays. Representations such as voice, audio, still
  3544.     image, text, video and graphics will become interchangeably
  3545.     available from a range of equipments that users interact with,
  3546.     including mobile telephones, personal computers, television
  3547.     sets and personal communicators. All aspects of security must
  3548.     be incorporated for potential implementation an all of these
  3549.     systems in order that a user may implement a level of security
  3550.     service appropriate to the application and the environment.
  3551.  
  3552.     A key issue is to maintain the "veracity" of the information
  3553.     transmitted. Veracity is the feature of a piece of information
  3554.     (eg a video sequence) to be true.  Veracity is a wider concept
  3555.     than integrity which is only concerned with the protection of
  3556.     information during transmission and storage.
  3557.  
  3558.     Another issue is concerned with the protection of information
  3559.     through copyright.  Without suitable technical means to
  3560.     safeguard the interests of the information owner, the evolution
  3561.     towards the information society will be seriously hampered.
  3562.  
  3563.     Global teleconferencing
  3564.  
  3565.     Teleconferencing is becoming the substitute for travel. In
  3566.     order to make it really cost effective all the above
  3567.     applications, multimedia, mobility, access to mass data and if
  3568.     necessary access to  one or more parties who are travelling in
  3569.     private vehicles need to be incorporated within the
  3570.     teleconferencing application. True geographic independence will
  3571.     come only if such an application works on a global scale and
  3572.     provides all the security services that are needed by the
  3573.     community of users. Such an application will demand the
  3574.     integration of the security services provided for each of the
  3575.     sub-applications alone. Specifications to allow such
  3576.     integration should be defined and the technology to provide the
  3577.     security functionality developed.
  3578.  
  3579.     Mobile services for applications.
  3580.  
  3581.     Mobility provides the end user with geographic independence.
  3582.     The price paid for this independence is infrastrucural
  3583.     information and process that allows his demands on the
  3584.     infrastrucural services to be met wherever he is. Such
  3585.     information and process has to, by design, have security
  3586.     features incorporated. At the community level extensions of the
  3587.     GSM concepts to allow all applications to function securely in
  3588.     the way telephony does on GSM will require significant
  3589.     technological investment.
  3590.  
  3591.     Mass data storage and communications in portable systems.
  3592.  
  3593.     Access to huge amounts of data from a mobile terminal will be
  3594.     essential. Such data needs to be communicated  securely,
  3595.     whether it be held in volatile memory, in the form of
  3596.     mechanically read ROM or transmitted over a network.
  3597.     Specifications for securing such data need to be developed as
  3598.     do the necessary bulk encryption services for huge data volumes
  3599.     . The technology components of such services will be a major
  3600.     challenge and need to be defined now.
  3601.  
  3602.     Robotically controlled transportation mechanisms.
  3603.  
  3604.     Human involvement in controlling mass transportation mechanisms
  3605.     is already decreasing as technology becomes more reliable. If
  3606.     human involvement  for individual transportation is to shrink
  3607.     in the same way then mass production of cost effective safety
  3608.     assured technologies will be essential. Collision avoidance ,
  3609.     guidance and navigation systems will be essential parts of
  3610.     every domestic vehicle and the requirements for the information
  3611.     safety and security critical elements of such systems need to
  3612.     be defined, standardised and developed .
  3613.  
  3614.  
  3615. 7.    Liability related issues (Consequences of Security and Safety Incidents)
  3616.  
  3617. 7.1.    Framework for international law relating to IS
  3618.  
  3619. [tba]
  3620.  
  3621. 7.2.    Legal provisions for liability in global services
  3622.  
  3623. Issue
  3624.  
  3625. Liability is a difficult issue under the best of conditions, but in the
  3626. context of global telematics services it remains a matter of great
  3627. concern but so far few advances have been accomplished.
  3628.  
  3629. Discussion
  3630.  
  3631. Liability is dealt with normally by a mixture of laws, regulations,
  3632. conventions and counselling reinforced by risk sharing arrangements, in
  3633. particular insurances. Legislation has so far evolved slowly and is
  3634. still far from the point where it can deal effectively with the issues
  3635. on a national level. When it comes to deal with liability under
  3636. international law things become even more difficult. The same applies
  3637. to regulations. It is only the insurance industry which has started to
  3638. cover some of the risks. With the rapid increase in the use of
  3639. telematics clearly there is a need to come to a better understanding of
  3640. liability in the context of world-wide networking of services.
  3641.  
  3642. Requirements
  3643.  
  3644. Development of international framework for private law, especially liability
  3645.  
  3646.     Application of "Verursacherprinzip"
  3647.  
  3648. Under this kind of liability the source of the information has the
  3649. responsibility to assure the proper use, its accuracy and the
  3650. compliance with the law and regulations. In the case of intermediaries
  3651. adding value the principle would be carried forward since the quality
  3652. of the information may have been significantly changed.
  3653.  
  3654.     Application of "User Principle"
  3655.  
  3656. In this case the user is made liable for the what is done with the
  3657. information and its consequences. He has to take all necessary steps to
  3658. ensure that the information is correct and applicable to its use.
  3659.  
  3660. 7.3.    Insurance issues
  3661.  
  3662. Issue
  3663.  
  3664. [tba]
  3665.  
  3666. Discussion
  3667.  
  3668. For the public safety risks are addressed by the Insurance Industry
  3669. with the premiums calculated on the basis of the assessment of risks
  3670. reflecting past experience. For the risk associated with information
  3671. systems there are only the beginning of an extension to cover this kind
  3672. of risks. As the taking out of insurance policies is a natural, or
  3673. partial alternative to IS measures, an improved methodology for the
  3674. assessment of risks is important in adopting the most economic and
  3675. practicable solution. Of course, there are some application areas where
  3676. this approach is not or only partially acceptable.
  3677.  
  3678. Requirements
  3679.  
  3680. [tba]
  3681.  
  3682. 7.4.    Monitoring of compliance
  3683.  
  3684. [tba]
  3685.  
  3686. Development of framework for the monitoring of compliance to
  3687. regulations, recommendations and good practices
  3688.  
  3689. 7.5.    Metrics for loss assessment
  3690.  
  3691. Issues
  3692.  
  3693. There is a fundamental need for guidance of any kind on how to access
  3694. the loss and damages an organisation might face and how much of this
  3695. might be addressed by evaluation and certification. Such metrics would
  3696. increase the perception of the value of a formal evaluation scheme.
  3697.  
  3698. Discussion
  3699.  
  3700. Action is necessary to ensure the effective international exploitation
  3701. of the security product evaluation and certification scheme. There must
  3702. be a competitive business advantage of developing, implementing and
  3703. using certified security products, and there must be a well understood
  3704. correlation between a certified security product and the problems that
  3705. it can solve.
  3706.  
  3707. Progress is hindered by lack of independent measures of the business
  3708. relevance of the certified product.
  3709.  
  3710. Measures can be obtained by:
  3711.  
  3712.     vendor/user studies (from actual risk assessment)
  3713.  
  3714.     product comparisons (using loss reduction models)
  3715.  
  3716.     insurance contracts (both direct and consequential damage
  3717.     assessment)
  3718.  
  3719.     vendor cost/benefit profiles (market penetration, Software
  3720.     engineering costs, etc.).
  3721.  
  3722. Such studies would prove invaluable to the SMEs who cannot justify
  3723. extensive Security controls yet are probably the most vulnerable to the
  3724. consequences of information abuse.
  3725.  
  3726. The ITSEC actions should reflect a balance between the product based
  3727. concepts of security objectives (codes of good practice) and
  3728. quantitative risk/loss assessment.
  3729.  
  3730. This should result in measured, affordable controls as a prerequisite
  3731. to developing a European and international security market.
  3732.  
  3733. Requirements.
  3734.  
  3735. Such a quantitative approach must address:
  3736.  
  3737.     mapping, certified product features to specific security incidents
  3738.  
  3739.     common, product independent risk analysis processes
  3740.  
  3741.     insurance processes recognising the advantages of certified products
  3742.  
  3743.     security incidents are the recognition by the legal, regulating
  3744.     and financial community.
  3745.  
  3746. A short term approach would be to raise awareness of the security
  3747. exposures of using poorly complying (non-assurance, non-certified)
  3748. products.
  3749.  
  3750. 8.    Spectrum of Measures
  3751.  
  3752. 8.1.    Common Framework and Consensus
  3753.  
  3754. Objective
  3755.  
  3756. To provide a minimum framework for trusted information and
  3757. communications services on an international scale and to establish a
  3758. multi actor consensus on essential requirements and options for the
  3759. provision of information security and related issues.
  3760.  
  3761. Background
  3762.  
  3763. Information and its exchange via global networks is inextricably
  3764. associated with all public and private activities involving the
  3765. citizen, service providers, operators, vendors, administrations and
  3766. authorities in numerous ways for all kind of purposes. With the
  3767. increasing globalisation of the economies an agreed framework for the
  3768. protection of information either associated with intellectual property,
  3769. privacy, internal security and other legitimate reasons is needed.
  3770. While there are several conventions and recommendations, the rapid
  3771. evolution of technology and services implies the need to reflect on a
  3772. common framework which could assist countries and regions to maintain
  3773. interworking and avoid technical barriers to trade and communications
  3774. without compromising their priorities in the protection of information
  3775. assets.
  3776.  
  3777. Solutions for open communications between a variety of parties on a
  3778. global scale do exist. They differ in detail and convenience in usage.
  3779. However, the ability to use them depends critically on a broad
  3780. consensus on the use of one or the other option. Nationally constrained
  3781. solutions, such as DES, RSA in the USA are of little utility if they
  3782. can not be used by US business in the pursuit of their global business
  3783. interests and vice versa if others can not make use of these techniques
  3784. for their communications with US partners.
  3785.  
  3786. To achieve agreement and reasonably general acceptance by the users
  3787. concerned is as important as the technical performance of the solution
  3788. in question.
  3789.  
  3790. Tasks 
  3791.  
  3792. Development of a Common Framework to address the following issues:
  3793.  
  3794.     Revision of scope and approach to information security to
  3795.     reflect the new conditions, challenges and requirements brought
  3796.     about by globalisation (4.1.)
  3797.  
  3798.     Verification of the existing provisions with respect to their
  3799.     conformance to the Internal Market Policy of the EC implying
  3800.     the removal of existing internal barriers and the avoidance of
  3801.     the formation of new technical barriers due to divergent
  3802.     application of IS rules, regulations and legislation (4.2.)
  3803.  
  3804.     Definition of a common approach defining rights,
  3805.     responsibilities and duties of citizens and business on the one
  3806.     hand, and that of the authorities on the other hand (4.3.)
  3807.  
  3808.     Development of a common approach defining the rights of
  3809.     citizens and business users on the one hand and that of
  3810.     corporations, organisations and authorities using biometric
  3811.     techniques (4.4.)
  3812.  
  3813.     Development of a generic framework for the management of open
  3814.     and protected communications in a user/business oriented
  3815.     environment (4.5.)
  3816.  
  3817.     Concerted effort to address the common requirements of
  3818.     business, citizens and authorities to adequately protect
  3819.     non-classified information and its communication (4.6.)
  3820.  
  3821.     Common approach to the assignment of responsibility and
  3822.     liability (4.9.)
  3823.  
  3824.     Clarification of "Info-Ethics" for the professional and
  3825.     individual user in its relationship to Information Security
  3826.  
  3827.     Clarification of responsibilities of the sector actors in
  3828.     general and in their relations within each other, with
  3829.     particular reference to open and distributed applications
  3830.     (4.10.)
  3831.  
  3832.     Concerted effort to address a common approach to the handling
  3833.     of security and safety critical requirements (4.10.)
  3834.  
  3835.     Development of a common approach to security evaluation of
  3836.     information systems in safety-critical environments (4.11.)
  3837.  
  3838.     Common framework for domain interworking (5.6.)
  3839.  
  3840.     Clarification of the right to signature and the attached
  3841.     authority (5.8.2.)
  3842.  
  3843.     Common approach to the security of electronically stored
  3844.     information (5.8.7.)
  3845.  
  3846.     Proposal for a frameworks and architectures which are accepted
  3847.     as well by the business users as by the national security
  3848.     agencies and the service providers (5.9.1.)
  3849.  
  3850.     Framework for the provision of trans-domain confidentiality
  3851.     services . Mechanisms are needed that provide for a defined way
  3852.     to pass from one domain to another. This will require
  3853.     collective or multilateral agreements for interoperation
  3854.     (5.9.2.)
  3855.  
  3856.     Adoption of a confidentiality algorithm standard and
  3857.     specification, and a key distribution mechanism based on an
  3858.     asymmetric public key algorithm (6.1.5.)
  3859.  
  3860.     Develop an approach to date and time stamping for time-critical
  3861.     transactions and applications (6.1.8.)
  3862.  
  3863.     Establish conditions and procedures for mutual recognition of
  3864.     evaluations (6.2.2.)
  3865.  
  3866.     Development of an agreed definition of scope and liabilities of
  3867.     vendor declarations for secure solutions (6.2.3.)
  3868.  
  3869. 8.2.    Awareness, education and training
  3870.  
  3871. Objective
  3872.  
  3873. Improved awareness of the issues of information security by specific
  3874. actions and a greater emphasis in the education and training of related
  3875. professions.
  3876.  
  3877. Background
  3878.  
  3879. In the end it is the human factor which decides the level of
  3880. information security, irrespective of the technical and operational
  3881. measures one may wish to deploy. In this sense awareness and the
  3882. teaching of appropriate skills in the context of the information
  3883. professions, is an important measure to be considered. This may entail
  3884. the creation of special training schemes and curricula, but most of all
  3885. the appropriate inclusion of information security related issues in the
  3886. teaching of information professions in general. This is in many cased
  3887. essential, since information security is very closely related to the
  3888. way information is used in a given context, ie often it has to be
  3889. embedded in the application and management procedure and can not be
  3890. added on as an external procedure.
  3891.  
  3892. Tasks
  3893.  
  3894.     Inclusion in the curriculum of relevant educational institutes
  3895.     (eg engineering, law and business schools) the use of digital
  3896.     signature (5.8.6.)
  3897.  
  3898.     Awareness of sector actors of the potential losses due to the
  3899.     absence of confidentiality services (5.9.1.)
  3900.  
  3901.     Initiate investigation to assist those member states not
  3902.     involved in the early stages of ITSEC to develop and test
  3903.     procurement policies that are based on evaluated communications
  3904.     products (5.11.)
  3905.  
  3906. 8.3.    Agreements
  3907.  
  3908. Objective
  3909.  
  3910. International agreements on a minimum set of features and operational
  3911. concepts as required for trusted and open service provision.
  3912.  
  3913. Background
  3914.  
  3915. While a common framework and general consensus may go a long way, there
  3916. is the need to get formal agreement on certain aspects. These may, for
  3917. example, relate to issues surrounding liability, accreditation and
  3918. certification and the fighting of organised crime..
  3919.  
  3920. Tasks
  3921.  
  3922. Development of a Common Framework to address the following issues:
  3923.  
  3924. 4.4.    Human Rights and biometrics
  3925.  
  3926. 4.6.    Management of Openness and Protection
  3927.  
  3928. 4.7.    Common concerns of commercial and national security
  3929.  
  3930. 4.8.    Security and Law enforcement on international scale
  3931.  
  3932. 5.6.    Security domains
  3933.  
  3934. 5.8.    Signature issues
  3935.  
  3936. 5.8.2.     The individual right to signature
  3937.  
  3938. 5.8.3.    Consistency of legal principles
  3939.  
  3940. 5.10.    Motivation to acquire evaluated products
  3941.  
  3942. 5.11.    Consistency of procurement practices
  3943.  
  3944. 6.1.4.    Use of names and certification of credentials
  3945.  
  3946. 6.1.5.    Key management service
  3947.  
  3948. 6.1.6.    Directory services
  3949.  
  3950. 6.1.7.    Legal services
  3951.  
  3952. 6.1.8.    Guaranteed date and time stamping
  3953.  
  3954. 6.1.9.    Negotiable document transaction
  3955.  
  3956. 6.2.1.    Perceived Requirements for trusted solutions
  3957.  
  3958. 6.2.2.    International harmonisation and mutual recognition
  3959.  
  3960. 6.2.3.    Vendor Declarations
  3961.  
  3962. 6.2.4.    Evaluation of applications
  3963.  
  3964. 8.4.    Common Practices and Codes of Conduct
  3965.  
  3966. Objectives
  3967.  
  3968. Development of Codes of Practice to
  3969.  
  3970.     support the development and harmonisation of sectorial practices
  3971.  
  3972.     support the development of a standardised approach to the
  3973.     development of baseline controls
  3974.  
  3975.     support the development and harmonisation of baseline controls.
  3976.  
  3977. Background
  3978.  
  3979. Codes of practice are found in many industries and disciplines. They
  3980. encapsulate the collective wisdom and experience of the practitioners
  3981. of a trade or profession or of an industry. For example codes of
  3982. practice for the building trade. To the practitioners of a trade or
  3983. profession, the need for codes of practice is self evident.
  3984.  
  3985. Codes of practice are not always obvious because they are often given
  3986. other names. In some situations they may be called standards manuals in
  3987. others requirements specifications. The property that sets them apart
  3988. and makes them recognisable as codes of practice is the encapsulation
  3989. of collective wisdom. The collective wisdom represents the means by
  3990. which all parties to a transaction are protected from harm. In legal or
  3991. business management terms this may be called a "standard of due care."
  3992.  
  3993. Any professional discipline needs to have a vehicle to encapsulate the
  3994. collective wisdom of its practitioners. They help to ensure consistency
  3995. across the wide spectrum of practitioners. That has to be true of
  3996. something as important as information processing.
  3997.  
  3998. We have mentioned elsewhere the move towards empowerment and
  3999. distributed systems. Empowerment means that the person responsible for
  4000. an operating unit of an enterprise is free to obtain its services and
  4001. resources anywhere. Where once information processing was done
  4002. in-house, it is now just as likely to be out-sourced.
  4003.  
  4004. When information was once processed centrally the computer centre was
  4005. well protected, both physically and logically. Indeed the protection of
  4006. computer centres was the trigger for the development of corporate
  4007. information security programmes. With information processing spread
  4008. throughout the enterprise, the need for a central site vanishes. With
  4009. it goes the ease of justifying the costs of high levels of security.
  4010.  
  4011. These two factors taken together mean that responsibility for
  4012. information security is fragmented and put in the hands of people who
  4013. have other responsibilities. Their mind set does not contain the same
  4014. awareness of the need for security. Neither do they understand the
  4015. interdependence of security and control measures.
  4016.  
  4017. The growth of legal, regulatory and contractual requirements for
  4018. security create the need for a generally accepted set of controls and
  4019. security measures. Words like due diligence and compliance with best
  4020. practice can be satisfied by compliance with codes of practice. They
  4021. provide the baseline needed for any comparison of actual with best
  4022. practice.
  4023.  
  4024. Looking to the future we can see that information processing will
  4025. become a basic skill for any skilled worker or manager. Where
  4026. industries have their own codes of practice governing the way they
  4027. operate, information security should become a sub-set.
  4028.  
  4029. Codes of practice must be formulated in such a way that audits can be
  4030. performed to establish compliance.
  4031.  
  4032. Tasks
  4033. Development of:
  4034.  
  4035.     Review of current design practices and codes of conduct with
  4036.     the aim of generating a community wide standard for the safety
  4037.     of systems (4.5.)
  4038.  
  4039.     Codes of practice for the handling of non-classified
  4040.     information, as opposed to classified information.  This should
  4041.     include rules for labelling of information. (4.7.)
  4042.  
  4043.     Guidelines to establish "cost of security" (4.9.)
  4044.  
  4045.     Assignment of responsibility and liability in global services (4.9.)
  4046.  
  4047.     Sector-specific codes of practice and base line controls, eg for:
  4048.     o finance
  4049.     o insurance
  4050.     o trade
  4051.     o medical
  4052.     o telecommunications
  4053.     o electronic service providers (including rules for
  4054.       inter-operation)
  4055.     o administrations
  4056.  
  4057.     (5.4.)
  4058.  
  4059.     Guidelines for the selection of security methodologies (5.5.)
  4060.  
  4061.     Code of Practice for data labelling (5.7.)
  4062.  
  4063.     Model contract clauses for contracts between service providers,
  4064.     TTPs and users, especially confidentiality service providers
  4065.     and services operating across national boundaries (5.9.1.,
  4066.     5.9.2., 5.9.3)
  4067.  
  4068.     Good practices for the operation of TTPs, specifically
  4069.     regarding availability, confidentiality, response times, rules
  4070.     of disclosure (6.1.2.)
  4071.  
  4072.     International guidelines for the accreditation and audit of
  4073.     TTPs (6.1.3.)
  4074.  
  4075.     International guidelines for
  4076.     o naming and certification
  4077.     o key management
  4078.     o directory services
  4079.     o legal services
  4080.     o time stamping
  4081.     o negotiable document transactions
  4082.     (6.1.4., to 6.1.9.)
  4083.  
  4084.     Rules for vendor declarations, as to the security of their
  4085.     products (6.2.3.)
  4086.  
  4087.     User and supplier obligations to report incidents (6.2.8.)
  4088.  
  4089.     Guidelines for the monitoring of compliance to codes of
  4090.     practice (7.4.)
  4091.  
  4092.     Rules for loss assessment (7.5.)
  4093.  
  4094. 8.5.    Specifications
  4095.  
  4096. Objectives
  4097.  
  4098. To develop specifications for the application of security, in order to
  4099. ensure interworking, interoperation and mutual recognition.
  4100.  
  4101. Background
  4102.  
  4103. Functional specifications for products or services are documents that
  4104. are to be used as parts of purchase specifications. They specify the
  4105. functions of a solution and the required performance characteristics.
  4106. Implementation aspects are only dealt with if they are particularly
  4107. important for the fulfilment of a specific function. Specifications
  4108. call up standards and profiles, as far as available.  Options in the
  4109. standards are resolved in specifications.
  4110.  
  4111. Common specifications for methodologies, eg evaluation, serve as a
  4112. basis for mutual recognition.
  4113.  
  4114. Tasks
  4115.  
  4116. Development of:
  4117.  
  4118.     Specifications for solutions to confidentiality and integrity
  4119.     services (4.8.)
  4120.  
  4121.     Methodologies for the assessment of threats, vulnerabilities,
  4122.     and hazards for safety critical systems (4.11.)
  4123.  
  4124.     Development of methods of testing that enable standards of
  4125.     reliability to be ensured, including tests to destruction where
  4126.     appropriate (4.12.)
  4127.  
  4128.     Definition of requirements for fail-safe system architectures
  4129.     and implementations (4.12.)
  4130.  
  4131.     Specifications of security evaluations for safety critical
  4132.     environments
  4133.  
  4134.     Taxonomy of user requirements for enterprises, individuals and
  4135.     citizens (5.1., 5.2.)
  4136.  
  4137.     Identify and group access control scenarios, to determine
  4138.     levels of commonality (5.8.1.)
  4139.  
  4140.     Identify techniques, products, specifications and standards
  4141.     addressing access control, and associate them with the
  4142.     identified scenarios (5.8.1.)
  4143.  
  4144.     Identify parameters common to most or all of the above
  4145.     techniques, products, specifications and standards and
  4146.     investigate the feasibility of establishing common formats for
  4147.     them (5.8.1.)
  4148.  
  4149.     Identify the key features for coherence in the supporting
  4150.     infrastructure (5.8.1.)
  4151.  
  4152.     Define a limited number of basic access control mechanisms for
  4153.     pilot implementation (5.8.1.)
  4154.  
  4155.     Specification of a signature scheme (5.8.4.)
  4156.  
  4157.     Specification of application oriented integration of the
  4158.     signature scheme (5.8.4.)
  4159.  
  4160.     Specification of an Application Program Interface (API) for the
  4161.     signature scheme (5.8.4.)
  4162.  
  4163.     Specification of the use of multiple signatures (5.8.4.)
  4164.  
  4165.     Specification of key usage for integrity and confidentiality
  4166.     (5.8.5.)
  4167.  
  4168.     Specification for the practical use of digital signatures as a
  4169.     full equivalent to manual signatures (5.8.6.)
  4170.  
  4171.     Specification for the handling of electronically stored
  4172.     information (5.8.7.)
  4173.  
  4174.     Specification of an approach to confidentiality (5.9.1.)
  4175.  
  4176.     Assurance criteria for confidentiality service providers and
  4177.     operators (5.9.2.)
  4178.  
  4179.     Specification for the inter-operability of confidentiality
  4180.     services (5.9.3.)
  4181.  
  4182.     Specification for date and time stamping (6.1.8.)
  4183.  
  4184. 8.6.    Standards
  4185.  
  4186. Objective
  4187.  
  4188. Development of standards for IS.
  4189.  
  4190. Background
  4191.  
  4192. European security standards developed over the next decade will have a
  4193. decisive influence on the technological structure of the entire
  4194. European market and will change the conditions of trade in export
  4195. markets and national markets.
  4196.  
  4197. The standards making infrastructure for the development of IT and
  4198. telecommunication standards has become increasingly complex. The number
  4199. of groups, the range of work items and the  overall process at
  4200. different levels of international, regional and national
  4201. standardisation is a complex maze. Security standardisation is no
  4202. exception to this situation. In general there is a reoccurring problem
  4203. which is that of coordination between groups developing standards
  4204. similar in nature and scope. Such coordination is necessary to avoid
  4205. duplication of work and the unnecessary waste of resource, and to
  4206. ensure that the standards that are developed are consistent and  they
  4207. form a coherent set.
  4208.  
  4209. At the European level the establishment of the Advisory Expert Group
  4210. ITAEGV has provided an ideal mechanism for the coordination of security
  4211. standards work within Europe. In addition, ITAEGV is in the process of
  4212. developing a European Memorandum, M-IT-06, which is a Taxonomy and
  4213. Directory of European Standardisation Requirements for Information
  4214. Systems Security based on market driven requirements. This memorandum
  4215. also contains a future work programme for security standardisation.
  4216.  
  4217. Hence Europe is now demonstrating through this action a clearly defined
  4218. strategic stance on security standardisation. One that is demonstrating
  4219. effective coordination, leadership and a market driven focused approach
  4220. to standardisation.
  4221.  
  4222. Traditionally the principal contributors to standards making have been
  4223. suppliers, designers and professionals. The end user of products and
  4224. services has only been peripherally interested or involved. The end
  4225. user has been concerned that standards have been used in relation to
  4226. the products he buys but not greatly interested in what they are.
  4227.  
  4228. There is a need for a more effective mechanism and framework through
  4229. which user interest is able to collectively express their requirements
  4230. and priorities so that they can contribute to the standardisation
  4231. process in a way which will balance the very strong interest of the
  4232. supply industry.
  4233.  
  4234. This mechanism should be used to provide greater user input into the
  4235. development of the European Memorandum, M-IT-06 (The Taxonomy and
  4236. Directory of European Standardisation Requirements for Information
  4237. Systems Security). This memorandum also contains a future work
  4238. programme for security standardisation.
  4239.  
  4240. The long-term benefits of security standardisation requires investment
  4241. by companies and users and as such they must be prepared to organise
  4242. themselves more effectively to participate in the standards making
  4243. process.
  4244.  
  4245. Tasks
  4246.  
  4247.     Define a solution to the specification, standardisation and
  4248.     licensing problem of cryptographic algorithms(5.8.4.).
  4249.  
  4250. Develop standards for:
  4251.  
  4252.     identify and group access control scenarios, to determine
  4253.     levels of commonality (5.8.1.)
  4254.  
  4255.     identify techniques, products, specifications and standards
  4256.     addressing access control, and associate them with the
  4257.     identified scenarios (5.8.1.)
  4258.  
  4259.     identify parameters common to most or all of the above
  4260.     techniques, products, specifications and standards and
  4261.     investigate the feasibility of establishing common formats for
  4262.     them (5.8.1.)
  4263.  
  4264.     identify the key features for coherence in the supporting
  4265.     infrastructure (5.8.1.)
  4266.  
  4267.     define a limited number of basic access control mechanisms for
  4268.     pilot implementation (5.8.1.)
  4269.  
  4270.     Digital signatures, including for application oriented
  4271.     integration and a general application programming interface
  4272.     (API) for integration of security services which could be
  4273.     easily integrated into any (almost) application (5.8.4.)
  4274.  
  4275.     Profile - or functional - standards to support CCITT X.509 (5.8.5.)
  4276.  
  4277.     Services and service provision. Ensure that the confidentiality
  4278.     services are compatible with existing communication standards
  4279.     and practices where possible (5.9.1.)
  4280.  
  4281.     Minimum requirements to ensure interoperability of procedure
  4282.     and operating practices for confidentiality services (5.9.3.)
  4283.  
  4284.     Evaluation criteria and methods (6.2.2.).
  4285.  
  4286. 8.7.    Products and Services
  4287.  
  4288. Objective
  4289.  
  4290. In order to facilitate a harmonious development of the provision of
  4291. security of information systems in the Community for the protection of
  4292. the public and of business interests, it will be necessary to develop a
  4293. consistent approach as to its provision of security. Where independent
  4294. organisations will have to be mandated, their functions and conditions
  4295. will need to be defined and agreed and, where required, embedded into
  4296. the regulatory framework. The objective would be to come to a clearly
  4297. defined and agreed sharing of responsibilities between the different
  4298. actors on a Community level as a prerequisite for mutual recognition.
  4299.  
  4300. Background
  4301.  
  4302. At present, the provision of security of information systems is well
  4303. organised only for specific areas and limited to addressing their
  4304. specific needs. The organisation on a European level is mostly
  4305. informal, and mutual recognition of verification and certification is
  4306. not yet established outside closed groups. With the growing importance
  4307. of the security of information systems, the need for defining a
  4308. consistent approach to the provision of security for information
  4309. systems in Europe and internationally is becoming urgent. The most
  4310. urgent needs identified relate to digital signatures and
  4311. confidentiality services.
  4312.  
  4313. Tasks
  4314.  
  4315.     Verification of the existing provisions with respect to their
  4316.     conformance to the Internal Market Policy of the EC implying
  4317.     the removal of existing internal barriers and the avoidance of
  4318.     the formation of new technical barriers due to divergent
  4319.     application of IS rules, regulations and legislation (4.2.)
  4320.  
  4321.     Provision of IS to business and the public of solutions freely
  4322.     applicable throughout the Community and on a preferential basis
  4323.     at the international level (4.2.)
  4324.  
  4325.     An effective, internationally agreed, economic, ethical and
  4326.     usable solution to meet business, administration and personal
  4327.     needs including mechanisms for authorised interception and
  4328.     reporting of incidents and crimes adjusted to the conditions of
  4329.     the Internal Market, and to include the necessary equipment and
  4330.     software, but also an infrastructure of Trusted Third Parties.
  4331.     This will discourage "home-made" or other solutions (4.8.)
  4332.  
  4333.     Recommendation for the implementation for a public digital
  4334.     signature scheme for use by business, administrations and the
  4335.     general public (5.8.3.)
  4336.  
  4337.     Development of a general application programming interface
  4338.     (API) for integration of security services which could be
  4339.     easily integrated into most application (This could as well
  4340.     include codes which explain the intention of the applied
  4341.     signature.) (5.8.4.)
  4342.  
  4343.     Development of transaction-oriented multiple signature schemes
  4344.     (5.8.4.)
  4345.  
  4346.     Framework for the provision of trans-domain confidentiality
  4347.     services (Mechanisms are needed that provide for a defined way
  4348.     to pass from one domain to another. This will require
  4349.     collective or multilateral agreements for interoperation.)
  4350.     (5.9.2.)
  4351.  
  4352.     Demonstration of trans-European confidentiality services using
  4353.     a suitable application , eg the realisation of administrative
  4354.     telematics applications (5.9.3.)
  4355.  
  4356.     Trial service evaluations for existing telecommunication
  4357.     services (6.2.5.)
  4358.  
  4359.     Incident reporting system for Certification Bodies (6.2.8.)
  4360.  
  4361. 8.8.    Technology
  4362.  
  4363. Objective
  4364.  
  4365. Systematic investigation and development of the technology to permit
  4366. economically viable and operationally satisfactory solutions to a range
  4367. of present and future requirements for the security of information
  4368. systems.
  4369.  
  4370. Background
  4371.  
  4372. Work on security of information systems would need to address
  4373. development and implementation strategies, technologies, and
  4374. integration and verification.
  4375.  
  4376. The strategic R&D work would have to cover conceptual models for secure
  4377. systems (secure against compromise, unauthorised modifications and
  4378. denial of service), functional requirements models, risk models and
  4379. architectures for security.
  4380.  
  4381. Verification and validation of the security of the technical system and
  4382. its applicability would be investigated through integration and
  4383. verification projects.
  4384.  
  4385. In addition to the consolidation and development of security
  4386. technology, a number of accompanying measures are required concerned
  4387. with the creation, maintenance and consistent application of standards,
  4388. and the validation and certification of IT and telecommunication
  4389. products with respect to their security properties, including
  4390. validation and certification of methods to design and implement
  4391. systems.
  4392.  
  4393. The fourth RD&T Community Framework Programme might be one of the tools
  4394. to foster co-operative projects at precompetitive and prenormative
  4395. levels.
  4396.  
  4397. Tasks
  4398.  
  4399.     Demonstration, through pilot projects, that digital signatures
  4400.     can be used as equivalent to hand-written signatures (5.8.6.)
  4401.  
  4402.     Development of techniques for the establishment, handling and
  4403.     recording of Electronic Negotiable Documents (6.1.9.)
  4404.  
  4405.     Adapt to technological change:
  4406.  
  4407.     Wide bandwidth telecommunications.
  4408.  
  4409.     Bandwidth will become a commodity on telecommunication systems.
  4410.     The added value in using it comes from the quality of service
  4411.     provided. One aspect of such quality is that of security. To
  4412.     provide security on wide band  public switched networks,
  4413.     investment is needed that is  focused on those aspects of
  4414.     security that are required by a) the telecoms service provider
  4415.     for his own purposes and b) the end user to support his
  4416.     application. Community wide and international specifications on
  4417.     security in ATM, SDH and associated signalling structures will
  4418.     be necessary.
  4419.  
  4420.     Multi media  applications and communications
  4421.  
  4422.     Multi media applications will integrate all known
  4423.     representations of information into files, documents, messages
  4424.     and displays. Representations such as voice, audio, still
  4425.     image, text, video and graphics will become interchangeably
  4426.     available from a range of equipments that users interact with,
  4427.     including mobile telephones, personal computers, television
  4428.     sets and personal communicators. All aspects of security must
  4429.     be incorporated for potential implementation an all of these
  4430.     systems in order that a user may implement a level of security
  4431.     service appropriate to the application and the environment.
  4432.  
  4433.     A key issue is to maintain the "veracity" of the information
  4434.     transmitted. Veracity is the feature of a piece of information
  4435.     (eg a video sequence) to be true.  Veracity is a wider concept
  4436.     than integrity which is only concerned with the protection of
  4437.     information during transmission and storage.
  4438.  
  4439.     Another issue is concerned with the protection of information
  4440.     through copyright.  Without suitable technical means to
  4441.     safeguard the interests of the information owner, the evolution
  4442.     towards the information society will be seriously hampered.
  4443.  
  4444.     Global teleconferencing
  4445.  
  4446.     Teleconferencing is becoming the substitute for travel. In
  4447.     order to make it really cost effective all the above
  4448.     applications, multimedia, mobility, access to mass data and if
  4449.     necessary access to  one or more parties who are travelling in
  4450.     private vehicles need to be incorporated within the
  4451.     teleconferencing application. True geographic independence will
  4452.     come only if such an application works on a global scale and
  4453.     provides all the security services that are needed by the
  4454.     community of users. Such an application will demand the
  4455.     integration of the security services provided for each of the
  4456.     sub-applications alone. Specifications to allow such
  4457.     integration should be defined and the technology to provide the
  4458.     security functionality developed.
  4459.  
  4460.     Mobile services for applications.
  4461.  
  4462.     Mobility provides the end user with geographic independence.
  4463.     The price paid for this independence is infrastrucural
  4464.     information and process that allows his demands on the
  4465.     infrastrucural services to be met wherever he is. Such
  4466.     information and process has to, by design, have security
  4467.     features incorporated. At the community level extensions of the
  4468.     GSM concepts to allow all applications to function securely in
  4469.     the way telephony does on GSM will require significant
  4470.     technological investment.
  4471.  
  4472.     Mass data storage and communications in portable systems.
  4473.  
  4474.     Access to huge amounts of data from a mobile terminal will be
  4475.     essential. Such data needs to be communicated  securely,
  4476.     whether it be held in volatile memory, in the form of
  4477.     mechanically read ROM or transmitted over a network.
  4478.     Specifications for securing such data need to be developed as
  4479.     do the necessary bulk encryption services for huge data volumes.
  4480.     The technology components of such services will be a major
  4481.     challenge and need to be defined now.
  4482.  
  4483.     Robotically controlled transportation mechanisms.
  4484.  
  4485.     Human involvement in controlling mass transportation mechanisms
  4486.     is already decreasing as technology becomes more reliable. If
  4487.     human involvement  for individual transportation is to shrink
  4488.     in the same way then mass production of cost effective safety
  4489.     assured technologies will be essential. Collision avoidance,
  4490.     guidance and navigation systems will be essential parts of
  4491.     every domestic vehicle and the requirements for the information
  4492.     safety and security critical elements of such systems need to
  4493.     be defined, standardised and developed .
  4494.  
  4495. 8.9.    Regulation and Legislation
  4496.  
  4497. Objective
  4498.  
  4499. Adjustment of national regulations and legislation to permit seamless
  4500. interworking of trusted services.
  4501.  
  4502. Background
  4503.  
  4504. The provision of information security is seen to related in some areas
  4505. closely to public order and defence issues. The related national
  4506. regulations and legislations vary considerably. In order to avoid the
  4507. creation of technical barriers to trade and communications outside the
  4508. domains of internal order and national security, adjustments of
  4509. legislation and regulations may be required in some countries.
  4510.  
  4511. Tasks
  4512.  
  4513. Development of a legal framework to address the following issues:
  4514.  
  4515.     Verification of the existing provisions with respect to their
  4516.     conformance to the Internal Market Policy of the EC implying
  4517.     the removal of existing internal barriers and the avoidance of
  4518.     the formation of new technical barriers due to divergent
  4519.     application of IS rules, regulations and legislation (4.2.)
  4520.  
  4521.     Clarification of the ownership and privacy issues surrounding
  4522.     biometric data (4.4.)
  4523.  
  4524.     Study the legal environment within which vendors and users of
  4525.     safety critical systems work, with the objective of harmonising
  4526.     that environment (4.5.)
  4527.  
  4528.     Need to provide business and the general public with an
  4529.     effective, economic and usable security solution to meet their
  4530.     needs including a mechanism for authorised interception (4.8.)
  4531.  
  4532.     Establishment of a network of Trusted Third Parties to provide
  4533.     user support and manage directories (4.8.)
  4534.  
  4535.     Clarification of responsibilities of the sector actors in
  4536.     general and in their relations within each other, with
  4537.     particular reference to open and distributed applications
  4538.     (4.10.)
  4539.  
  4540.     Agreement on management, TTPs, accreditation, auditing and
  4541.     relations with law enforcement agencies (5.6.)
  4542.  
  4543.     Clarification of the right to signature and the attached
  4544.     authority (5.8.3.)
  4545.  
  4546.     The legal functions of signatures need to be agreed
  4547.     EC-wide/internationally. Once this is achieved, it is possible
  4548.     to determine to what extent a code-of- practice will suffice.
  4549.     One issue to be addressed is the intended use of the digital
  4550.     signature, and the legal responsibility and liability of the
  4551.     signing entity with regard to the signed information (5.8.3.)
  4552.  
  4553.     Clarification of the conditions of acceptance of the authority
  4554.     of an electronic signature, eg for legally binding purposes, ie
  4555.     as substitute for hand-written original signatures (5.8.3.)
  4556.  
  4557.     Solution to the licensing problem of cryptographic algorithms
  4558.     (5.8.4.)
  4559.  
  4560.     Definition of minimum requirements to ensure interoperability,
  4561.     including standards, specifications, rules of procedure and
  4562.     operating practices for autonomous confidentiality services
  4563.     (5.9.3.)
  4564.  
  4565.     Alignment of national procurement policies concerning evaluated
  4566.     products (5.11.)
  4567.  
  4568.     Definition of the classes of information used and the types of
  4569.     damage that could be caused to the information owners (5.12.)
  4570.  
  4571.     Definition of the rights and duties of information ownership
  4572.     (5.12.)
  4573.  
  4574.     Development of guidance for owners of information as to the
  4575.     actions that they would have been expected to take to protect
  4576.     their assets and avoid negligence charges (5.12.)
  4577.  
  4578.     Development of the methods and procedures that should be used
  4579.     to establish information value (5.12.)
  4580.  
  4581.     Introduce or harmonise legislation to provide an appropriate
  4582.     framework for arbitration, supervision and litigation (6.1.2.)
  4583.  
  4584.     Adapt applicable legislation or regulations to provide an
  4585.     appropriate legal framework for use throughout the Community
  4586.     and in the relations with third countries (6.1.3.)
  4587.  
  4588.     Harmonisation of legislation on the legal status of evidence
  4589.     generated by any TTPs and especially on the intra- and extra-
  4590.     community recognition thereof. This probably implies the
  4591.     settlement of the accreditation question.
  4592.  
  4593.     Promotion of community-level information technology litigation
  4594.     services modelled after existing international bodies such as
  4595.     the International Chamber of Commerce (6.1.7.)
  4596.  
  4597.     Framework for international law relating to IS (7.1.)
  4598.  
  4599.     Development of international framework for private law,
  4600.     especially liability (7.2.)
  4601.  
  4602. 8.10.   Accreditation
  4603.  
  4604. 8.10.1. Accreditation of Services
  4605.  
  4606. Objective
  4607.  
  4608. Evaluation of communication services.
  4609.  
  4610. Background
  4611.  
  4612. Common criteria for security evaluation are mainly focused on IT
  4613. products and IT systems.  However, there is a perceived need for
  4614. criteria to support the evaluation of communication services.  This
  4615. later criteria may be considered as an extension to the current
  4616. criteria or there may be a need to develop separate criteria.
  4617.  
  4618. The evaluation of a service and its subsequent accreditation will be a
  4619. critical requirement in many user applications, in particular those
  4620. that need to use trans-European communication services. The
  4621. consistency, completeness and effectiveness of the security
  4622. enhancements of communication services needs to be checked for an
  4623. overall fitness for purpose. Hence there is a need for a framework for
  4624. accreditation of communications services.
  4625.  
  4626. Tasks
  4627.  
  4628.     Establishment of a formal accreditation scheme for secure
  4629.     communication services (6.2.5.)
  4630.  
  4631.     Development of accreditation guidelines for the
  4632.     telecommunication sector (6.2.5.)
  4633.  
  4634.     Accreditation guidelines for the trusted network management
  4635.     (6.2.6.)
  4636.  
  4637. 8.10.2. Accreditation of TTPs
  4638.  
  4639. Objective
  4640.  
  4641. Procedures for the accreditation and audit of TTPs.
  4642.  
  4643. Background
  4644.  
  4645. TTPs will need to interwork and communicate internationally to provide
  4646. a service infrastructure to support a range of security services such
  4647. as digital signature and confidentiality.  TTPs will thus need to
  4648. process, store and distribute a range of security-related information
  4649. for the use and management of such services. This implies the need for
  4650. a set of harmonised procedures for the accreditation and audit of TTPs
  4651. in order to ensure mutual trust by the public in TTPs and the services
  4652. they provide.
  4653.  
  4654. Tasks
  4655.  
  4656.     Development of international guidelines for the accreditation
  4657.     and audit of TTPs (6.1.3.)
  4658.  
  4659.     Adaptation of applicable legislation or regulations to provide
  4660.     an appropriate legal framework for use throughout the Community
  4661.     and in the relations with third countries (6.1.3.)
  4662.  
  4663. Annex: Recalling the Action Lines from the Council mandate
  4664.  
  4665. Action line I - Development of a strategic framework for the security
  4666. of information systems
  4667.  
  4668. Issue
  4669.  
  4670. Security of information systems is recognized as a pervasive quality
  4671. necessary in modern society. Electronic information services need a
  4672. secure telecommunications infrastructure, secure hard- and software as
  4673. well as secure usage and management. An overall strategy, considering
  4674. all aspects of security of information systems, needs to be
  4675. established, avoiding a fragmented approach. Any strategy for the
  4676. security of information processed in an electronic form must reflect
  4677. the wish of any society to operate effectively yet protect itself in a
  4678. rapidly changing world.
  4679.  
  4680. Objective
  4681.  
  4682. A strategically oriented framework has to be established to reconcile
  4683. social, economic and political objectives with technical, operational
  4684. and legislative options for the Community in an international context.
  4685. The sensitive balance between different concerns, objectives and
  4686. constraints are to be found by sector actors working together in the
  4687. development of a common perception and agreed strategy framework. These
  4688. are the are the prerequisites for reconciling interests and needs both
  4689. in policy-making and in industrial developments.
  4690.  
  4691. Status and trends
  4692.  
  4693. The situation is characterized by growing awareness of the need to act.
  4694. However, in the absence of an initiative to coordinate efforts, it
  4695. seems very likely that dispersed efforts various sectors will create a
  4696. situation which will de facto be contradictory, creating progressively
  4697. more serious legal, social and economic problems.
  4698.  
  4699. Requirements, options and priorities
  4700.  
  4701. Such a shared framework would need to address and situate risk analysis
  4702. and risk management concerning the vulnerability of information and
  4703. related services, the alignment of laws and regulations associated with
  4704. computer/telecommunications abuse and misuse, administrative
  4705. infrastructures including security policies, and how these may be
  4706. effectively implemented by various industries/disciplines, and social
  4707. and privacy concerns (e.g. the application of identification,
  4708. authentication, non-repudiation and possibly authorization schemes in a
  4709. democratic environment ).
  4710.  
  4711. Clear guidance is to be provided for the development of physical and
  4712. logical architectures for secure distributed information services,
  4713. standards, guidelines and definitions for assured security products and
  4714. services, pilots and prototypes to establish the viability of various
  4715. administrative structures, architectures and standards related to the
  4716. needs of specific sectors.
  4717.  
  4718. Security awareness must be created in order to influence the attitude
  4719. of the users towards an increased concern about security in information
  4720. technology (IT).
  4721.  
  4722. Action line II - Identification of user and service provider
  4723. requirements for the security of information systems
  4724.  
  4725. Issues
  4726.  
  4727. Security of information systems is the inherent prerequisite for the
  4728. integrity and trustworthiness of business applications, intellectual
  4729. property and confidentiality. This leads inevitably to a difficult
  4730. balance and sometimes choices, between a commitment to free trade and a
  4731. commitment to securing privacy and intellectual property. These choices
  4732. and compromises need to be based on a full appreciation of requirements
  4733. and the impact of possible options for the security of information
  4734. systems to respond to them.
  4735.  
  4736. User requirements imply the security functionalities of information
  4737. systems interdependent with technological, operational and regulatory
  4738. aspects. Therefore, a systematic investigation of security requirements
  4739. for information systems forms an essential part of the development of
  4740. appropriate and effective measures.
  4741.  
  4742. Objective
  4743.  
  4744. Establishing the nature and characteristics of requirements of users
  4745. and service providers and their relation to security measures of
  4746. information systems.
  4747.  
  4748. Status and trends
  4749.  
  4750. Hitherto, no concerted effort has been undertaken to identify the
  4751. rapidly evolving and changing requirements of the major actors for the
  4752. security of information systems. Member States of the Community have
  4753. identified the requirements for harmonization of national activities
  4754. (especially of the "IT security evaluation criteria"). Uniform
  4755. evaluation criteria and rules for mutual recognition of evaluation
  4756. certification are of major importance.
  4757.  
  4758. Requirements, options and priorities
  4759.  
  4760. As a basis for a consistent and transparent treatment of the justified
  4761. needs of the sector actors, it is considered necessary to develop an
  4762. agreed classification of user requirements and its relation to the
  4763. provision of security in information systems.
  4764.  
  4765. It is also considered important to identify requirements for
  4766. legislation, regulations and codes of practice in the light of an
  4767. assessment of trends in service characteristics and technology, to
  4768. identify alternative strategies for meeting the objectives by
  4769. administrative, service, operational and technical provisions, and to
  4770. assess the effectiveness, user friendliness and costs of alternative
  4771. security options and strategies for information systems for users,
  4772. service providers and operators.
  4773.  
  4774. Action Line III - Solutions for immediate and interim needs of users,
  4775. suppliers and service providers
  4776.  
  4777. Issues
  4778.  
  4779. At present it is possible to protect adequately computers from
  4780. unauthorized access from the outside world by "isolation", i.e. by
  4781. supplying conventional organizational and physical measures. This
  4782. applies also to electronic communications within closed user group
  4783. operating on a dedicated network. The situation is very different if
  4784. the information is shared between user groups or exchanged via a
  4785. public, or generally accessible, network. Neither the technology,
  4786. terminals and services nor the related standards and procedures are
  4787. generally available to provide comparable security for information
  4788. systems in these cases.
  4789.  
  4790. Objectives
  4791.  
  4792. The objective has to be to provide, at short notice, solutions which
  4793. can respond to the most urgent needs of users, service providers and
  4794. manufacturers. This includes the use of common IT-security evaluation
  4795. criteria. These should be conceived as open towards future requirements
  4796. and solutions.
  4797.  
  4798. Status and trends
  4799.  
  4800. Some user groups have developed techniques and procedures for their
  4801. specific use responding, in particular, to the need for authentication,
  4802. integrity and non-repudiation. In general, magnetic cards or smart
  4803. cards are being used. Some are using more or less sophisticated
  4804. cryptographic techniques. Often this implied the definition of
  4805. user-group specific "authorities". However, it is difficult to
  4806. generalise these techniques and methods to meet the needs of an open
  4807. environment.
  4808.  
  4809. ISO is working on OSI Information System Security (ISO DIS 7498-2) and
  4810. CCITT in the context of X400. It is also possible to insert security
  4811. segments into the messages. Authentication, integrity and
  4812. non-repudiation are being addressed as part of the messages (EDIFACT)
  4813. as well as part of the X400 MHS.
  4814.  
  4815. At present, the Electronic Data Interchange (EDI) legal framework is
  4816. still at the stage of conception. The International Chamber of Commerce
  4817. has published uniform rules of conduct for the exchange of commercial
  4818. data via telecommunications networks.
  4819.  
  4820. Several countries (e.g. Germany, France, the United Kingdom and the
  4821. United States) have developed, or are developing, criteria to evaluate
  4822. the trustworthiness of IT and telecommunication products and systems
  4823. and the corresponding procedures for conducting evaluations. These
  4824. criteria have been coordinated with the national manufacturers and will
  4825. lead to an increasing number of reliable products and systems starting
  4826. with simple products. The establishment of national organizations which
  4827. will conduct evaluations and offer certificates will support this
  4828. trend.
  4829.  
  4830. Confidentiality provision is considered by most users as less
  4831. immediately important. In the future, however, this situation is likely
  4832. to change as advanced communication services and, in particular, mobile
  4833. services will have become all-pervasive.
  4834.  
  4835. Requirements, options and priorities
  4836.  
  4837. It is essential to develop as soon as possible the procedures,
  4838. standards, products and tools suited to assure security both in
  4839. information systems as such (computers, peripherals) and in public
  4840. communications networks. A high priority should be given to
  4841. authentication, integrity and non-repudiation. Pilot projects should be
  4842. carried out to establish the validity of the proposed solutions.
  4843. Solutions to priority needs on EDI are looked at in the TEDIS programme
  4844. within the more general content of this action plan.
  4845.  
  4846. Action line IV - Development of specifications, standardization,
  4847. evaluation and certification in respect of the security of information
  4848. systems
  4849.  
  4850. Issues
  4851.  
  4852. Requirements for the security of information systems are pervasive and
  4853. as such common specifications and standards are crucial. The absence of
  4854. agreed standards and specifications for IT security may present a major
  4855. barrier to the advance of information-based processes and services
  4856. throughout the economy and society. Actions are also required to
  4857. accelerate the development and use of technology and standards in
  4858. several related communication and computer network areas that are of
  4859. critical importance to users, industry and administrations.
  4860.  
  4861. Objective
  4862.  
  4863. Efforts are required to provide a means of supporting and performing
  4864. specific security functions in the general areas of OSI, ONP, ISDN/IBC
  4865. and network management. Inherently related to standardization and
  4866. specification are the techniques and approaches required for
  4867. verification, including certification leading to mutual recognition.
  4868. Where possible, internationally agreed solutions are to be supported.
  4869. The development and use of computer systems with security functions
  4870. should also be encouraged.
  4871.  
  4872. Status and trends
  4873.  
  4874. The United States, in particular, has taken major initiatives to
  4875. address the security of information systems. In Europe the subject is
  4876. treated in the context of IT and telecommunications standardization in
  4877. the context of ETSI and CEN/CENELEC in preparation of CCITT and ISO
  4878. work in the field.
  4879.  
  4880. In view of growing concern, the work in the United States is rapidly
  4881. intensifying and both vendors and service providers are increasing
  4882. their efforts in this area In Europe, France, Germany and the United
  4883. Kingdom have independently started similar activities, but a common
  4884. effort corresponding to the United States is evolving only slowly.
  4885.  
  4886. Requirements, options and priorities
  4887.  
  4888. In the security of information systems there is inherently a very close
  4889. relationship between regulatory, operational, administrative and
  4890. technical aspects. Regulations need to be reflected in standards, and
  4891. provisions for the security of information systems need to comply in a
  4892. verifiable manner to the standards and regulations. In several aspects,
  4893. regulations require specifications which go beyond the conventional
  4894. scope of standardization, i.e. include codes of practice. Requirements
  4895. for standards and codes of practice are present in all areas of
  4896. security of information systems, and a distinction has to be made
  4897. between the protection requirements which correspond to the security
  4898. objectives and some of the technical requirements which can be
  4899. entrusted to the competent European standards bodies (CEN/CENELEC/
  4900. ETSI).
  4901.  
  4902. Specifications and standards must cover the subjects of security
  4903. services of information systems (personal and enterprise
  4904. authentication, non-repudiation protocols, legally acceptable
  4905. electronic proof, authorisation control), their communication services
  4906. (image communication privacy, mobile communications voice and data
  4907. privacy, data and image data-base protection, integrated services
  4908. security), their communication and security management (public/private
  4909. key system for open network operation, network management protection,
  4910. service provider protection) and their certification (assurance
  4911. criteria and levels, security assurance procedures for secure
  4912. information systems).
  4913.  
  4914. Action line V - Technological and operational developments in the
  4915. security of information systems
  4916.  
  4917. Issues
  4918.  
  4919. Systematic investigation and development of the technology to permit
  4920. economically viable and operationally satisfactory solutions to a range
  4921. of present and future requirements for the security of information
  4922. systems is a prerequisite for the development of the services market
  4923. and the competitiveness of the European economy as a whole.
  4924.  
  4925. Any technological developments in the security of information systems
  4926. will have to include both the aspects of computer security and security
  4927. of communications as most present-day systems are distributed systems,
  4928. and access to such systems is through communications services.
  4929.  
  4930. Objective
  4931.  
  4932. Systematic investigation and development of the technology to permit
  4933. economically viable and operationally satisfactory solutions to a range
  4934. of present and future requirements for the security of information
  4935. systems.
  4936.  
  4937. Requirements, options and priorities
  4938.  
  4939. Work on security of information systems would need to address
  4940. development and implementation strategies, technologies, and
  4941. integration and verification.
  4942.  
  4943. The strategic R&D work would have to cover conceptual models for secure
  4944. systems (secure against compromise, unauthorized modifications and
  4945. denial of service), functional requirements models, risk models and
  4946. architectures for security.
  4947.  
  4948. The technology-oriented R&D work would have to include user and message
  4949. authentication (e.g. through voice-analysis and electronic signatures),
  4950. technical interfaces and protocols for encryption, access control
  4951. mechanisms and implementation methods for provable secure systems.
  4952.  
  4953. Verification and validation of the security of the technical system and
  4954. its applicability would be investigated through integration and
  4955. verification projects.
  4956.  
  4957. In addition to the consolidation and development of security
  4958. technology, a number of accompanying measures are required concerned
  4959. with the creation, maintenance and consistent application of standards,
  4960. and the validation and certification of IT and telecommunication
  4961. products with respect to their security properties, including
  4962. validation and certification of methods to design and implement
  4963. systems.
  4964.  
  4965. The third RD&T Community Framework Programme might be used to foster
  4966. cooperative projects at precompetitive and prenormative levels.
  4967.  
  4968. Action line VI - Provision of security of information systems
  4969.  
  4970. Issues
  4971.  
  4972. Depending on the exact nature of the security features of information
  4973. systems, the required functions will need to be incorporated at
  4974. different parts of the information system including
  4975. terminals/computers, services, network management to cryptographic
  4976. devices, smart cards, public and private keys, etc. Some of these can
  4977. be expected to be embedded in the hardware or software provided by
  4978. vendors, while others may be part of distributed systems (e.g. network
  4979. management), in the possession of the individual user (e.g. smart
  4980. cards) or provided from a specialised organization (e. g.
  4981. public/private keys).
  4982.  
  4983. Most of the security products and services can be expected to be
  4984. provided by vendors, service providers or operators. For specific
  4985. functions, e.g. the provision of public/private keys, auditing
  4986. authorization, there may be the need to identify and mandate
  4987. appropriate organizations.
  4988.  
  4989. The same applies for certification, evaluation and verification of
  4990. quality of service which are functions which need to be addressed by
  4991. organizations independent of the interests of vendors, service
  4992. providers or operators. These organizations could be private,
  4993. governmental or licensed by government to perform delegated functions.
  4994.  
  4995. Objective
  4996.  
  4997. In order to facilitate a harmonious development of the provision of
  4998. security of information systems in the Community for the protection of
  4999. the public and of business interests, it will be necessary to develop a
  5000. consistent approach as to its provision of security. Where independent
  5001. organizations will have to be mandated, their functions and conditions
  5002. will need to be defined and agreed and, where required, embedded into
  5003. the regulatory framework. The objective would be to come to a clearly
  5004. defined and agreed sharing of responsibilities between the different
  5005. actors on a Community level as a prerequisite for mutual recognition.
  5006.  
  5007. Status and trends
  5008.  
  5009. At present, the provision of security of information systems is well
  5010. organized only for specific areas and limited to addressing their
  5011. specific needs. The organization on a European level is mostly
  5012. informal, and mutual recognition of verification and certification is
  5013. not yet established outside closed groups. With the growing importance
  5014. of the security of information systems, the need for defining a
  5015. consistent approach to the provision of security for information
  5016. systems in Europe and internationally is becoming urgent.
  5017.  
  5018. Requirements, options and priorities
  5019.  
  5020. Because of the number of different actors concerned and the close
  5021. relations to regulatory and legislative questions, it is particularly
  5022. important to pre-agree on the principles which should govern the
  5023. provision of the security of information systems.
  5024.  
  5025. In developing a consistent approach to this question, one will need to
  5026. address the aspects of identification and specification of functions
  5027. requiring, by their very nature, the availability of some independent
  5028. organizations (or interworking organizations). This could include
  5029. functions such as the administration of a public/private key system.
  5030.  
  5031. In addition, it is required to identify and specify, at an early stage,
  5032. the functions which in the public interest need to be entrusted to
  5033. independent organizations (or interworking organizations). This could,
  5034. for example, include auditing, quality assurance, verification,
  5035. certification and similar functions.
  5036.  
  5037.  
  5038.  
  5039.     OJ No L 123, 8.5.1992, p.19
  5040.  
  5041.     SOG-IS Opinion of 17.11.92 on objectives, scope and approach
  5042.  
  5043.     Information Security is concerned with the protection of
  5044.     information stored, processed or transmitted in electronic
  5045.     form, against deliberate or accidental threats.
  5046.  
  5047.     Information is acquired, communicated, processed and stored by
  5048.     Information Services.  Electronic Information services need a
  5049.     secure telecommunication infrastructure, secure terminals
  5050.     (including processors and data bases) as well as secure usage.
  5051.     The management of the service provision itself must also and
  5052.     foremost be secure.  Therefore the approach to information
  5053.     security starts form an analysis of the needs of an individual
  5054.     or organisation for Information Services.  92/242/EEC
  5055.  
  5056.     This danger has already been identified and OECD Member
  5057.     Countries have, in the context of Protection of Privacy and
  5058.     Transborder Data Flow of Personal Data, recognised the risk of
  5059.     new technical barriers forming.  They have therefore agreed to
  5060.     endeavour to remove and to avoid to create in the name of
  5061.     privacy protection, unjustified obstacles to transborder flows
  5062.     of personal data, co-operate in the implementation of the
  5063.     Guidelines and agree as soon as possible on specific procedures
  5064.     of consultation and co-operation for the application of these
  5065.     Guidelines.
  5066.  
  5067.