NENA NG-SEC Audit Checklist
NENA 75-502, Version 1, December 14, 2011
Next Generation 9-1-1
Security (NG-SEC)
Audit Checklist
NENANext Generation 9-1-1 (NG-SEC) Audit Checklist
NENA 75-502, Version 1, December 14, 2011
Development Steering Council Approval Date, November 1, 2011
Standards Advisory Committee Approval Date, November 22, 2011
NENA Executive Board Approval Date, December 14, 2011
Prepared by:
National Emergency Number Association (NENA) Joint Technical and Operations Security for Next Generation 9-1-1 Working Group.
Published by NENA
Printed in USA
NENA
INFORMATION DOCUMENT
NOTICE
The National Emergency Number Association (NENA) publishes this document as an information source for the designers and manufacturers of systems to beutilized for the purpose of processing emergency calls. It is not intended to provide complete design specifications or parameters or to assure the quality of performance for systems that process emergency calls.
NENA reserves the right to revise this Information Document for any reason including, but not limited to:
- conformity with criteria or standards promulgated by various agencies
- utilization of advances in the state of the technical arts
- or to reflect changes in the design of network interface or services described herein.
It is possible that certain advances in technology will precede these revisions. All NENA documents are subject to change as technology or other influencing factors change.Therefore, this NENA document should not be the only source of information used. NENA recommends that readers contact their 9-1-1 System Service Provider (9-1-1 SSP) representative to ensure compatibility with the 9-1-1 network.
Patents may cover the specifications, techniques, or network interface/system characteristics disclosed herein. No license expressed or implied is hereby granted. This document shall not be construed as a suggestion to any manufacturer to modify or change any of its products, nor does this document represent any commitment by NENA or any affiliate thereof to purchase any product whether or not it provides the described characteristics.
This document has been prepared solely for the use of E9-1-1 System Service Providers, network interface and system vendors, participating telephone companies, etc.
By using this document, the user agrees that NENA will have no liability for any consequential, incidental, special, or punitive damages arising from use of the document.
NENA’s Committees have developed this document. Recommendations for change to this document may be submitted to:
National Emergency Number Association
4350 North Fairfax Drive, Suite750
Arlington, VA 22203-1695
800-332-3911
or:
Acknowledgments:
The National Emergency Number Association (NENA) Operations and TechnicalCommittee Chairs developed this document. NENA recognizes the following industry experts and their companies for their contributions in development of this document.
Version 1, Approval Date, 12/14/2011
Members / Company/AgencySmith - CISSP, Jeremy - Working GroupTechnical Co-Leader / L.R. Kimball
Vanauken, Gordon- Working Group Operations Co-Leader / L.R. Kimball
Vislocky, Mike – CPE Chair / Network Orange, Inc.
Walthall - CISSP, Robert CPE Vice Chair / National Public Safety Solutions
Boyken, Bill / AT&T
Davis, Kenneth / Sangamon County ETSD
Erdman, Bob / Amcom Software
Herron, Myron S / Synergem
Irwin, Dave / Washington Military Department, Emergency Management Division
Kaczmarczyk, Casimer M / Verizon
Kelley, Robert
Lagreid, Steve / King County E9-1-1 Program
Lewis, Shelby / Positron
Lipinski, Jim / State of VT
Mathis, CISSP ENP PSNP, Ron / Intrado Inc.
McClure, ENP, Nate / AECOM
McIntire, Clay / North Central Texas Council of Governments
Oenning, Bob / State of Washington
Rodabaugh, Carl
Rosen, Brian / NeuStar
Schoenberg, Carter / Motorola
Skain, John / Clinton County 9-1-1
Sylvester, Robert L. / Convergent Technologies, Inc.
Wilcox, Nathan G / microDATA
This working group would also thank Tom Breen, Technical Committee Chair/Liaison; Tony Busam,Technical Committee Vice-Chair/Liaison; Pete Eggimann, Operations Committee Chair/Liaison; WendyLively, Operations Committee Chair/Liaison; Roger Hixson, Technical Issues Director; and Rick Jones,Operations Issues Director for their support and assistance. The committee/working group would also like to give a special thank you to KennethDavisfor support & assistance in formatting the original standard into the checklist format.
TABLE OF CONTENTS
1Executive Overview
2Introduction
2.1Operations Impacts Summary
2.2Technical Impacts Summary
2.3Security Impacts Summary
2.4Document Terminology
2.5Reason for Issue/Reissue
2.6Recommendation for Additional Development Work
2.7Date Compliance
2.8Anticipated Timeline
2.9Costs Factors
2.10Future Path Plan Criteria for Technical Evolution
2.11Cost Recovery Considerations
2.12Additional Impacts (non-cost related)
2.13Intellectual Property Rights Policy
2.14Acronyms/Abbreviations
3Operations or Technical Description
4Appendices
5Recommended Reading and References
Version 1,December 14, 2011 Page 1 of 102
NENA NG-SEC Audit Checklist
NENA 75-502, Version 1, December 14, 2011
1Executive Overview
This Information Document is a companion to the NENA 75-001 - NENA Security for Next-Generation 9-1-1 Standard (NG-SEC) Standard. To effectively use this document the user should have a clear understanding of the concepts and procedures described therein.
This checklist provides a summary of the requirements and recommendations detailed in the NG-SEC standard and provide the educated user a method to document a NG-SEC Audit. The checklist has spaces to document the findings of the audit.
The auditor can use this document to record if the 9-1-1 entity complies or not with the listed item. There is also room to make notes of the findings. Each checklist item is further categorized as:
- R – Requirement
- BP – Best Practice
The date and auditor’s identity should also be documented, including cases where multiple auditors may be used.
2Introduction
2.1Operations Impacts Summary
This document will impact the operations of 9-1-1 systems and PSAPs as standardized security practices are implemented where they have not been in place before. NG9-1-1 Entities will be required to understand, implement and maintain new security solutions, mechanisms and processes.
2.2Technical Impacts Summary
Certain security features of various 9-1-1 equipment may be impacted as standardized security practices are implemented where they have not been in place before. NG9-1-1 Entities will be required to understand, implement and maintain new security solutions, mechanisms and processes.
2.3Security Impacts Summary
This security checklist references the NG-SEC standard which may impact other NENA standards. Accordingly it should be reviewed by each NENA committee to determine impact.
2.4Document Terminology
The terms "shall", "must" and "required" are used throughout this document to indicate required parameters and to differentiate from those parameters that are recommendations. Recommendations are identified by the words "desirable" or "preferably".
2.5Reason for Issue/Reissue
NENA reserves the right to modify this document. Upon revision, the reason(s) will be provided in the table below.
Version / Approval Date / Reason For ChangesOriginal / 12/14/2011 / Initial Document
2.6Recommendation for Additional Development Work
No additional standards work was identified, but continued updates to the NG-SEC documents will be needed to keep them current.
2.7Date Compliance
All systems that are associated with the 9-1-1 process shall be designed and engineered to ensure that no detrimental, or other noticeable impact of any kind, will occur as a result of a date/time change up to 30 years subsequent to the manufacture of the system. This shall include embedded application, computer based or any other type application.
To ensure true compliance, the manufacturer shall upon request, provide verifiable test results to an industry acceptable test plan such as Telcordia GR-2945 or equivalent.
2.8Anticipated Timeline
This checklist is available for use immediately, and may take several days to complete the checklist.
2.9Costs Factors
The implementation of this checklist will have costs of the time to complete the checklist. Additional cost to implement the recommendations of the NG-SEC Standard as identified by the use of this checklist.
2.10Future Path Plan Criteria for Technical Evolution
In present and future applications of all technologies used for 9-1-1 call and data delivery, it is a requirement to maintain the same level or improve on the reliability and service characteristics inherent in present 9-1-1 system design.
New methods or solutions for current and future service needs and options should meet the criteria below. This inherently requires knowledge of current 9-1-1 system design factors and concepts, in order to evaluate new proposed methods or solutions against the Path Plan criteria.
Criteria to meet the Definition/Requirement:
- Reliability/dependability as governed by NENA’s technical standards and other generally accepted base characteristics of E9-1-1 service
- Service parity for all potential 9-1-1 callers
- Least complicated system design that results in fewest components to achieve needs (simplicity, maintainable)
- Maximum probabilities for call and data delivery with least cost approach
- Documented procedures, practices, and processes to ensure adequate implementation and ongoing maintenance for 9-1-1 systems
This basic technical policy is a guideline to focus technical development work on maintaining fundamental characteristics of E9-1-1 service by anyone providing equipment, software, or services.
2.11Cost Recovery Considerations
Normal business practices shall be assumed to be the cost recovery mechanism.
2.12Additional Impacts (non-cost related)
The information or requirements contained in this NENA document are expected to have 9-1-1 technical and center operational impacts, based on the analysis of the authoring group. At the date of publication of this document, development had not started. The primary impacts are expected to include:
- Time needed to complete this checklist
- Changes to operational procedures
- New equipment
- New staff skill sets
2.13Intellectual Property Rights Policy
NENAtakes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights.
NENA invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard.
Please address the information to:
National Emergency Number Association
4350 N Fairfax Dr, Suite 750
Arlington, VA 22203-1695
800-332-3911
or:
2.14Acronyms/Abbreviations
Acronyms/abbreviations used in this document have been included in the original standard document 75-001.
Version 1,December 14, 2011 Page 1 of 102
NENA NG-SEC Audit Checklist
NENA 75-502, Version 1, December 14, 2011
3Operations or Technical Description
The following instructions and clarifications are provided to guide the auditor.
- For each section, provide the auditor name, title, and contact information, as well as the date the audit section was completed
- For each audit question, choose C for “comply,”No for “does not comply” or not applicable (N/A) for “the requirement is not applicable.” If N/A is chosen, provide commentary as to why the question isn’t application in the comments column. Items marked No are deemed out of compliance with the NG-SEC standard.
- Please refer to the NG-SEC standard (NENA Document 75-001) itself as a reference for questions of interpretation.
- As noted earlier, audit questions consist of Requirements (R) and Best Practices (BP).
- For questions or sections not audited please indicate they were not audited using the comments column
Version 1,December 14, 2011 Page 1 of 102
NENA NG-SEC Audit Checklist
NENA 75-502, Version [1], [December 14, 2011]
Audit Item Number / NG-SEC Standard / Audit Area / Compliance Type / Compliance Finding / Comments
1 / 4.1 / Has Senior Management created a Senior Management Statement (SMS) of Policy?
(Audit Guidance: this could take the shape of a security plan, executive level security policy, or other such documents. The auditor should use his/her discretion as to whether the document in question meets the requirements of this portion of the NG-SEC standard) / R / C No N/A
2 / 4.1 / Does the SMS designate the person responsible for security (e.g. Security Administrator)? / R / C No N/A
3 / 4.1 / Does the SMS clearly document the security goals and objectives of the organization? / R / C No N/A
Section 1 - Senior Management Statement / Auditor:______Date:______
Version 1, December 14, 2011 Page 1 of 102
NENA NG-SEC Audit Checklist
NENA 75-502, Version [1], [December 14, 2011]
Audit Item Number / NG-SEC Standard / Audit Area / Compliance Type / Compliance Finding / Comments
4 / 4.2 / Does the organization have an Acceptable Usage Policy? / R / C No N/A
5 / 6.6 / Are any and all actual, attempted, and/or suspected misuses of Public Safety assets reported and documented by appropriate organizations? / R / C No N/A
Section 2 - Acceptable Use Policy / Auditor:______Date:______
Version 1, December 14, 2011 Page 1 of 102
NENA NG-SEC Audit Checklist
NENA 75-502, Version [1], [December 14, 2011]
Audit Item Number / NG-SEC Standard / Audit Area / Compliance Type / Compliance Finding / Comments
6 / 4.2 / Does the organization have an Authentication / Password Policy? / R / C No N/A
7 / 7.1.1 / Is each individual requiring access to the NG9-1-1 System provided a unique Identification and authentication? / R / C No N/A
8 / 7.1.1 / Do individuals share their authentication information (including usernames and passwords) with other individuals or groups? / R / C No N/A
9 / 7.1.2 / Are requests for new User Accounts, User IDs, and File and Resource authorization documented?
(Audit Guidance: review applicable documentation and processes for adequacy of process and adherence to process) / R / C No N/A
10 / 7.1.2 / Do personnel performing entity or security administration ensure that only approved entities are granted access? / R / C No N/A
11 / 7.1.2.1 / Does the organization have procedures for changing access authority? / R / C No N/A
12 / 7.1.2.1 / Does the organization have procedures for removing access authority for terminated personnel? / R / C No N/A
13 / 7.1.3 / When system to system access is implemented does the system mask individual accountability for transactions?
(Audit Guidance: The system shall not mask individual accountability for transactions) / R / C No N/A
14 / 7.1.3 / When system to system access is implemented is the source system authenticated before each transfer session? / R / C No N/A
15 / 7.1.3 / When system to system access is implemented and push technology is utilized, is the destination authenticated by the source? / R / C No N/A
16 / 7.1.3 / When system to system access is implemented and a continuous connection is utilized, was authentication performed at the initial connection? / R / C No N/A
17 / 7.1.3 / When system to system access is implemented are individuals accessing any of the systems required to Authenticate when initially accessing each system? / R / C No N/A
18 / 7.1.5 / Are Authentication Credentialsdisplayed in an obscured format when entered on computer screens?
(Auditor Guidance: Check to see if passwords can be seen on the screen when typed in. They should not be able to be seen so as to prevent “shoulder surfing.”) / R / C No N/A
19 / 7.1.4 / Are users locked out after no more than 5 invalid sign on attempts? / R / C No N/A
20 / 7.1.5 / Are Default and Null Passwords changed when installing new equipment or software? / R / C No N/A
21 / 7.1.5 / Are Authentication Credentials encrypted when stored on a computer? / R / C No N/A
22 / 7.1.5 / When two-factor authentication is used, (e.g. SecurID + Pin or Certificate + Passphrase) are two authentication factors stored in such fashion that one incident can compromise both?
(Auditor Guidance: e.g. password or pin isn’t written down on the token, or stored with the token) / R / C No N/A
23 / 7.1.5.1 / All user accounts shall require a password / R / C No N/A
24 / 7.1.5.1 / Passwords are not based on the user’s account name. / R / C No N/A
25 / 7.1.5.1 / Passwords must meet the following complexity requirements:
- Contains characters from three of the following four categories:
- Uppercase alphabet characters (A–Z)
- Lowercase alphabet characters (a–z)
- Arabic numerals (0–9)
- Non-alphanumeric characters (for example, !$#,%)
26 / 7.1.5.1 / Minimum password length shall be 8 characters or greater / R / C No N/A
27 / 7.1.5.1 / Minimum password age shall be 3 days or greater / R / C No N/A
28 / 7.1.5.1 / Maximum password age requirement 60 days or less / R / C No N/A
29 / 7.1.5.1 / Maximum password age recommendation 30 days / BP / C No N/A
30 / 7.1.5.1 / If feasible, authentication schemes shall provide for password exchange in a format that cannot be captured and reused/replayed by unauthorized users to gain authenticated access, e.g., random password generating tokens or one-way encryption (also known as hashing) algorithms. / R / C No N/A
31 / 7.1.5.1 / When using temporary passwords they shall be required to be changed upon initial login / R / C No N/A
32 / 7.1.5.1 / Passwords should not be hard coded into automatic login sequences, scripts, source code and batch files, etc., unless required by business need and then only if protected by security software and/or physical locks on the workstation, and passwords are encrypted. / BP / C No N/A
33 / 7.1.5.1 / Password construction should be complex enough to avoid use of passwords that are easily guessed, or otherwise left vulnerable to cracking or attack. Names, dictionary words, or combinations of words shall not be used; nor shall they contain substitutions of numbers for letters, e.g., s3cur1ty. Repeating numbers or sequential numbers shall also not be used / BP / C No N/A
34 / 7.1.5.1 / Passwords should not contain sequences of three (3) or more characters from the user's login ID or the system name. / BP / C No N/A
35 / 7.1.5.1.4 / Passwords should not contain sequences of three (3) or more characters from previous chosen or given passwords. / BP / C No N/A
36 / 7.1.5.1.5 / Passwords should not contain a sequence of two (2) or more characters more than once, e.g., a12x12. / BP / C No N/A
37 / 7.1.5.1.5 / Passwords used to access Public Safety systems and resources should not be used on any external systems, e.g., Home PC's, Internet sites, shared public systems. / BP / C No N/A
38 / 7.1.5.2 / When Passphrases are used do they have a required length of at least 15 characters?
(Audit Guidance: Alpha, numeric and special characters may all be used.) / R / C No N/A
39 / 7.1.5.2 / When Passphrases are used they shall not use repeating words, or sequential characters or numbers. / R / C No N/A
40 / 7.1.5.2 / When Passphrases are used they shall be case sensitive / C No N/A
41 / 7.1.5.2 / When Passphrases are used and where they are automatically set or set by administrator, the initial passphrase shall be randomly generated and securely distributed. / R / C No N/A
42 / 7.1.5.2 / When Passphrases are used first-time users may create their own passphrase after authenticating. / R / C No N/A
43 / 7.1.5.2 / When Passphrases are usedUsers shall have the capability of changing their own passphrase online. However, the old passphrase shall be correctly entered before a change is allowed / R / C No N/A
44 / 7.1.5.2 / When Passphrases are used a lost or forgotten passphrase can be reset only after verifying the identity of the user (or process owner) requesting a reset. / R / C No N/A
45 / 7.1.5.2 / When Passphrases are usedpassphrases shall automatically expire every 180 days or less for General Users. / R / C No N/A
46 / 7.1.5.2 / When Passphrases are used systems shall notify users at expiration time and allow the user to update the passphrase. / R / C No N/A
47 / 7.1.5.2 / When Passphrases are used and when it is changed, the old passphrase shall not be reused until either:
1. at least four (4) other passphrases have been used, or
2. at least 4 months have passed. / R / C No N/A
48 / 7.1.5.2 / When Passphrases are usedsystems shall not display the passphrase in clear text as the user enters it. / R / C No N/A
49 / 7.1.5.2 / When Passphrases are used shall not be stored in script files or function keys. / R / C No N/A
50 / 7.1.5.2 / When Passphrases are used Passphrases shall always be encrypted for transmission / R / C No N/A
51 / 7.1.5.3 / If Digital Certificates are used is a revocation procedure in place if compromised? / R / C No N/A
52 / 7.1.5.3 / Are Digital Certificates kept current and expired or invalid certificates not used? / R / C No N/A
53 / 7.1.5.3 / Cryptographic implementations use standard implementations of security applications, protocols, and format? / R / C No N/A
54 / 7.1.5.3 / Cryptographic implementations shall be purchased from reputable vendors? / R / C No N/A
55 / 7.1.5.3 / If Cryptographic solutions are developed in-house staff should be properly trained in cryptology. / R / C No N/A
56 / 7.1.5.3 / Do employees protect and safeguard any encryption keys for which they are responsible? / R / C No N/A
57 / 7.1.5.3 / Employees do not share private encryption keys with others except when applicable or appropriate authorities demand the key be surrendered (Termination, Promotion, Investigation etc.) / R / C No N/A
58 / 7.1.5.3 / A process exists by which current validity of a certificate can be checked and a certificate can be revoked
Validity testing includes:
- Do key holders initiate key revocation when they believe access to their keys have been compromised
- Has the Certificate Authority signature on the certificate been validated
- Is the date the certificate is being used within the validity period for the certificate
- The Certificate Revocation List for the certificates of that type are checked to ensure they have not been revoked
- The identity represented by the certificate - the "distinguished name" is valid (distinguished name refers to the location in the x.500 database where the object in question exists)
59 / 7.2.6 / In order to help assure segregation of duties, developers shall not be System Administrators for the Production Systems they have developed (small, stand-alone systems can be excepted from this requirement) / R / C No N/A
Section 3 - Authentication / Password Policy / Auditor:______Date:______
Version 1, December 14, 2011 Page 1 of 102