ITU-T activities in the field of telecommunications security - PowerPoint PPT Presentation

Loading...

PPT – ITU-T activities in the field of telecommunications security PowerPoint presentation | free to download - id: 8053cd-OTVlN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

ITU-T activities in the field of telecommunications security

Description:

ITU-T activities in the field of telecommunications security Sami Trabulsi ITU/TSB sami.trabulsi_at_itu.int Introduction ICT security is high in the agenda of many ... – PowerPoint PPT presentation

Number of Views:88
Avg rating:3.0/5.0
Slides: 112
Provided by: Franci574
Learn more at: http://ituarabic.org
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: ITU-T activities in the field of telecommunications security


1
ITU-T activities in the field of
telecommunications security
  • Sami Trabulsi
  • ITU/TSB
  • sami.trabulsi_at_itu.int

2
Introduction
  • ICT security is high in the agenda of many
    national, regional or international organizations
  • Computing and networking are an important part of
    daily life
  • Increase in widely reported security incidents
  • Need for effective security measures to protect
    computer and telecom systems of governments,
    industry, commerce, critical infrastructure and
    consumers

3
Security services/dimensions
4
Security services/dimensions
5
Background
  • A key concern for ICT security relates to systems
    vulnerabilities
  • Statistics on computer-security vulnerabilities

Carnegie Mellon Uni. CERT CC
Symantec Corp.
This computer-security company cataloges 11,000
vulnerabilities in 20,000 technologies, affecting
2,000 vendors in the last decade
6
Background
  • An increasing number of countries now have data
    protection legislation requiring compliance with
    demonstrated data protection standards
  • Some SDOs have security in their work programme
    as a continuous item (e.g., ITU, ISO, IETF)
  • Or, other SDOs may be established to respond to a
    specific issue (e.g.,
  • e-business OASIS
  • SPAM MAAWG)

7
High Level Security Drivers
  • ITU Plenipotentiary Conference (PP-02)
  • Intensify efforts on security
  • World Telecommunications Standardization Assembly
    (WTSA-04)
  • Security robustness of protocols
  • Countering spam
  • World Summit on the Information Society (WSIS-05)
  • Cyber security

8
ITU Plenipotentiary Conference 2002Resolution
PLEN/2 - Strengthening the role of ITU in
information and communication network security
  • resolves
  • to review ITU's current activities in information
    and communication network security
  • to intensify work within existing ITU study
    groups in order to
  • a) reach a common understanding on the
    importance of information and communication
    network security by studying standards on
    technologies, products and services with a view
    to developing recommendations, as appropriate
  • b) seek ways to enhance exchange of technical
    information in the field of information and
    communication network security, and promote
    cooperation among appropriate entities
  • c) report on the result of these studies
    annually to the ITU Council.

9
ITU-T World Telecommunications Standardization
Assembly (WTSA)
  • Resolution 50, Cyberscecurity- Evaluate existing
    and evolving new Recommendations with respect to
    their robustness of design and potential for
    exploitation by malicious parties- Raise
    awareness of the need to defend against the
    threat of cyber attack
  • Resolution 51, Combating spam- Report on
    international initiatives for countering spam-
    Member States to take steps within their national
    legal frameworks to ensure measures are taken to
    combat spam
  • Resolution 52, Countering spam by technical
    means- Study Groups, in cooperation with other
    relevant groups, to develop as a matter of
    urgency technical Recommendations on countering
    spam

10
ITU-T Study Groups
  • ITU-T work is divided up between Study Groups
    (SGs).
  • SG 2 Operational aspects of service provision,
    networks and performance
  • SG 4 Telecommunication management
  • SG 5 Protection against electromagnetic
    environment effects
  • SG 6 Outside Plant and related indoor
    installations
  • SG 9 Integrated broadband cable networks and
    television and sound transmission
  • SG 11 Signaling requirements and protocols
  • SG 12 Performance and quality of service
  • SG 13 Next Generation Networks
  • SG 15 Optical and other transport networks
  • SG 16 Multimedia services, systems and terminals
  • SG 17 Security, languages and telecommunication
    software
  • SG 19 Mobile Telecommunications Networks
  • SG17 is the Lead Study Group on security.

11
Overview of ITU-T Security StandardizationCollabo
ration is key factor
12
Study Group 17 Security, languages and
telecommunication software
  • SG 17 is the Lead Study Group on
    telecommunication security - It is responsible
    for coordination of security across all Study
    Groups.
  • Subdivided into three Working Parties (WPs)
  • WP1 - Open systems technologies
  • WP2 - Telecommunications security
  • WP3 - Languages and telecommunications software
  • Most (but not all) security Questions are in WP2
  • Summaries of all draft Recommendations under
    development in SG 17 are available on the SG 17
    web page at www.itu.int/itu-t/studygroups/com17

13
Current SG 17 security-related Questions
  • Working Party 1
  • 1/17 End-to-end Multicast Communications with
    QoS Managing Facility
  • 2/17 Directory services, Directory systems, and
    public- key/attribute certificates
  • 3/17 Open Systems Interconnection (OSI)
  • 16/17 International Domain Names (IDN)
  • Working Party 2
  • 4/17 Communications Systems Security Project
  • 5/17 Security Architecture and Framework
  • 6/17 Cyber Security
  • 7/17 Security Management
  • 8/17 Telebiometrics
  • 9/17 Secure Communication services
  • 17/17   Countering spam by technical means

14
WP 2/17 Security Questions (2005-2008)
Q8/17
Telecom Systems Users
Telebiometrics Multimodal Model Fwk System
Mechanism Protection Procedure X.1081
TelecomSystems
Q5/17
Secure Communication Services Mobile Secure
Communications Home Network Security
Security Web Services X.1121, X.1122
Q7/17
SecurityManagement ISM Guideline for
Telecom Incident Management Risk
Assessment Methodology etc X.1051
SecurityArchitecture Framework Architecture,
Model, Concepts, Frameworks,etc X.800
seriesX.805
Q9/17
Cyber SecurityOverview of Cyber-securityVulner
ability Information Sharing Incident Handling
Operations
Q6/17
New
Countering SPAM Technical anti-spam measures
Q17/17
New
Q4/17
New
Communications System Security
Vision, Coordination, Roadmap, Compendia
15
ITU-T SG 17 Question 4Communications Systems
Security Project
  • Security Workshop
  • ICT Security Roadmap
  • Focus Group on Security Baseline For Network
    Operators

