1、 ATIS-0300020 Next Generation Interconnection Interoperability (NGIIF) Reference Document Part III, Installation, Testing and Maintenance Responsibilities for SS7 Links and Trunks Attachment I SS7 Network Security Base Guidelines Version 12.0 ATIS is the leading technical planning and standards deve
2、lopment organization committed to the rapid development of global, market-driven standards for the information, entertainment and communications industry. More than 200 companies actively formulate standards in ATIS Committees, covering issues including: IPTV, Cloud Services, Energy Efficiency, IP-B
3、ased and Wireless Technologies, Quality of Service, Billing and Operational Support, Emergency Services, Architectural Platforms and Emerging Networks. In addition, numerous Incubators, Focus and Exploratory Groups address evolving industry priorities including Smart Grid, Machine-to-Machine, Connec
4、ted Vehicle, IP Downloadable Security, Policy Management and Network Optimization. ATIS is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications
5、Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). ATIS is accredited by the American National Standards Institute (ANSI). For more information, please visit www.atis.org. Notice This document was developed by the Alliance for Telecommunications Industry Solutions (ATI
6、S) sponsored Next Generation Interconnection Interoperability Forum (NGIIF). The NGIIF addresses next-generation network interconnection and interoperability issues associated with emerging technologies. Specifically, it develops operational procedures which involve the network aspects of architectu
7、re, disaster preparedness, installation, maintenance, management, reliability, routing, security, and testing between network operators. In addition, the NGIIF addresses issues which impact the interconnection of existing and next generation networks and facilitate the transition to emerging technol
8、ogies. All changes to this document shall be made through the NGIIF issue resolution process. Note Regarding Previous Versions The NIIF Reference Document was formerly known as the Network Operations Forum (NOF) Reference Document. The NOF Reference Document was published and maintained by Bellcore.
9、 The last version of the NOF Reference Document is Issue 13. Disclaimer and Limitation of Liability The information provided in this document is directed solely to professionals who have the appropriate degree of experience to understand and interpret its contents in accordance with generally accept
10、ed engineering or other professional standards and applicable regulations. No recommendation as to products or vendors is made or should be implied. NO REPRESENTATION OR WARRANTY IS MADE THAT THE INFORMATION IS TECHNICALLY ACCURATE OR SUFFICIENT OR CONFORMS TO ANY STATUTE, GOVERNMENTAL RULE OR REGUL
11、ATION, AND FURTHER NO REPRESENTATION OR WARRANTY IS MADE OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR AGAINST INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS. ATIS SHALL NOT BE LIABLE, BEYOND THE AMOUNT OF ANY SUM RECEIVED IN PAYMENT BY ATIS FOR THIS DOCUMENT, WITH RESPECT TO ANY CLAIM,
12、AND IN NO EVENT SHALL ATIS BE LIABLE FOR LOST PROFITS OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES. ATIS EXPRESSLY ADVISES THAT ANY AND ALL USE OF OR RELIANCE UPON THE INFORMATION PROVIDED IN THIS DOCUMENT IS AT THE RISK OF THE USER. ATIS-0300020, NGIIF Reference Document, Part III, Installation and
13、 Maintenance Responsibilities for SS7 Links and Trunks, Attachment G, SS7 Network Security Base Guidelines, Formerly NIIF 5015 The NGIIF Reference Document, Part III, Installation and Maintenance Responsibilities for SS7 Links and Trunks, Attachment G, SS7 Network Security Base Guidelines, is an ATI
14、S standard developed by the NGIIF. Published by Alliance for Telecommunications Industry Solutions 1200 G Street, NW, Suite 500 Washington, DC 20005 Copyright 2011 by Alliance for Telecommunications Industry Solutions All rights reserved. 2 No part of this publication may be reproduced in any form,
15、in an electronic retrieval system or otherwise, without the prior written permission of the publisher. For information contact ATIS at 202.628.6380. ATIS is online at . Printed in the United States of America. 3 SS7 NETWORK SECURITY BASE GUIDELINES Table of Contents 1 GENERAL 4 1.1 PURPOSE OF THIS D
16、OCUMENT . 4 2 SECURITY BASELINE FOR SS7 . 4 2.1 DATA SECURITY FEATURES OF CRITICAL SS7 NODES 4 2.2 IDENTIFICATION 4 2.3 AUTHENTICATION . 4 2.4 SYSTEM ACCESS CONTROL . 5 2.5 RESOURCE ACCESS CONTROL 5 2.6 SECURITY LOG (AUDIT) 5 2.7 SECURITY ADMINISTRATION 6 2.8 DOCUMENTATION . 6 3 CONCLUSION 7 4 1 Gen
17、eral The following SS7 Network Security Base Guidelines should be used as a minimum set of guidelines to be adopted by the Access Service Providers and the Access Service Customers. 1.1 Purpose of this Document This document is intended to provide a minimum set of general guidelines to be adopted by
18、 the Access Service Providers and Access Service Customers. 2 Security Baseline for SS7 2.1 Data Security Features of Critical SS7 Nodes This section specifies the desirable security features that any SS7 Network Element (NE), Network System (NS), Operations System (OS) or Data Communications Networ
19、k (DCN) should provide in order to reduce the risk of potentially service affecting security compromises. Highlights of the critical components of those documents are listed below. For the sake of brevity, the term “SS7 node“ in the following list is used to imply an NE, NS, OS, or a DCN and its nod
20、es. 2.2 Identification The SS7 node should not allow an existing user-ID to be assigned to another active user (i.e., user-IDs should be unique). Each operations related process running in the SS7 node should be associated with the corresponding user-ID (so that an audit trail can be established if
21、there is a need). The SS7 node should disable a user-ID if it has remained inactive (i.e., never used) over a specifiable time period. 2.3 Authentication All OAM&P input ports of the SS7 node (including direct, dial-up and network access) should require authentication of a session requester, without
22、 any provision for a bypass mechanism. A single stored password entry (e.g., in a password file) should not be allowed to be shared by multiple user-IDs. However, the SS7 node should not prevent a user from choosing (unknowingly) a password that is already being used by some other user. Nor should t
23、he SS7 node volunteer this information to either user. Passwords should be stored in a one-way encrypted form, and should not be retrievable by any user including managers or administrators (of system and security). Also, there should be no clear text display (on a device such as a screen, typewrite
24、r, or printer) of a password at any time (e.g., login, file dump, etc.). The SS7 node should allow passwords to be user changeable (requiring reauthentication), and should require that the user change it the first time he/she establishes a session with the password assigned to him/her. The default s
25、hould be non-trivial in nature. The password should have an “aging“ feature, and it should have a complexity requirement to make it not easily guessable. The SS7 node should not accept common words or names as valid passwords. Also, it should not allow a recently obsolete password to be readily rese
26、lected by the said user. 5 2.4 System Access Control The SS7 node should not allow access to any session requester unless identified and authenticated. There should be no default mechanism to circumvent it. The SS7 node should not allow any session to be established via a port that is not authorized
27、 to accept input commands. For example, if an output port receives a login request, the SS7 node should not respond. The entire login procedure should be allowed to be completed without interruption, even if incorrect parameters (such as an incorrect user-ID or an incorrect password) are entered, an
28、d no “help message“ should be transmitted to the session requester as to which part of the authentication is incorrect. The only information to be conveyed at the end of the login attempt is that the login is invalid. After a specified number of incorrect login attempts carried out in succession, th
29、e SS7 node should lock out the channel and raise an alarm in real time for the administrator. Before the session begins, the SS7 node should provide a warning message explicitly alerting the user of the consequences of unauthorized access and use. At the beginning of the session, the SS7 node should
30、 display the date and time of the users last successful access and the number of unsuccessful attempts, if any, that have been made to establish a session since the last successful access. There should be a “time-out“ feature - i.e., the SS7 node should disconnect or reauthenticate users after a spe
31、cified time interval during which no messages were exchanged. Also, there should be a mechanism for user-initiated keyboard locking. The SS7 node should provide a mechanism to end a session through a secure logoff procedure. If a session gets interrupted due to reasons such as time-out, power failur
32、e, link disconnection, etc., the port should be dropped immediately. For dial-up access over untrusted channels, authentication involving one time passwords should be required (e.g., smart card, third party authentication, etc.). 2.5 Resource Access Control Access to resources should be controlled o
33、n the basis of “privilege“ (i.e., access permission) associated with user-ID and channel. It should not be based on a “password“ associated with the access function, because that password will have to be necessarily shared among all users requiring such access. Neither should encryption be used as a
34、 primary access control mechanism (though encryption may be used to enhance it). The granularity of resource access control should be such that for each resource it should be possible to grant (or deny) access privilege to any single user (or a prescribed group of users). For example, the control sh
35、ould be adequately fine-grained so that user access and channel access can be restricted on the basis of commands, database views (i.e., objects), records (i.e., object instances), and fields (i.e., attributes). If external entities - e.g., customers, are allowed access to the resources, each SS7 no
36、des resource (e.g., proprietary data) should be protected from access by unauthorized persons. Executable/loadable/fetchable software should be access controlled for overwrite, update, and execution rights. 2.6 Security Log (Audit) The SS7 node should generate a security log containing information s
37、ufficient for after-the-fact investigation of loss or impropriety. 6 The security log should be protected from unauthorized access. No user should be allowed to modify or delete a security log. There should be no mechanism to disable the security log. There should be an alarm in real time if the sec
38、urity log does not function properly. The security log should, at a minimum, record events such as all sessions established, invalid user authentication attempts, and unauthorized attempts to access resources (including data and transactions). It should also include changes in users security profile
39、s and attributes, changes in access rights to resources, changes in the SS7 node security configuration, and modification of SS7 node software. For each such event, the record should, as a minimum, include date and time of event, initiator of the event such as: user-ID, terminal, port, network addre
40、ss, etc., names of resources accessed, and success or failure of the event. Actual or attempted passwords should not be recorded in the security log. There should be audit tools to produce exception reports, summary reports, and detailed reports on specifiable data items, users, or communication fac
41、ilities. 2.7 Security Administration The SS7 node should support functions for the “management“ of security related data (e.g., security parameters such as user-IDs, passwords, privileges, etc.) as “separate“ from other user functions. Security administration should be reserved only for an appropria
42、te administrator. The administrator should be able to display all currently logged-in users as well as a list of all authorized user-IDs. The administrator should be able to independently and selectively monitor, in real time, the actions of any one or more users based on respective user-IDs, termin
43、als, ports, or network addresses. The administrator should be able to identify all resources owned by or accessible to any specific user along with the associated access privileges. The administrator should be able to enter, edit, delete or retrieve all attributes of a user-ID (except for a password
44、, which should not be retrievable). The administrator should limit the use of a “null password“ during system login on a per user or per port basis (i.e., during new release installation). The administrator should be able to save the security log for safe storage, so that it is not written over when
45、 the buffer is full. All security parameters (e.g., password aging interval, time-out interval, various alarm conditions) should be specifiable and adjustable by the administrator. This implies that the SS7 node should not have any security parameters hard coded. 2.8 Documentation Any SS7 node suppl
46、ier/vendor should provide documentation on security considerations for administrators, operators, and users. They can be stand alone documents or sections incorporated in appropriate vendor manuals. The administrators guide should contain items such as: functions and privileges that need to be contr
47、olled to secure the facility, proper usage of security audit tools, procedures for examining and maintaining audit files, and procedures for periodic saving and backup of security logs. It should also include recommendations on setting the minimum access permissions on all files, directories, and da
48、tabases, guidelines on security assessment techniques. The operators guide should contain procedures necessary to initially start the SS7 node in a secure manner and to resume secure operation after any lapse that may have occurred. 7 The users guide should describe the protection mechanisms that ar
49、e non-transparent to the user, should explain their purpose, and provide guidelines on their use. It should not contain any information that could jeopardize the security of the SS7 node if made public. The above list is not exhaustive. There are requirements related to other areas such as: data and system integrity, and various phases of life cycle involving design, packaging, delivery, and support by the vendor. 3 Conclusion The following table includes a list of questions that should be addressed when performing a security analysis. The list is not a complete list but is prov
