Docstoc

UNECE security enforcement

Document Sample
UNECE security enforcement Powered By Docstoc
					                                         RESTRICTED
                               CEFACT/ECAWG/97N0015
                                       4 December 1997




   Electronic Commerce Ad hoc Working Group (ECAWG)

  Report on GII Security for JTC1 and the SWG-GII
         9th July 1997, BSI, Bonn, Germany




SOURCE:   ISO/IEC JTC 1
STATUS:   for review
ACTION:
page 2


                                 ISO/IEC JTC 1/SWG-GII N 156
                            ISO/IEC JTC 1/SC 27         N1762
                            Information Technology -    WG1/N814
                            Security Techniques
                                                   July 11, 1997

DOC. TYPE:    Report

TITLE:         Report on GII Security for JTC1
               and the SWG-GII
               9th July 1997, BSI, Bonn, Germany

SOURCE:        SC27/WG1 Ad Hoc Group GII Security
               Co-ordinators (Ted Humphreys and
               Richard Brackney)

SUBMISSION:    1997-07-09

PROJECT:

DISTRIBUTION: WG1 Members
              W. Fumy, SC 27 Chairman
              SC27 Secretariat
              M. De Soete, T. Humphreys, S. Knapskog, WG-
              Convenors

STATUS:

ACTION:

DUE DATE:

MEDIUM:        Paper and email
                                                                                 page 3


        ISO/IEC JTC1/SC27/WG1 Report on GII Security


                            Executive Summary

In December 1996 JTC1 initiated a 60-day ballot on a set of SWG-GII
Recommendations. One of these recommendations (PDR3.61) related to the
topic of security and the GII. The summary of voting on this ballot is
contained in document JTC1/N46242.

Following on from this ballot the SWG-GII were asked to respond to the ballot
comments. This has been carried out and their report is contained in document
SWG-GII/N1292.

In response to the initial recommendation PDR3.6, SC27 took an initial step at
its meetings in April this year (see SC27/N17092 WG1 Resolutions 11 and 12)
by setting up a study period to consider PDR3.6. To start the process
SC27/WG1 had a meeting on the 9th July to draft this current report
(WG1/N814) on GII security. This report will be input into the next SWG-GII
meeting in July and then sent to JTC1 for approval at their meeting in
September.

This report introduces some of the issues regarding GII security, it suggests
some activities and areas of work to be covered, and it lists various activities
that are taking place around the world on GII and security.

In conclusion, the scope and terms of reference for an Ad Hoc Group on GII
Security is as follows.

Scope of Work

The scope of the work of the Ad Hoc Group on GII Security is standardisation
aspects of GII Security. This work should be carried out within JTC1 and


1
  PDR3.6 Ad Hoc on GII Security In view of the critical importance of interoperable
security to the GII, the leadership role of SC27 in security, and the pervasive impact of
security requirements across all applications of IT, JTC1 establishes an Ad Hoc on GII
security, led preferably by a representative from JTC1/SC27, with terms of reference to
review the business requirements to determine if there are areas where, and how, JTC1
should be more actively involved to provide a solution addressing the security related
market-requirements of GII and Electronic Commerce, and to report back by the
Ottawa JTC1 Plenary. The Ad Hoc Group should be open to JTC1 NBLOs and SCs,
ISO and IEC TCs, and fora and consortia active in this field.

2
 JTC1/N3175      Contribution from the US NB on National Planning for the GII
JTC1/N4461       Report to JTC1 on SWG-GII
JTC1/N4464       First Report for JTC1 on GII Standardisation
JTC1/N4502       SWG-GII Recommendations for JTC1 Approval.
JTC1/N4624       Summary of Voting on Document JTC1/N4502 ‘SWG-
                GII Recommendations for JTC1 Approval’
JTC1/SWG-GII/N129 Draft Ballot resolution of responses in JTC1/N4624
JTC1/SC27/N1709 WG1 Resolutions, April 1997


SWG-GII 156 (copy of ISO/IEC JTC /SC27 N1762)
page 4