16
New Horizons for Security Standardization Workshop
  • Workshop held in Geneva 3-4 October 2005
  • Hosted by ITU-T SG17 as part of security
    coordination responsibility
  • ISO/IEC JTC1 played an important role in planning
    the program and in providing speakers/panelists.
  • Speakers, panelists, chairs from
  • ITU-T
  • ISO/IEC
  • IETF
  • Consortia OASIS, 3GPP
  • Regional SDOs ATIS, ETSI, RAIS

17
Workshop Objectives
  • Provide an overview of key international security
    standardization activities
  • Seek to find out from stakeholders (e.g., network
    operators, system developers, manufacturers and
    end-users) their primary security concerns and
    issues (including possible issues of adoption or
    implementation of standards)
  • Try to determine which issues are amenable to a
    standards-based solution and how the SDOs can
    most effectively play a role in helping address
    these issues
  • Identify which SDOs are already working on these
    issues or are best equipped to do so and
  • Consider how SDOs can collaborate to improve the
    timeliness and effectiveness of security
    standards and avoid duplication of effort.

18
Workshop Results
  • Excellent discussions, feedback and suggestions
  • Documented in detail in the Workshop report
  • Results are reported under following topics
  • What are the crucial problems in ICT security
    standardization?
  • Meta issues and need for a global framework
  • Standards Requirements and Priorities
  • Liaison and information sharing
  • User issues
  • Technology and threat issues
  • Focus for future standardization work
  • Process issues
  • Follow-on issues
  • The report is available on-line at
  • www.itu.int/ITU-T/worksem/security/200510/index.ht
    ml

19
ICT Security Standards Roadmap(an SG 17
work-in-progress)
  • Publicly available under Special Projects and
    Issues at
  • www.itu.int/ITU-T/studygroups/com17/index
  • Part 1 contains information about organizations
    working on ICT security standards
  • Part 2 is database of existing security standards
  • Part 3 will be a list of standards in development
  • Part 4 will identify future needs and proposed
    new standards

20
Roadmap access
  • Part 2 includes ITU-T, ISO/IEC JTC1 and IETF
    standards. It will be expanded to include other
    standards (e.g. regional and consortia
    specifications).
  • It will also be converted to a Database format to
    allow searching and to allow organizations to
    manage their own data
  • We invite you to use the Roadmap, provide
    feedback and help us develop it to meet your
    needs

21
Other Q.4/17 projects
  • Security in Telecommunications and Information
    Technology an overview of existing ITU-T
    Recommendations for secure telecommunications
    (Security Manual, v3)
  • www.itu.int/ITU-T/publications/index.html
  • Security compendium
  • catalogue of approved ITU-T Recommendations
    related to telecommunication security
  • extract of ITU-T approved security definitions
  • listing of ITU-T security related Questions
  • www.itu.int/ITU-T/studygroups/com17/tel-security.h
    tml
  • We are in the process of establishing a Security
    Experts Network (SEN) to maintain on-going
    dialogue on key issues of security
    standardization.

22
Focus Group Security Baseline for Network
Operators
  • Established October 2005 by SG 17
  • Objectives
  • Define a security baseline against which network
    operators can assess their network and
    information security posture in terms of what
    security standards are available, which of these
    standards should be used to meet particular
    requirements, when they should be used, and how
    they should be applied
  • Describe a network operators readiness and
    ability to collaborate with other entities
    (operators, users and law enforcement
    authorities) to counteract information security
    threats
  • Provide meaningful criteria that can be used by
    network operators against which other network
    operators can be assessed, if required.
  • Next Step
  • Survey network operators by means of a
    questionnaire
  • 2 meetings in preparation for 2006

23
ITU-T SG 17 Question 5Security Architecture and
Framework
  • Brief description of Q.5
  • Milestones
  • Draft Recommendations under development

24
Brief description of Q.5/17
  • Motivation
  • The telecommunications and information technology
    industries are seeking cost-effective
    comprehensive security solutions that could be
    applied to various types of networks, services
    and applications. To achieve such solutions in
    multi-vendor environment, network security should
    be designed around the standard security
    architectures and standard security technologies.
  • Major tasks
  • Development of a comprehensive set of
    Recommendations for providing standard security
    solutions for telecommunications in collaboration
    with other Standards Development Organizations
    and ITU-T Study Groups.
  • Maintenance and enhancements of Recommendations
    in the X.800 series
  • X.800, X.802, X.803, X.805, X.810, X.811,
    X.812, X.813, X.814, X.815, X.816, X.830, X.831,
    X.832, X.833, X.834, X.835, X.841, X.842 and
    X.843

25
Q.5/17 Milestones
  • ITU-T Recommendation X.805, Security Architecture
    for Systems Providing End-to-end Communications,
    was published in 2003.
  • ISO Standard 18028-2, Network security
    architecture, was developed in collaboration
    between ITU-T Q.5/17 and ISO/IEC JTC 1 SC 27 WG
    1. The Standard is technically aligned with
    X.805. It was published in 2006.

26
ITU-T Recommendation X.805
X.805 defines a network security architecture for
providing end-to-end network security. The
architecture can be applied to various kinds of
networks where the end-to-end security is a
concern and independently of the networks
underlying technology.
27
ITU-T X.805 Approach
X.805
28
ITU-T X.805
  • Provides A Holistic Approach
  • Comprehensive, End-to-End Network View of
    Security
  • Applies to Any Network Technology
  • Wireless, Wireline, Optical Networks
  • Voice, Data, Video, Converged Networks
  • Applies to Any Scope of Network Function
  • Service Provider Networks
  • Enterprise Networks
  • Government Networks
  • Management/Operations, Administrative Networks
  • Data Center Networks
  • Can Map to Existing Standards
  • Completes the Missing Piece of the Security
    Puzzle of what to do next

