1、 ATIS-0300033 Next Generation Interconnection Interoperability (NGIIF) Reference Document Part X, Interconnection Between LECS Operations Handbook Local Interconnection Service Arrangement Attachment A Security Guidelines Version 12.0 ATIS is the leading technical planning and standards development
2、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-Based and
3、 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, Connected Vehi
4、cle, 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 Sectors,
5、 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 (ATIS) spons
6、ored 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 architecture, disa
7、ster 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 technologies. A
8、ll 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. The la
9、st 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 accepted engi
10、neering 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 REGULATION,
11、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, AND IN
12、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-0300033, NGIIF Reference Document, Part X, Interconnection Between L
13、ECS Operations Handbook Local Interconnection Service Arrangement, Attachment A, Security Guidelines, Formerly NIIF 5029 The NGIIF Reference Document, Part X, Interconnection Between LECS Operations Handbook Local Interconnection Service Arrangement, Attachment A, Security Guidelines is an ATIS stan
14、dard 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. No part of this publication may be reproduced in any form, in an el
15、ectronic 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. 2 INTERCONNECTION BETWEEN LECs OPERATIONS HANDBOOK, ATTACHMENT A NETWORK SECURITY BASE GUIDELINES
16、Table of Contents 1 GENERAL 3 2 DATA SECURITY FEATURES OF CRITICAL SWITCHING NODES . 3 2.1 IDENTIFICATION 3 2.2 AUTHENTICATION . 3 2.3 SYSTEM ACCESS CONTROL . 3 2.4 RESOURCE ACCESS CONTROL 4 2.5 SECURITY LOG (AUDIT) 4 2.6 SECURITY ADMINISTRATION 5 2.7 DOCUMENTATION . 5 3 SYSTEMS ENGINEERING APPROACH
17、 TO SECURITY BASELINE FOR TELECOMMUNICATIONS NETWORK NODES, LOGICAL SECURITY CHECKLIST 6 3 1 General The following Network Security Base Guidelines should be used at a minimum as a set of guidelines to be adopted by the Local Service Providers as they interconnect and on an ongoing basis. 2 Data Sec
18、urity Features of Critical Switching Nodes This section specifies the desirable security features that all LSP should have for any Network Element (NE), Network System (NS), Operations System (OS) or Data Communications Network (DCN) in order to reduce the risk of potentially service affecting secur
19、ity compromises. 2.1 Identification The LSP 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 a switching node should be associated with the corresponding user-ID (so that an audit trail can b
20、e established if there is a need). The node under query should disable a user-ID if it has remained inactive (i.e., never used) over a specific time period. 2.2 Authentication All remote input ports of a node (including direct, dial-up and network access) should require authentication of a session r
21、equester, without 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 node should not prevent a user from choosing (unknowingly) a password that is already being used by some other user.
22、 Nor should the 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,
23、typewriter, or printer) of a password at any time (e.g., login, file dump, etc.). The node should allow passwords to be user changeable (requiring re-authentication), and should require that the user change it the first time he/she establishes a session with the password assigned to him/her. The def
24、ault should be non-trivial in nature. The password should have an “aging“ feature, and it should have a complexity requirement to make it not easily determined. The node should not accept common words or names as valid passwords. Also, it should not allow a recently obsolete password to be readily r
25、e-selected by the said user. 2.3 System Access Control The node should not allow access to any session requester unless identified and authenticated. There should be no default mechanism to circumvent it. The node should not allow any session to be established via a port that is not authorized to ac
26、cept input commands. For example, if an output port receives a Log on request, the node should not respond. 4 The entire Log on 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, and no “
27、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 Log on attempt is that the Log on is invalid. After a specified number of incorrect Log on attempts carried out in succession, the n
28、ode should lock out the channel and raise an alarm in real time for the administrator. Before the session begins, the 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 node should display the da
29、te 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 node should disconnect or re-authenticate users after a specified time interv
30、al during which no messages were exchanged. Also, there should be a mechanism for user-initiated keyboard locking. The node should provide a mechanism to end a session through a secure log off procedure. If a session gets interrupted due to reasons such as time-out, power failure, link disconnection
31、, etc., the port should be dropped immediately. For dial-up access over un-trusted channels, authentication involving one time passwords should be required (e.g., smart card, third party authentication, etc.). 2.4 Resource Access Control Access to resources should be controlled on the basis of “priv
32、ilege“ (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 primary access cont
33、rol 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 should be adequately f
34、ine-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 nodes resource (e.g., propr
35、ietary data) should be protected from access by unauthorized persons. Executable/loadable/fetchable software should be access controlled for overwrite, update, and execution rights. 2.5 Security Log (Audit) The node should generate a security log containing information sufficient for after-the-fact
36、investigation of loss or impropriety. 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 security log does not function pro
37、perly. The security log should, as a minimum, record events such as all sessions established, invalid user authentication attempts, unauthorized attempts to access resources (including data and transactions), changes in users security profiles and attributes, changes in access rights to resources, c
38、hanges in the node security configuration, and modification of 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 address, etc., names of resources accessed, and success or failure of t
39、he event. 5 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 specific data items, users, or communication facilities. 2.6 Security Administration The node should support functi
40、ons 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 appropriate administrator. The administrator should be able to display all curre
41、ntly 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, terminals, ports, or network addresses. The administrator should be able to i
42、dentify 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, which should not be retrievable). The administrator should limit the
43、use of a “null password“ during system Log on 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 the buffer is full. All security parameters (e.g., password aging int
44、erval, time-out interval, various alarm conditions) should be specific and adjustable by the administrator. This implies that the node should not have any security parameters hard coded. 2.7 Documentation Any node supplier/vendor should provide documentation on security considerations for administra
45、tors, 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 controlled to secure the facility, proper usage of security audit tools, procedures fo
46、r examining and maintaining audit files, procedures for periodic saving and backup of security logs, recommendations on setting the minimum access permissions on all files, directories, and databases, guidelines on security assessment techniques. The operators guide should contain procedures necessa
47、ry to initially start the node in a secure manner and to resume secure operation after any lapse that may have occurred. The users guide should describe the protection mechanisms that are non-transparent to the user, should explain their purpose, and provide guidelines on their use. It should not co
48、ntain any information that could jeopardize the security of the 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.
49、6 3 Systems Engineering Approach to Security Baseline for Telecommunications Network Nodes, Logical Security Checklist Question Yes/No If No, Why not? Is security addressed across the entitys entire network? Are Critical Common Environments defined and isolated (e.g. by firewall perimeters) to limit access to authorized processes and users? If fire walls are deployed are they placed around the “perimeter“ or perimeters critical components, NEs, NSs and OSs? Are software changes controlled and verified to maintain the established security perimeter? Has a security baseline be