through appropriate liasion and collaborative channels with other ISO, IEC,
and ITU-T standardisation groups, and fora and consortium activie in this
field.

Terms of Reference

The terms of reference for the Ad Hoc Group on GII Security are:

   To be a focal point for GII Security advise and make recommendations to
    JTC1 and SWG-GII on work to be done;

   To identify and understand the business requirements for GII Security (as
    suggested in PDR3.6), and translate these into a set of requirements for
    standardisation, specifications and supporting guidelines;

   To review existing work being carried out e.g. within the ANSI IISP,
    through the European ISPO and the EPIC activities, the APII activities, G7
    activities and current ISO/IEC/ITU-T work;

   To recommend work to be done, based on the above requirements, within
    the most appropriate committee with the resources to carry out the work;

   To recommend appropriate co-operation and collaboration between with
    groups, both internal and external to JTC1, to produce the necessary
    standards and specifications.

Recommendation to JTC 1


JTC1 approves the establishment of an Ad Hoc Group on GII Security
with Scope and Terms of Reference above.

The membership of this Group should be open to JTC1 MBLOs and SCs,
ISO, IEC and ITU-T TCs amd SGs, and fora and consortia active in this
field.

The Group should be lead by SC27/WG1 with the acting co-ordinators as
defined.
                                                                                page 5


Prologue to GII Security

The national information infrastructures3 (e.g. NII, EII, APII) should integrate
together at the global level to form the Global Information Infrastructure (GII).

Consequently, for most nation states, it is very difficult to separate the
national infrastructure from the GII. To some the two are viewed as two
different user domains within major portions of the same infrastructure. To
others, the GII is a collection of various national infrastructures and the
distinction between the two is not important nor relevant.

The GII promises to revolutionize electronic commerce, re-invigorate
government, and provide new and open access to the information society.
Consequently security4 for GII is of critical importance to individuals, business
and governments: both for privacy protection and security and reliability.

The GII security problem is inherently transnational because activities, e.g. in
cyberspace, move beyond the control of any individual national body. As a
result, security solutions to be effective (i.e. interoperable, manageable,
providing the appropriate level of security) must also be transnational. One
method of achieving transnational solutions for those security solutions is
through the international security standards process. However, this standards
process should only be initiated for those solutions which are developed and
demonstrated. Standards should not be undertaken for technologies which are
in the research stage.

There are a number of areas of concern regarding the security for the users of
the GII, including:

   securing Electronic Commerce - banking, financial services and
    transactions (EFT), teleshopping and trade;

   protecting communications via telephone, fax and email - business and
    private;

   protecting business information, exchanged and stored, sensitive
    commercial data, intellectual property, customer details, trade secrets;

   the security of services to the Public - public administration and
    government on-line, libraries, healthcare, telemedicine, social services;

   individual use - (i) protection and privacy of personal information e.g.
    healthcare records, personnel files, (ii) security solutions for interactive
    entertainment, telelearning;




3
  (e.g. information systems for administration, public utilities such as electricity and
gas, transportation, telecommunications, banking/financial, defence)
4
   According to the document "Global Information Infrastructure: Agenda for
Cooperation” offered by the U.S. Government there are two major topics to encourage
the use of a global infrastructure; both are addressed under the title "information
policy and content issues": (i) privacy protection and (ii) security and reliability.


SWG-GII 156 (copy of ISO/IEC JTC /SC27 N1762)
page 6

       the implementation and management of critical information systems (e.g.
        air traffic control, the electricity, gas and water management systems,
        emergency services);

       government use - a need to protect national and international information
        infrastructures (NII/GII) in peacetime, crisis, and war; as well as to ensure
        these infrastructures are available when a nation needs to conduct military
        operations5.

Scope and Objectives of Future Work

The objective of any future work should be to help GII users, system suppliers,
network service providers, information service providers, content providers,
regulators, and public policy makers realise the full potential in the GII.