X.805
29
E.409 Incident organization and security
incident handling
  • analyze, structure and suggest a method for
    establishing an incident management organization
    within a telecommunications organization, where
    the flow and structure of incident handling is
    dealt with.
  • flow and structure of incident handling helps in
    classifying a problem as
  • event
  • incident
  • security incident
  • crisis
  • incident flow handling also covers the critical
    first decisions to be made

30
Pyramid of events in E.409
  • Are considered as Information and Communications
    Networks (ICN) Security Incident any real or
    suspected adverse event in relation to the
    security of ICN. This includes
  • intrusion into ICN computer systems via the
    network
  • occurrence of computer viruses
  • probes for vulnerabilities via the network into
    a range of computer systems
  • PABX call leak-through and
  • any other undesired events arising from
    unauthorized internal or external actions,
    including denial of service attacks, disasters
    and other emergency situations, etc.

31
E.409 suggested reactions
  • telecommunication organizations should create
    computer security incident response teams
    (CSIRT), as the first step, declare their use of
    taxonomy in order to avoid misunderstandings.
  • Collaboration is much easier when using the same
    "language".
  • organizations should use the term Incident and
    ICN Security Incident (any undesired,
    unauthorized event
  • computer intrusion
  • denial of service attack
  • virus attack),
  • define their own subdivisions with regard to
    severity, depending on motivation, experience and
    available knowledgeable resources. When an
    effective virus fighting team has been created,
    viruses may not be considered as ICN security
    incidents but rather as incidents

32
Q.5/17 Draft Recommendations 1/2
  • Applications and further development of major
    concepts of ITU-T Recommendation X.805
  • X.805, Division of the security features between
    the network and the users. This Recommendation
    specifies division of security features between
    the networks and users. It provides guidance on
    applying concepts of the X.805 architecture to
    securing service providers, application
    providers networks and the end users equipment.
  • X.805nsa, Network security certification based on
    ITU-T Recommendation X.805. This Recommendation
    describes the methodology, processes and controls
    required for network security certification based
    on ITU-T Recommendation X.805, Security
    Architecture for Systems Providing End-to-End
    Communications.

33
Q.5/17 Draft Recommendations 2/2
  • Standardization in support of Authentication
    Security Dimension (defined in X.805)
  • X.pak, Password-authenticated Key Exchange
    Protocol (PAK). This Recommendation specifies a
    password-based protocol for authentication and
    key exchange, which ensures mutual authentication
    of both parties in the act of establishing a
    symmetric cryptographic key via Diffie-Hellman
    exchange.
  • X.ngn-akm, Framework for authentication and key
    management for link layer security of NGN. This
    Recommendation establishes a framework for
    authentication and key management for securing
    the link layer of NGN. It also provides guidance
    on selection of the EAP methods for NGN.
  • Standardization of network security policies
  • X.spn, Framework for creation, storage,
    distribution, and enforcement of security
    policies for networks. This Recommendation
    establishes security policies that are to drive
    security controls of a system or service. It also
    specifies a framework for creation, storage,
    distribution, and enforcement of policies for
    network security that can be applied to various
    environmental conditions and network devices.

34
ITU-T SG 17 Question 6Cyber Security
  • Definition
  • Motivation
  • Objectives
  • Scope
  • Current area of focus
  • Draft Recommendations under development

35
Cybersecurity working definition(SG17 SG2
liaison)
  • As a working definition within the ITU-T,
    Cybersecurity means the collection of tools,
    policies, guidelines, risk management approaches,
    actions, training, best practices, assurance and
    technologies that may be used to protect
    organization and users assets on the cyber
    environment. Organization and users assets
    include connected computing devices, computing
    users, applications/services, Telecommunications
    systems, multimedia communication, and the
    totality of transmitted and/or stored information
    in the cyber environment.
  • It encompasses the attainment and maintenance of
    the security properties of the organization and
    users assets against relevant security risks in
    the cyber environment. The security properties
    include one or more of the following
  • Availability
  • Integrity, which may include authenticity and
    non-repudiation
  • Confidentiality

36
Q.6/17 Motivation
  • Network connectivity and ubiquitous access is
    central to todays IT systems
  • Wide spread access and loose coupling of
    interconnected IT systems is a primary source of
    widespread vulnerability
  • Threats such as denial of service, theft of
    financial and personal data, network failures and
    disruption of voice and data telecommunications
    are on the rise
  • Network protocols in use today were developed in
    an environment of trust.
  • Most new investments and development is dedicated
    to building new functionality and not on securing
    that functionality
  • An understanding of cybersecurity is needed in
    order to build a foundation of knowledge that
    can aid in securing the networks of tomorrow

37
Q.6/17 Objectives
  • Perform actions in accordance with Lead Study
    Group (LSG) responsibility with the focus on
    cybersecurity
  • Work with Q.1 of SG 2 on a definition of
    Cybersecurity
  • Identify and develop standards required for
    addressing the challenges in cybersecurity,
    within the scope of Q.6/17
  • Provide assistance to other ITU-T Study Groups in
    applying relevant cybersecurity Recommendations
    for specific security solutions. Review
    project-oriented security solutions for
    consistency.
  • Maintain and update existing Recommendations
    within the scope of Q.6/17.
  • Coordinate security activities with other ITU-T
    SGs, ISO/IEC JTC 1 eg. SC6, SC27 and SC37), and
    consortia as appropriate.
  • Provide awareness on new security technologies
    related to cybersecurity

38
Q. 6/17 Scope
  • Definition of Cybersecurity
  • Security of Telecommunications Network
    Infrastructure
  • Security Knowledge and Awareness of Telecom
    Personnel and Users
  • Security Requirements for Design of New
    Communications Protocol and Systems
  • Communications relating to Cybersecurity
  • Security Processes Life-cycle Processes
    relating to Incident and Vulnerability
  • Security of Identity in Telecommunication Network
  • Legal/Policy Considerations

39
Q.6/17 Current area of focus
  • Work with SG 2 on the definition and requirements
    of cybersecurity.
  • Collaborate with Q5,7,9,17/17 and SG 2 in order
    to achieve better understanding of various
    aspects of network security.
  • Collaborate with IETF, OASIS, ISO/IEC JTC1, W3C,
    APEC-TEL and other standardization bodies on
    cybersecurity.
  • Work on framework for secure network operations
    to address how telecommunications network
    providers secure their infrastructure and
    maintain secure operations.
  • Work on Recommendation for standardization of
    vulnerability data definition.
  • Study new cybersecurity issues How should ISPs
    deal with botnets, evaluating the output of
    appropriate bodies when available.
  • Call for contributions for the outstanding
    questions identified in the revised scope.

40
Q.6/17 Draft Recommendations 1/2
  • Overview of Cybersecurity (X.cso)
  • This Recommendation provides a definition for
    Cybersecurity. The Recommendation provides a
    taxonomy of security threats from an operator
    point of view. Cybersecurity vulnerabilities and
    threats are presented and discussed at various
    network layers.
  • Various Cybersecurity technologies that are
    available to remedy the threats include Routers,
    Firewalls, Antivirus protection, Intrusion
    detection systems, Intrusion protection systems,
    Secure computing, Audit and Monitoring. Network
    protection principles such as defence in depth,
    access and identity management with application
    to Cybersecurity are discussed. Risk Management
    strategies and techniques are discussed including
    the value of training and education in protecting
    the network. A discussion of Cybersecurity
    Standards, Cybersecurity implementation issues
    and certification are presented.
  • A vendor-neutral framework for automatic checking
    of the presence of vulnerabilities information
    update (X.vds)
  • This Recommendation provides a framework of
    automatic notification on vulnerability
    information. The key point of the framework is
    that it is a vendor-neutral framework. Once users
    register their software, updates on the
    vulnerabilities and patches of the registered
    software will automatically be made available to
    the users. Upon notification, users can then apply

41
Q.6/17 Draft Recommendations 2/2
  • Guidelines for Internet Service Providers and
    End-users for Addressing the Risk of Spyware and
    Deceptive Software (X.sds)
  • This Recommendation provides guidelines for
    Internet Service Providers (ISP) and end-users
    for addressing the risks of spyware and deceptive
    software. The Recommendation promotes best
    practices around principles of clear notices, and
    users consents and controls for ISP web hosting
    services. The Recommendation also promotes best
    practices to end-users on the Internet to secure
    their computing devices and information against
    the risks of spyware and deceptive software
  • Guidelines on Cybersecurity Vulnerability
    Life-cycle Management(X.cvlm)
  • The Recommendation provides a framework for the
    provision of monitoring, discovering, responding
    and post-analysis of vulnerabilities. Service
    providers can use this Recommendation to
    complement their existing Information Security
    Management System process in the aspect of
    regular vulnerability assessment, vulnerability
    management, incident handling and incident
    management.

42
ITU-T SG 17 Question 7Security Management
  • Tasks
  • Recommendations planned
  • Revised X.1051
  • Approach for revised X.1051

43
Q.7/17 Tasks
  • Information Security Management Guidelines for
    telecommunications (Existing X.1051,
    Information security management system
    Requirements for telecommunications (ISMS-T) )
    Maintain and revise Recommendation X.1051,
    Information Security Management Guidelines for
    telecommunications based on ISO/IEC27002.Jointl
    y develop a guideline of information security
    management with ISO/IEC JTC 1/SC 27.
  • Risk Management MethodologyStudy and develop a
    methodology of risk management for
    telecommunications in line with Recommendation
    X.1051.Produce and consent a new ITU-T
    Recommendation for risk management methodology.
  • Incident ManagementStudy and develop a handling
    and response procedure on security incidents for
    the telecommunications in line with
    Recommendation X.1051.Produce and consent a new
    ITU-T Recommendation for incident management
    methodology and procedures.

44
Recommendations planned in Q.7/17 (Security
Management)
  • X.1050 To be proposed
  • X.1051 In revision process Information Security
    Management Guidelines for Telecommunications
    based on ISO/IEC 27002
  • X.1052 To be proposed
  • X.1053 To be proposed (Implementation Guide for
    Telecoms)
  • X.1054 To be proposed (Measurements and metrics
    for Telecommunications)
  • X.1055 In the first stage of development Risk
    Management Guidelines for Telecommunications
  • X.1056 In the first stage of development
    Security Incident Management Guidelines for
    Telecommunications
  • X.1057 To be proposed (Identity Management for
    Telecoms)

45
Information security management guidelines for
Telecommunications (Revised X.1051)
Revised X.1051
Security policy
Organising information security
Asset management
Human resources security
Physical environmental security
Communications operations management
Access control
Information systems acquisition, development and
maintenance
Information security incident management
Business continuity management
Compliance
46
Q.7/17 Approach to developrevised ITU-T Rec.
X.1051
47
ITU-T SG 17 Question 8Telebiometrics
  • Objectives
  • Study areas on Biometric Processes
  • X.1081 and draft Recommendations under
    development

48
Q.8/17 Objectives
  • 1)To define telebiometric multimodal model
    framework
  • 2)To specify biometric authentication mechanism
    in open network
  • 3)To provide protection procedures and
    countermeasures for telebiometric systems

49
Q.8/17 Study areas on Biometric Processes
50
Q.8/17 Recommendations 1/4
  • X.1081 The telebiometric multimodal model
    framework A framework for the specification of
    security and safety aspects of telebiometrics
  • This Recommendation defines a telebiometric
    multimodal model that can be used as a framework
    for identifying and specifying aspects of
    telebiometrics, and for classifying biometric
    technologies used for identification (security
    aspects).
  • X.physiol Telebiometrics related to human
    physiology
  • This Recommendation gives names and symbols for
    quantities and units concerned with emissions
    from the human body that can be detected by a
    sensor, and with effects on the human body
    produced by the telebiometric devices in his
    environments.

51
Q.8/17 Recommendations 2/4
  • X.tsm-1 General biometric authentication
    protocol and profile on telecommunication system
  • This Recommendation defines communication
    mechanism and protocols of biometric
    authentication for unspecified end-users and
    service providers on open network.
  • X.tsm-2 Profile of telecomunication device for
    Telebiometrics System Mechanism (TSM)
  • This Recommendation defines the requirements,
    security profiles of client terminals for
    biometric authentication over the open network.