This work should include:

       identify and understand the business requirements for GII Security (as
        suggested in PDR3.6), and translate these into a set of requirements for
        standardisation, specifications and supporting guidelines;

       review existing work being carried out e.g. within the ANSI IISP, through
        the European ISPO and the EPIC activities, the APII activities, G7
        activities and current ISO/IEC/ITU-T work;

       initiate work to be done, based on the above requirements, within the most
        appropriate committee with the resources to carry out the work;

       where appropriate promote co-operation and collaboration between with
        groups, both internal and external to JTC1, to produce the necessary
        standards and specifications;

       advise and make recommendations to SWG-GII on work to be done.

Programme of Future Activities

In addition to reviewing the IISP needs and other requirements, the following
topics have been identified as some of the initial areas of work that need to be
pursued as potential areas of future study/standardization work:

       Secure Application Architectures and Portability
            electronic commerce and payments
            information and document retrieval
            sector specific applications e.g. healthcare


5
  For example, during a crisis a nation state maybe required to deploy its military
forces to areas throughout the world. In these situations, a nation state may also be
required to rely on allies and coalition partners to carry out its military mission. In
such a multi-national military environment, there is a need to protect portions of the
GII from exploitation by an adversary and to protect the NII’s of the allies and/or
coalition partners.
                                                                       page 7

          secure business-to-business, business-to-government, private user-
           to-public administration/services interoperability

   Methods for Security Administration

   Methods, Techniques and Services for
       anonymity/pseudonymity
       integrity
       authentication, authorisation, delegation and administration
       non-repudiation
       confidentiality
       IPR, copyright
       prevention of theft, tampering and destruction

   Mechanisms for Interoperable Encoding of Security Attributes

   Development of a Glossary of GII Security Terminology that can be used
    to describe an adversary’s cyberspace probes, intrusions, and attacks on
    the GII as well as the defensive measures that could be use to mitigate an
    adversary’s actions.

   Development of standard application programming interfaces (API’s) for
    tools used to detect GII cyberspace probes, intrusions, and attacks.

   Development of guidelines

          taxonomy of security events, incidents and threats: covering those
           of national and regional concern, and those of transnational or
           potential transnational concern;
          for security incident reporting, detection and responding: the
           guidelines could include what data to collect, when, how and why
           it is needed for a safe and appropriate response to a security
           incident;
          use and inter-cooperation of probes, sensors, and monitors across
           national borders to protect regional and national information
           infrastructures;

   Development of a common format/procedure for the incident reporting
    i.e. sharing of generic information relating to breaches in GII security,
    especially those that have an impact on the global business and
    operations.




SWG-GII 156 (copy of ISO/IEC JTC /SC27 N1762)
page 8


Annex A         Standards Needs, Initiatives and Related Projects

This annex contains some of the activities that are currently being considered
or underway. This is not a definitive or final list.

A1       IISP Security Activities