52
Q.8/17 Recommendations 3/4
  • X.tai Telebiometrics authentication
    infrastructure
  • This Recommendation specifies a framework to
    implement biometric identity authentication with
    certificate issuance, management, usage and
    revocation.
  • X.bip BioAPI interworking protocol
  • This Recommendation is common text of ITU-T and
    ISO/IEC JTC1 SC37. It specifies the syntax,
    semantics, and encodings of a set of messages
    ("BIP messages") that enable BioAPI-conforming
    application in telebiometric systems.

53
Q.8/17 Recommendations 4/4
  • X.tpp-1 A guideline of technical and managerial
    countermeasures for biometric data security
  • This Recommendation defines weakness and
    threats in operating telebiometric systems and
    proposes a general guideline of security
    countermeasures from both technical and
    managerial perspectives.
  • X.tpp-2 A guideline for secure and efficient
    transmission of multi-modal biometric data
  • This Recommendation defines threat
    characteristics of multi-modal biometric system,
    and provides cryptographic methods and network
    protocols for transmission of multi-modal
    biometric data.

54
ITU-T SG 17 Question 9Secure Communication
Services
  • Focus
  • Position of each topic
  • Mobile security
  • Home network security
  • Web services security
  • Secure applications services

55
Q.9/17 Focus
  • Develop a set of standards of secure application
    services, including
  • Mobile security Under study
  • Home network security Under study
  • Web Services security Under study
  • Secure application services Under study
  • Privacy protection for RFID and multimedia
    content and digital Identity management To be
    studied

56
Position of each topic
Web Services security
Application Server
Home Network
Mobile Terminal
Open Network
Mobile Network
Home network security
Mobile security
Secure application services
57
Q.9/17 - Mobile Security
  • X.1121, Framework of security technologies for
    mobile end-to-end data communications Approved
    2004
  • X.1122, Guideline for implementing secure mobile
    systems based on PKI Approved 2004
  • X.msec-3, General security value added service
    (policy) for mobile data communication
  • Develops general security service as value added
    service for secure mobile end-to-end data
    communication.
  • X.msec-4, Authentication architecture in mobile
    end-to-end data communication
  • Constructs generic authentication architecture
    for mobile data communication between mobile
    users and application servers.
  • X.crs, Correlative reacting system in mobile
    network
  • Develops the generic architecture of a
    correlative reactive system to protect the mobile
    terminal against virus, worms, trojan-horses or
    other network attacks to both the mobile network
    and its mobile users.

58
Q.9/17 - Home network security
  • X.homesec-1, Framework for security technologies
    for home network
  • Framework of security technologies for home
    network
  • Define security threats and security
    requirements, security functions, security
    function requirements for each entity in the
    network, and possible implementation layer
  • X.homesec-2, Certificate profile for the device
    in the home network
  • Device certificate profile for the home network
  • Develops framework of home network device
    certificate.
  • X.homesec-3, User authentication mechanisms for
    home network service
  • User authentication mechanisms for home network
    service.
  • Provides the user authentication mechanism in the
    home network, which enables various
    authentication means such as password,
    certificate, biometrics and so on.

59
Q.9/17 - Web Services security
  • X.websec-1, Security Assertion Markup Language
    (SAML)
  • Security assertion markup language
  • Adoption of OASIS SAML v2.0 into ITU-T
    Recommendation X.1141 - Consented April 2006
  • Define XML-based framework for exchanging
    security information.
  • The security information expressed in the form of
    assertions about subjects, where a subject is an
    entity (either human or computer) that has an
    identity in some security domain.
  • X.websec-2, eXtensible Access Control Markup
    Language (XACML)
  • eXtensible Access Control Markup Language
  • Adoption of OASIS XACML v2.0 into ITU-T
    Recommendation X.1142 - Consented April 2006
  • Provides an XML vocabulary for expressing access
    control policies and the syntax of the language
    and the rules for evaluating policies.
  • X.websec-3, Security architecture for message
    security in mobile Web Services
  • Develops a guideline on message security
    architecture and service scenarios for securing
    messages for mobile Web Services.

60
Q.9/17 - Secure applications services
  • X.sap-1, Guideline on strong password
    authentication protocols
  • Guideline on secure password-based authentication
    protocol with key exchange.
  • Define a set of requirements for password-based
    protocol with key exchange and a selection
    guideline by setting up criteria that can be used
    in choosing an optimum authentication protocol
    for each application.
  • X.sap-2, Secure communication using TTP service
  • Secure end-to-end data communication techniques
    using TTP services
  • Specifies secure end-to-end data communication
    techniques using TTP services that are services
    defined in X.842 or other services.
  • X.p2p-1, Anonymous authentication architecture in
    community communication
  • Requirements of security for peer-to-peer and
    peer-to-multi peer communications
  • Investigates threat analysis for P2P and P2MP
    communication services and describes security
    requirements for secure P2P and P2MP
    communication services.
  • X.p2p-2, Security architecture and protocols for
    peer to peer network
  • Security architecture and protocols for peer to
    peer network
  • Describes the security techniques and protocols
    in the P2P environment.

61
ITU-T SG 17 Question 17Countering spam by
technical means
  • Objectives
  • Set of Recommendations

62
Q.17/17 Objectives
  • The aim of this Question is to develop a set of
    Recommendations on countering spam by technical
    means for ITU-T, taking into account the need for
    collaboration with ITU-T other Study Groups and
    cooperation with other SDOs. The Question focuses
    particularly on technical requirement, frameworks
    and new technologies for countering spam.
    Guidelines on countering spam by technical means
    are also studied.

63
Spam definitionSG2 TD 3 Rev.3 (PLEN/2)
  • The ITUs WSIS Thematic Meeting on Countering
    Spam, held 7-9 July 2004 in Geneva
    (http//www.itu.int/osg/spu/spam/chairman-report.p
    df), looked at the issue of defining spam. As
    reported in the Chairmans Conclusions of that
    meeting, the description of what the term is
    commonly used for is as follows
  • 12. Although there is no universally agreed
    definition of spam, the term is commonly used to
    describe unsolicited electronic bulk
    communications over e-mail or mobile messaging
    (SMS, MMS), usually with the objective of
    marketing commercial products or services. While
    this description covers most kinds of spam, a
    recent and growing phenomenon is the use of spam
    to support fraudulent and criminal
    activitiesincluding attempts to capture
    financial information (e.g. account numbers and
    passwords) by masquerading messages as
    originating from trusted companies
    (brand-spoofing or phishing) and as a
    vehicle to spread viruses and worms. On mobile
    networks, a particular problem is the sending of
    bulk unsolicited text messages with the aim of
    generating traffic to premium-rate numbers.

64
Spam definition (2)SG2 TD 3 Rev.3 (PLEN/2)
  • The OECD Task Force on Spam also addressed the
    question of defining spam in its Anti-Spam
    Toolkit launched publicly in April 2006, where
    the Task Force noted that
  • SPAM can be considered as the slang term for the
    reception of unsolicited messages, usually of
    commercial nature, and sent to multiple
    destinations. Anyone can send SPAM, it is easy to
    do and costs very little, and can be done through
    a variety of media, from email to fax and mobile
    phones.
  • However, there is no commonly held definition of
    the term. Although broadly referring to the same
    phenomena, different countries define spam in a
    manner that is most relevant to their local
    environment. The simplest view of spam is
    that it is any received message that is unwanted
    by the recipient. In terms of developing a policy
    response to spam, or anti-spam legislation, this
    definition is too broad and simplistic.
    Definitions will generally be the accretion of
    additional technical, economic, social and
    practical aspects of spam.

65
Spam definition (3)SG2 TD 3 Rev.3 (PLEN/2)
  • A definition was also elaborated for the
    tripartite Memorandum of Understanding on spam
    enforcement signed in July 2004 by the relevant
    regulatory authorities of Australia, the United
    States and the United Kingdom.
  • For the purposes of this Memorandum,
  • Spam Violations means conduct prohibited by a
    countrys Commercial Email Laws that is
    substantially similar to conduct prohibited by
    the Commercial Email Laws of the other countries,
    including, but not necessarily limited to
  • 1. sending commercial email containing deceptive
    content
  • 2. sending commercial email without providing the
    recipient with a means, such as a valid email
    address or an Internet based mechanism, to
    request that such communications cease
  • 3. sending commercial email that contains
    misleading information about the message
    initiator, or fails to disclose the senders
    address or
  • 4. sending commercial email, when the recipient
    has specifically requested the sender not to do
    so.

66
Q.17/17 Set of Recommendations
67
Q.17/17 Brief Summaries of draft Recommendations
under development 1/2
  • X.csreq, Requirement on countering spamThis
    Recommendation provides the general
    characteristics of spam, elicits generic
    objectives and provides an overview of the
    technical requirements on countering spam. In
    addition, this Recommendation provides checklist
    to evaluate the solution on countering spam.
  • X.fcs, Technical framework for countering email
    spam
  • This Recommendation specifies the technical
    framework for network structure for the
    countering spam. Functions inside the framework
    are defined. It also includes the commonsensible
    characteristics of email spam, the universal
    rules of judgement and the common methods of
    countering email spam.

68
Q.17/17 Brief Summaries of draft Recommendations
under development 2/2
  • X.gcs, Guideline on countering email spam
    (X.gcs)
  • This Recommendation specifies technical
    issues on countering email spam. It provides the
    current technical solutions and related
    activities from various SDOs and relevant
    organizations on countering email Spam. It will
    be used as a basis for further development of
    technical Recommendations on countering email
    spam.
  • X.ocsip, Overview of countering spam for IP
    multimedia applicationThis Recommendation
    specifies basic concepts, characteristics, and
    effects of Spam in IP multimedia applications
    such as IP Telephony, video on demand, IP TV,
    instant messaging, multimedia conference, etc. It
    will provide basis and guideline for developing
    further technical solutions on countering Spam.

69
Security Work in other ITU-T Study Groups
  • SG 4 Security of Management plane
  • SG 9 IPCablecom
  • SG 13 NGN security
  • SG 16 Multimedia security
  • SG 19 Security in IMT-2000

70
SG 4 Security of the management plane (M.3016
series)
  • Approved last year, the M.3016 series is viewed
    as a key aspect of NGN Management it is included
  • in the NGN Management Roadmap issued by the
    NGNMFG
  • In M.3060 on the Principles of NGN Management
  • The M.3016 series consists of 5 parts
  • M.3016.0 Overview
  • M.3016.1 Requirements
  • M.3016.2 Services
  • M.3016.3 Mechanisms
  • M.3016.4 Profile proforma
  • The role of M.3016.4 is unique in that it
    provides a template for other SDOs and forums to
    indicate for their membership what parts of
    M.3016 are mandatory or optional

71
SG 9 IPCablecom Evolution
  • Enhance cables existing IP service environment
    to accelerate the convergence of voice, video,
    data, and mobility
  • Define an application agnostic architecture that
    allows cable operators to rapidly innovate new
    services
  • Provide a suite of Recommendations that define
    the elements and interfaces needed to facilitate
    multi-vendor interoperability
  • Incorporate leading communications technologies
    from the IETF and 3GPP IMS

72
SG 9 IPCablecom Evolution
73
SG 9 Targeted Applications
  • Enhanced Cable Voice and Video IP Telephony
  • Support for new media and client types (e.g.,
    video telephony, soft clients)
  • Call treatment based on presence, device
    capability, identity
  • Maintain support for cable telephony features
    enabled by current IPCablecom Recommendations
  • Fixed-mobile Convergence over Cable
  • Support for dual mode cellular/WiFi handsets over
    DOCSIS
  • Call handover between IPCablecom VoIP networks
    and cellular networks
  • Integrated features and call control between
    cellular and VoIP platforms
  • Cable Cross-Platform Features
  • Cross platform notification, messaging (e.g.,
    Caller-ID on TV)
  • Third-party call control features, such as Click
    to dial