The IISP activity has recognised the following needs for security
standardisation (see http://www.ansi.org/iisp/needlist.html):

Anonymous Features - Need to de-identify information infrastructure (II)
components, e.g., transactions, data, network connections, phone calls, images,
etc.

    IISP Need #101 - Secure Message Format - Standards are needed for the
     secure exchange of information within messages at the application,
     network, and data link levels.

    IISP Need #102 - Cryptographic Functions - Standards are needed for the
     secure exchange of information. This requires the use of cryptography to
     authenticate, encrypt, decrypt, digitally sign, perform key exchange for
     the message or message component.

    IISP Need #103 - Mechanisms for Electronic Cash Transactions - A need
     exists for standards that define mechanisms for anonymous cash
     transactions across the network.

Confidentiality - The need for security standards for operating in an
environment where there is unrestricted, non-destructive outbound transfer
through the security perimeter (i.e., snooping, copying, eavesdropping, etc.,
but not tampering, theft or destruction).

    IISP Need #104 - Negotiating Cryptographic Attributes At Connection
     Establishment     - Standards are needed to specify components of
     communications protocols used to negotiate cryptographic attributes for
     connection establishment.

    IISP Need #105 - Renegotiating Cryptographic Attributes During a
     Connection - Standards are needed to specify components of
     communications protocols used to renegotiate cryptographic attributes
     during a session.

Prevention of Theft, Tampering & Destruction - The need for security
standards for operating in an environment where there is unrestricted, non-
destructive and destructive inbound transfer through the security perimeter
(i.e., tampering, changing, theft, destruction, etc., but not snooping, copying,
or eavesdropping).

    IISP Need #106 - Non-repudiation Mechanisms for Operating Mediation
     of Resource System Access - Standards are needed to specify non
     repudiation mechanisms for operating system access. For purposes of this
     needs statement, non repudiation supports the accountability objective to
     trace all security-relevant events to individual users.
                                                                        page 9



   IISP Need #107 - Non-repudiation Mechanisms for Application Mediation
    of Resource Access - Standards are needed to specify non repudiation
    mechanisms for application access. For purposes of this needs statement,
    non repudiation supports the accountability objective to trace all security-
    relevant events to individual users and provide a profile which cannot be
    refuted

   IISP Need #108 - A Framework for Application Layer Protocols -
    Standards are needed to provide a general framework for application layer
    protocols to transparently and securely traverse an entity boundary such as
    a firewall. This is necessary for collaboration in a network environment.

   IISP Need #109 - Security Aware Entity Naming Systems - There is a need
    for standards that specify security aware entity naming systems in a
    networked environment. An example of such a naming system might be a
    DNS like service with a digital signature mechanism.

   IISP Need #110 - Secure Payment Protocols - A need exists for standards
    that define secure payment protocols.

Quality of Service - Standards are needed to provide common methods for
specify security control and operation in light of varying security
implementations.

   IISP Need #111 - Application Features for Security - A comprehensive set
    of standards are needed to define secure application features. These
    features, such as exception handling and auditing, should be consistently
    implementable across different applications and platforms.

   IISP Need #112 - Secure Application Architectures - Carefully crafted
    standards are needed to govern the design of secure application
    architectures. These standards should be usable as guidelines across a
    variety of application architectures from various industry segments.

   IISP Need #113 - Secure Application Portability - Standards are needed
    that provide application portability across different platforms and still
    maintain all security features.

   IISP Need #114 - Secure Operating System Architectures - Carefully
    crafted standards are needed to govern the design of secure operating
    system architectures. These standards should be usable as guidelines
    across a variety of operating system architectures from various industry
    segments.

   IISP Need #115 - Standard Overall Security Framework - There is a need
    for standards governing the design of an overall security framework. Such
    a framework is independent of platform, application, and operating system
    but should certainly be complimentary of them.

Authentication, Authorization, Delegation, and Administration - Standards
are needed to provide common validation methods and mechanisms for II
components and for the administration of security methods.


SWG-GII 156 (copy of ISO/IEC JTC /SC27 N1762)
page 10



   IISP Need #116 - Methods of Operating System Level Authentication -
    Standards are needed to specify methods of operating system level
    authentication. Authentication for the purposes of    this needs statement
    means verifiying that the user or remote entity is who they say they are
    when attempting to access the resources of the operating system.

   IISP Need #117 - Methods of Application Level Authentication -
    Standards are needed to specify methods of application level
    authentication. Authentication for the purposes of this needs statement
    means verifying that the user or remote entity is who they say they are
    when attempting to access the application.

   IISP Need #118 - Methods of Operating System Level Authorization -
    Standards are needed to specify methods of operating system level
    authorization. Authorization for the purposes of this needs statement
    means that the user is authorized to perform a particular operation when
    accessing a particular operating system.

   IISP Need #119 - Methods of Application Level Authorization - Standards
    are needed to specify methods of application level authorization.
    Authorization for the purposes of this needs statement means that the user
    is authorized to perform a particular operation when accessing a particular
    application.

   IISP Need #120 - Delegation of Security Attributes - Standards are needed
    to define the delegation and retraction of delegation of security attributes
    and functions to a different entity.

Security Classification - Standards are needed for common security
classifications. Security classifications might parallel organizational structure,
might parallel other structures, or might be ad hoc.

   IISP Need #121 - Security Levels for Processing Data - Standards are
    needed for methods of supporting multiple hierarchical security levels for
    the processing of data.

   IISP Need #122 - Security Compartmentalization for Processing Data -
    Standards are needed for methods of supporting a nonhierarchical
    compartmentalization security classification for the processing of data.

   IISP Need #123 - Security Levels for Data - Standards are needed for
    methods of supporting multiple hierarchical security levels for the
    classification of data.

   IISP Need #124 - Methods to Support Non-hierarchical
    Compartmentalization Security Classification for Data - Standards are
    needed for methods of supporting a non-hierarchical compartmentalization
    security classification for data. An example of such data is secure
    electronic mail where data needs to be protected independent of the on-
    line connection security level.
                                                                         page 11

Interoperable Encoding of Security Attributes - Standards are needed for
common mechanisms to translate security attributes to/from interoperable
encodings.

    IISP Need #125 - Conversion of Security Attributes to and from Text -
     Standards are needed to specify the conversion of security attributes into
     and out of a textual representation. This is required for maximum
     portability of security attributes.

    IISP Need #126 - User Interface Security Labeling - Standards are needed
     that define user interface security labeling which provides a human
     readable representation of the internal security labels.

Secure Methods for Security Administration - Standards are needed for
common methods for securing transactions related to security administration.
These methods are necessary to prevent damage to the use, auditing, and
enforcement of security mechanisms.

    IISP Need #127 - Standardization of Levels of Assurance for Application
     Integrity - There is a need for a standard or set of standards that define
     levels of assurance for application integrity. A level of assurance may be
     described by one or more security features such as encryption, intrusion
     detection, access control, or other factor.

Evaluation Methods and Criteria - Standards are needed to evaluate the
suitability of security systems

    IISP Need #128 - Standardization of Evaluation Criteria for Operating
     System Security Services - There is a need for a standard set of criteria for
     evaluating operating systems security services.

    IISP Need #129 - Standardization of Evaluation Criteria for Application
     Security Services - There is a need for a standard set of criteria for
     evaluating application security services.

    IISP Need #130 - Evaluation Criteria for Security Enforcement - Standards
     are needed to specify evaluation criteria for security enforcement features,
     assurances, and architectures.

    IISP Need #131 - Standard Evaluation Criteria for Network Security
     Services - A need exists to standardize evaluation criteria for network
     security services. For purposes of this need statement, network security
     services include transport security.

    IISP Need #132 - Evaluation Criteria for Security Architectures and
     Frameworks - Standards are needed that define evaluation criteria for
     security architectures and frameworks independent of actual
     implementations.

A2       G7 Pilot Projects




SWG-GII 156 (copy of ISO/IEC JTC /SC27 N1762)
page 12

The      following     are    some    of    the    G7      projects    (see
http://www.ispo.cec.be/gip/gip.html). Some of these are related to security
directly and some indirectly.

    G7 #2 - Global Interoperability of Broadband Networks

    G7 #4 - Electronic Libraries : To constitute from existing digitisation
     programs a large distributed virtual collection of the knowledge of
     mankind, available to the public via networks. This includes a clear
     perspective towards the establishment of the global electronic library
     network which interconnects local electronic libraries.

    G7 #6 - Environment and Natural Resources Management

    G7 #7 - Global Emergency Management Information : To encourage the
     development of a global management information network to enhance the
     management of emergency response situations,                risks and
     knowledge.

    G7 #8 - Global Healthcare Applications : To demonstrate the potential of
     telematics technologies in the field of telemedicine in the fight against
     major health scourges; to promote joint approaches to issues such as the
     use of data cards, standards and other enabling mechanisms.
    G7 #9 - Government On-Line : To exchange experience and best practice
     on the use of online information technology by administrations on the
     establishment of procedures for conducting electronic administrative
     business between governments, companies and citizens.

    G7 #10 - Global Martketplace for SMEs : To contribute to the
     development of an environment for open and non-discriminatory exchange
     of information and to demonstrate the interoperability of electronic and
     information co-operation and trading services on a global scale for the
     benefit of SME's.

    G7 #11 - Maritime Information Systems

A3       European Electronic Commerce Projects

The following are some of the projects currently being undertaken in the
Electronic    Commerce        of      the    IT      Programme      (see
http://www.ISPO/electcom/security.html).

    E2S End-to-End Security over the Internet (SW) 20563. The goal of
     the project is to contribute to the growth of Electronic Commerce on the
     Internet by developing, testing and installing end-to-end security
     mechanisms for commercial transactions using the Internet. The plan is to
     deliver a professional infrastructure that is attractive to businesses and
     consumers, enabling the economic growth promised by the "information
     society".

    WIRE Web Information Repository for the Enterprise (SW) 22005.
     The overall goal of the WIRE project is to make it possible for
     organisations to deploy Secure Enterprise Webs. Today, many
                                                                       page 13

     organisations have set up Web servers for non strategic IT applications to
     deliver public information to the market at a low cost compared to
     advertisement in other media.

    FACTMERCHANT (TBP) 24103. The pilot will demonstrate the
     integration of secure billing, e-mail and EDI on a platform, which provides
     comprehensive access to business information. This will include news and
     rates, world-wide market and broker research, and financial and credit
     analysis. The pilot will be run over Internet for access for both SMEs and
     larger organisations. The pilot will use knowledge-based systems
     technology for search, public-key cryptography and digital signatures for
     confidentiality, authentication, integration and non-repudiation.

    ICX (TBP) 22803. A business driven European User Group, to be known
     as the International Commerce eXchange (ICX), is proposed. ICX will be
     a European Forum for the discussion, identification and subsequent
     resolution of security issues in the electronic commerce arena.

    WEBCORE A World-Wide Web Coordinating Organisation (SW)
     9801. The W3C is an industry consortium which seeks to promote
     standards for the evolution of the Web and interoperability between
     WWW products by producing specifications and reference software.
     Although W3C is funded by industrial members, it is vendor-neutral, and
     its products are freely available to all. In early 1996, W3C identified
     digital signature to be one of the major market drivers for Web security
     and launched the so called Digital Signature Initiative.

A4       PROJECTS IN ‘STANDARDISATION AND THE
         INFORMATION SOCIETY’

The following are some of the projects currently being undertaken within the
European Information Society inititaive (see http://www.ispo.cec.be/).

    C-SET (Interoperable Chip-secured Electronic Transaction) As the
     need for Electronic Commerce emerges, Visa and MasterCard have
     developed the SET (Secure Electronic Transaction) protocol to secure
     payment transactions on open networks by software. Worldwide card
     schemes will mostly apply to SET payment regulations according to which
     the merchant is not paid if the cardholder repudiates the transaction. Some
     regional card schemes, such as CB and Banksys, enjoy a high level of
     security in domestic face-to-face payments thanks to the use of the micro-
     circuit card. They wish to enhance SET so as to support the use of
     microcircuit cards, thus providing the additional security needed to fully
     guarantee payments over open networks. The enhanced C-SET protocol
     will be specified so that : (i) it can easily be implemented by every
     regional card scheme through the use of the microcircuit card already in
     use for face-to-face payments and (ii) all C-SET schemes can interoperate
     with one another as well as with SET schemes, thanks to translators
     located at the interfaces between each C-SET scheme and the world-wide
     card schemes. C-SET specifications will be forwarded to the main formal
     standardisation bodies.




SWG-GII 156 (copy of ISO/IEC JTC /SC27 N1762)
page 14

    ICE -TEL The aim of the ICE-TEL project is to offer solutions to the
     problem of security on the Internet as used by industrial and academic
     research. This will be achieved by support for the usage of secured
     applications where users need to be certified, by providing a large scale
     public key certification infrastructure in a number of European countries
     and by providing all the necessary technology components which allow
     the deployment.

    SEMPER This deals the development of a secure electronic marketplace.
     The work includes a detailed description of legal, commercial, social, and
     technical requirements and options for an electronic marketplace, a
     coherent model and a generic, open architecture of an electronic
     marketplace, independent of specific hardware, software, and network
     architectures and specifications, designs, and prototype implementations
     and evaluations for basic and advanced services enabling electronic
     commerce. The development is driven by market requirements and the
     state of the art in security and online information services. For
     authentication services, state-of-the-art digital signatures are used.
     Requirements for multi-party security and the protection of the users'
     privacy will receive prime attention.

    MEDSEC - Healthcare Security and Privacy in the Information       Society

    SEMRIC - Secure Medical Record Information Communication

A5       ETSI EPIISG/EPIC Projects

The following are some of the projects currently being undertaken by ETSI-
EPIC (see http://www.ict.etsi.fr/). Some of these are related to security
directly and some indirectly.

    EPIC #1 - Access Networks to Residential Environment
    EPIC #3 - Inter-Networking
    EPIC #8 - Technical Framework for Electronic Commerce
    EPIC #12 - Security
    EPIC #18 - Electronic Information and Document Retrieval
    EPIC #24 - Medical Informatics
    EPIC #27 - Electronic Purse

A6       Trans-European         Networks        in     Telecommunications
         Programme

The following are some of the projects currently being undertaken by the TEN
initiative (see http://www.ispo.cec.be). Some of these are related to security
directly and some indirectly.

    TEN Need #4 -       Electronic Commerce for SMEs
    TEN Need #6 -       Healthcare
    TEN Need #7 -       Telework Networks
    TEN Need #11 -      Citizen’s Access to Services
    TEN Need #12 -      Electronic Tendering
                                                                  page 15

    TEN Need #15 -    Digital Signatures for Open Service Provision and
                       Mobility of Use

A7      ITU-T GII Standardisation Projects

The following are some of the projects currently being undertaken by ITU-T.
Some of these are related to security directly and some indirectly.

    ITU Need #4 -     End-to-end Interoperability
    ITU Need #7 -     Network Interworking for the GII
    ITU Need #8 -     Internet Access and Interworking
    ITU Need #9 -     Intelligent Mobility for the GII
    ITU Need #12 -    Quality of Service and Network Performance
    ITU Need #16 -    Technical Framework for Electronic Commerce
    ITU Need #19 -    Security (end-to-end)
    ITU Need #23 -    Medical Informatics
    ITU Need #27 -    Electronic Purse




SWG-GII 156 (copy of ISO/IEC JTC /SC27 N1762)
page 16


Annex B         Standardisation and Related Activities

At the ISO/IEC JTC1 level there are many Sub-Committees (SC’s) that
security relevant standardisation work as part of their work programmes. The
following is a list, which is not definitive or final, of SC’s known to be
involved in, or interfacing with, security work:

SWG GII
SC1  Vocabulary
SC6  Telecommunications       and    Information   Exchange Between
     Systems
SC7  Software Engineering
SC17 Identification Cards and Related Devices
SC18 Document Processing and Related Communications
SC21 Open Systems Interconnection, Data Management and Open
     Distributed Processing
SC22 Programming Languages, Environments and System Software
     Interfaces
SC25 Interconnection of Information Technology Equipment
SC27 IT Security Techniques
SC28 Office Equipment
SC30 Open EDI

In addition, there are a number of ISO and IEC groups that are also involved
with security work including:

ISO/TC68        Banking Systems
IEC/TC65        Safety Related Control Systems

Also at the international level there is the important relationship with ITU-T
and ITU-R which collaborates closely with a number of the JTC1 groups on a
number of standards activities and in some cases jointly publish standards.

Other groups involved in security related standards activities include:

ATM Forum
CEN            European Committee for Standardisation
DAVIC          Digital Audio-Visual Council (http://www.davic.org/)
ECMA           European Computer Manufactures Association
ETSI           European Telecommunications Standards Institute
EURESCOM European Institute for Research and Strategic Studies in
      Telecommunications
IEEE           Institute of Electrical and Electronic Engineers
IETF           Internet Engineering Task Force
IFIP           International Federation of Information Processing
NIST           National Institute of Standards and Technology
      (http://nii.nist.gov/pubs/app.html)
Open Group     (http://www.xopen.org/)
OMG            Object Management Group (http://www.omg.org/)

Finally there is also various national standards bodies that are active in
security standards.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:10/5/2012
language:Latin
pages:16