74
SG 9 Design Approach
  • Incorporate new IP communication technologies
  • Focus on the Session Initiation Protocol (SIP)
    and supporting protocols
  • Leverage the 3GPP IMS as a service delivery
    platform
  • Develop a modular and extensible architecture
    that allows new services to be added without
    impacting the core IPCablecom infrastructure
  • Ensure backward compatibility with existing
    IPCablecom Recommendations
  • Support a wide variety of client devices

75
SG 9 IPCablecom Security Requirements Under
Consideration
  • Support a range of authentication schemes
  • UICCs (similar to SIM card)
  • Digital Certificates (existing IPCablecom EMTAs)
  • SIP digest (software clients)
  • Support a range of secure signaling options
  • IPsec
  • TLS
  • Disabled
  • Support secure configuration before registration
  • Support TLS for intra-domain security
  • Minimize changes to IMS
  • Reuse existing standards

76
SG 9 DOCSIS base line privacy
  • The primary goals of DOCSIS BPI are to provide
    privacy of customer traffic, integrity of
    software downloads, and prevent theft of service.
  • DOCSIS BPI provides a number of tools to support
    these goals
  • Traffic encryption for privacy/confidentiality.
  • Secure Software Download to assure a valid CM
    image.
  • Configuration file authentication to help secure
    the provisioning process.
  • Focus is on the link layer between the CMTS and
    CM. Security outside the DOCSIS network is
    provided by applications and other networks.

77
SG 9 DOCSIS BPI Security Algorithms
  • A Cable Modem Terminations System (CMTS)
    authenticates cable modems (CM) using X.509
    certificates and RSA public key cryptography.
  • Subscriber Traffic encryption
  • 3DES used for key exchange
  • DES used for traffic encryption. AES being
    considered for future DOCSIS versions.
  • SW download image validation is performed using
    X.509 certificates and digital signatures using
    RSA public key cryptography.
  • Message integrity checks (MIC) with keyed MD5
    hash used for CM configuration file security.

78
SG 13 NGN Security Outline
  • Why NGN security?
  • The ITU-T work on NGN Security
  • Relationship to other SDOs
  • Output of the NGN Focus Group
  • Recent developmentsstarting the SG 13 Security
    work
  • Top NGN security issues that need resolution

Security is among the key differentiators of the
NGN. It is also among its biggest challenges!..
All SG 13 Recommendations have a security section
79
SG 13 Why Security?(Threat examples)
  • Providers perspective
  • Theft of service
  • Denial of service
  • Disclosure of network topology
  • Non-audited configuration changes
  • Additional related risks to the PSTN
  • Subscribers perspective
  • Eavesdropping, theft of PIN codes
  • Tele-spam
  • Identity theft
  • Infection by viruses, worms, and spyware
  • Loss of privacy (call patterns, location, etc.)
  • Flooding attacks on the end point

In NGN, known IP security vulnerabilities can
make PSTN vulnerable, too!
80
SG 13 The ITU-T work on NGN Security
  • SG 13 Lead Study Group on the NGN
    standardization. (Question 15/13 is responsible
    for X.805-based NGN security)
  • SG 17 Lead Study Group on Telecommunication
    Securitythe fundamental X.800 series, PKI, etc.
  • SG 4 Lead Study Group on Telecommunication
    ManagementManagement Plane security
  • SG 11 Lead Study Group on signaling and
    protocolssecurity of the Control and Signaling
    planes
  • SG 16 Lead Study Group on multimedia terminals,
    systems and applicationsMultimedia security

FGNGN has concluded its work has moved to SG 13
81
Collaboration of ITU-T with other SDOs and fora
on NGN security Recommendations
ATIS
ISO/IEC JTC1 SC 27,
ITU-T SG 13, 17, 4, 11, 16
IETF
3GPP
3GPP2
Fora (such as OASIS)
ETSI TISPAN
TIA
SG 13 is the Lead Study Group for NGN SG 17 is
the Lead Study Group for Security
82
SG 13 Question 15NGN security
  • Question 15 (NGN security) of SG 13 ITU-T lead
    study group for NGN and satellite matters - will
    continue standards work started by FGNGN WG 5.
  • Q.15/13 major tasks are
  • Lead the NGN-specific security project-level
    issues within SG 13 and with other Study Groups.
    Recognizing SG 17s overall role as the Lead
    Study Group for Telecommunication Security,
    advise and assist SG 17 on NGN security
    coordination issues.
  • Apply the X.805 Security architecture for systems
    providing end-to-end communication within the
    context of an NGN environment
  • Ensure that
  • the developed NGN architecture is consistent with
    accepted security principles
  • Ensure that AAA principles are integrated as
    required throughout the NGN

83
SG 13 FGNGN output Security Requirements for
NGN Release 1 (highlights)
  • Security requirements for the Transport Stratum
  • NGN customer network domain
  • Customer network to IP-Connectivity Access
    Network (IP-CAN) interface
  • Core network functions
  • NGN customer network to NGN customer network
    interface
  • Security requirements for the Service Stratum
  • IMS securty
  • Transport domain to NGN core network interface
  • Open service platforms and applications security
  • VoIP
  • Emergency Telecommunication Services and
    Telecommunications for Disaster Relief

84
SG 13 FGNGN output Guidelines for NGN Security
Release 1 (highlights)
  • General
  • General principles and guidelines for building
    secure Next Generation Networks
  • Detailed examination of IMS access security and
    NAT and firewall traversal
  • NGN Security Models
  • Security Associations model for NGN
  • Security of the NGN subsystems
  • IP-Connectivity Access Network
  • IMS Network domain and IMS-to-non-IMS network
    security
  • IMS access
  • Framework for open platform for services and
    applications in NGN
  • Emergency Telecommunications Service (ETS) and
    Telecommunications for Disaster Relief (TDR)
    Security
  • Overview of the existing standard solutions
    related to NAT and firewall traversal

85
SG 13 Focus of the current work of Question 15,
NGN security
  • Security Requirements for NGN Release 1
  • Authentication requirements for NGN Release 1
  • AAA Service for Network Access to NGN
  • Guidelines for NGN Security Release 1
  • Security considerations for Pseudowire (PWE)
    technology

At the heart of securing network protocols, the
biggest challenge is authentication.
86
SG 13 Major issues for NGN security
standardization
  • Key distribution (for end-users and network
    elements) and Public Key Infrastructure
  • Network privacytopology hiding and
    NAT/Firewall traversal for real-time applications
  • Convergence with IT security
  • Management of security functions (e.g., policy)
  • Guidelines on the implementation of the IETF
    protocols (e.g., IPsec options)
  • Security for supporting access DSL, WLAN, and
    cable access scenarios
  • Guidelines for handling 3GPP vs. 3GPP2
    differences in IMS Security

Bothnetwork assets and network trafficmust be
protected. Proper management procedures will help
prevent attacks from within.
87
SG 13 NGN Architecture
88
SG 16 Multimedia security in Next Generation
Networks
  • ITU-T SG 16 MM-security activities Overview
    (Q.25 and Q.5)
  • Status and results within SG16.
  • Ongoing and future activities within SG16.

89
Question 25/16 Multimedia Security
inNext-Generation Networks (NGN-MM-SEC)
  • Study Group 16 concentrates on Multimedia
    systems.
  • Q.25/16 focuses on the application-security
    issues of MM applications in next generation
    networks
  • Standardizes Multimedia Security
  • So far Q.25 has been standardizing MM-security
    for the 1st generation MM/pre-NGN?-systems
  • H.323/H.248-based systems.

90
Evolution of H.235
Improvement and Additions
Consolidation
1st Deployment
Core SecurityFrameworkEngineering
H.235V3 Amd1 Annex H
H.235V3 Amd1
H.235V3 Annex I
H.235 Annex G
H.235V2 Annex D Annex E approved
Security Profiles Annex D Annex E started
Annex F H.530 consent
H.235V1 approved
Initial Draft
H.323V5
H.323V2
H.323V4
1997
1998
1999
2000
2001
2002
2003
2004
1996
gt 2005
91
H.235 v4 subseries Recommendations
  • Major restructuring of H.235v3 Amd1 and annexes
    in stand-alone subseries Recommendations
  • H.235.x subseries specify scenario-specific
    MM-security procedures as H.235-profiles for
    H.323
  • Some new parts added
  • Some enhancements and extensions
  • Incorporated corrections
  • Approved in Sept. 2005

92
H.323 Security Recommendations (1)
  • H.235.0 Security framework for H-series (H.323
    and other H.245-based) multimedia systems
  • Overview of H.235.x subseries and common
    procedures with baseline text
  • H.235.1 "Baseline Security Profile
  • Authentication integrity for H.225.0 signaling
    using shared secrets
  • H.235.2 "Signature Security Profile
  • Authentication integrity for H.225.0 signaling
    using X.509 digital certificates and signatures

93
H.323 Security Recommendations (2)
  • H.235.3 "Hybrid Security Profile"
  • Authentication integrity for H.225.0 signaling
    using an optimized combination of X.509 digital
    certificates, signatures and shared secret key
    managementspecification of an optional
    proxy-based security processor
  • H.235.4 "Direct and Selective Routed Call
    Security"
  • Key management procedures in corporate and in
    interdomain environments to obtain key material
    for securing H.225.0 call signaling in GK
    direct-routed/selective routed scenarios

enhanced
extended
94
H.323 Security Recommendations (3)
  • H.235.5 "Framework for secure authentication in
    RAS using weak shared secrets"
  • Secured password (using EKE/SPEKE approach) in
    combination with Diffie-Hellman key agreement for
    stronger authentication during H.225.0 signaling
  • H.235.6 "Voice encryption profile with native
    H.235/H.245 key management"
  • Key management and encryption mechanisms for RTP

enhanced
modified
95
H.323 Security Recommendations (4)
  • H.235.7 "Usage of the MIKEY Key Management
    Protocol for the Secure Real Time Transport
    Protocol (SRTP) within H.235"
  • Usage of the MIKEY key management for SRTP
  • H.235.8 "Key Exchange for SRTP using secure
    Signalling Channels"
  • SRTP keying parameter transport over secured
    signaling channels (IPsec, TLS, CMS)
  • H.235.9 "Security Gateway Support for H.323"
  • Discovery of H.323 Security Gateways(SG H.323
    NAT/FW ALG) and key management for H.225.0
    signaling

96
Other SG16 MM-SEC Results
  • H.350.2 (2003) H.350.2 Directory Services
    Architecture for H.235
  • An LDAP schema to represent H.235 elements (PWs,
    certificates, ID information)
  • H.530 (Revision 2003) Symmetric security
    procedures for H.323 mobility in H.510
  • Authentication, access control and key management
    in mobile H.323-based corporate networks

97
Q.5/16 (H.300 NAT/FW traversal) Results (1)
  • H.460.18 Traversal of H.323 signalling across
    FWs and NATs
  • H.323 protocol enhancements and new client/server
    proxies to allow H.323 signalling protocols
    traverse NATs FWsH.323 endpoints can remain
    unchanged
  • H.460.19 NAT FW traversal procedures for RTP
    in H.323 systems
  • uses multiplexed RTP media mode and symmetric RTP
    in conjunction with H.460.18 as a short-term
    solution

98
More Q.5/16 Results (2)
  • Technical Paper Requirements for Network Address
    Translator and Firewall Traversal of H.323
    Multimedia Systems
  • Documentation of scenarios and requirements for
    NAT FW traversal in H.323
  • Technical Paper Firewall and NAT traversal
    Problems in H.323 Systems
  • An analysis of scenarios and various problems
    encountered by H.323 around NAT FW traversal

99
New Q.25/16 itemsunder current study (1)
  • Draft H.460.spn Security protocol negotiation
  • Goal Negotiate security protocols(IPsec or TLS)
    for H.323 signaling)
  • (Draft) H.FSIC Federated Architecture for Secure
    Internet Conferencing
  • Goal Define a generic protocol independent
    security profile for globally scalable security
    conferencing using trust federations.

100
New Q.25/16 itemsunder current study (2)
  • Study Anti-DDoS (Denial-of-Service)
    countermeasures for (H.323-based) NAT/FW proxy
    and MM applications
  • Security for MM-QoS (H.mmqos.security)
  • MM security aspects of Vision H.325Next-generati
    on Multimedia Terminals and Systems
About PowerShow.com