fg1b cyber security best practices -- draft€¦ · xls file · web viewbps by column service...

document.xls

of 107

Number 6-6-8000Title Disable Unnecessary Services

Reference

Dependency 6-6-8502Implementor NO, SP

Preventative Best Practice

Unneeded network-accessible services that are not needed or used should be disabled on any network/service element or management system when practical. E.g., Network Time Protocol (NTP), Remote Procedure Calls (RPC), Finger, Rsh-type commands, etc.

Configuration guides for security from NIST, CERT, NSA, SANS, vendors, etc.

document.xls

of 107

NumberTitle

Reference

DependencyImplementor


6-6-8001Strong Encryption Algorithms and Keys

6-6-8503All

Use industry-accepted algorithms and key lengths for all uses of encryption.

ftp://ftp.t1.org/t1m1/NEW-T1M1.5/2m151252.pdf


document.xls

of 107

NumberTitle

Reference



6-6-8002

ES

Proper Wireless LAN/MAN Configurations

Equipment supplier should be encouraged to change the default installation configuration for Wireless LANs, so that it is less likely that an unknowledgeable, or home user, will configure a network that 'works" sut has no security.

document.xls

of 107

NumberTitle

Reference



6-6-8003Reliability and Resiliency for Security

6-6-8504, 6-6-8027, 6-6-8037NO, SP

Single points of failure should be minimized in the architecture, alternative power sources, including back-up generators or DC powering should be included, critical applications should run on dedicated computers, and information should not be transferred to any connected system that does not have equivalent security controls. Establish redundancy for single points of failure where critical. Regularly exercise redundant and back-up systems, especially those for infrastructure management and control. Maintain spares for point of failure that do not have 'online' backup. Maintain trusted back-ups for element configuration and software loads.

document.xls

of 107

NumberTitle

Reference



6-6-8004Harden Default Configurations

6-6-8505ES

Vendors should work closely and regularly with CERT, NSA and customers to address concerns with existing default settings and prevent further default settings from introducing vulnerabilities.

document.xls

of 107

NumberTitle

Reference



6-6-8005Document Single Points of Failure

ISF SB52

6-6-8506NO, SP

Components that are critical to the continuity of the infrastructure and single points of failure should be identified and recorded.

document.xls

of 107

NumberTitle

Reference



6-6-8006Enforce Least-Privilege-Required Access Levels

ISF CB63, NRIC BP 5-510

6-6-8507NO, SP

Web servers should be prevented from running with high-level privileges, interfaces between web servers and back-office systems should be restricted to services required and supported by mutual authentication, sensitive data in transit should be protected by encryption, and key systems configuration info should not be inadvertently made available to 3rd parties.

document.xls

of 107

NumberTitle

Reference



6-6-8007Define Security Architecture

6-6-8508NO, SP

Each organization should develop a formal, written Security Architecture and make it readily accessible to systems administrators and security staff for use during threat response. Develop a contingency plan listing resources such as people, processing capability, data, applications, and infrastructure needed. Ensure business continuity function is led and properly funded at accountable senior level, independent of operational conflicts.

Octave Catalog of Practices, Version 2.0,CMU/SEI-2001-TR-20 (http://www.cert.org/archive/pdf/01tr020.pdf) Practice SP6.2; NIST Special Pub 800-12, NIST Special Pub 800-14

document.xls

of 107

NumberTitle

Reference



6-6-8008Network Architecture Isolation/Partitioning

ISF SB52, www.sans.org

6-6-8509NO, SP

Compartmentalization of technical assets is a basic isolation principle of security where contamination or damage to one part of an overall asset chain does not disrupt or destroy other parts of an asset chain. Network Operators and Service Providers should give deliberate thought to and document an Architecture plan that partitions and isolates network communities and information, through the use of firewalls, DMZ or (virtual) private networks. In particular, where feasible, it is suggested the user traffic networks, network management infrastructure network, customer transaction system networks and enterprise communication/business operations networks be separated and partitioned from one another. Special care must to taken to assess OS, protocol and application vulnerabilities, and subsequently hardened and secure systems and applications, which are located in DMZ's or exposed to the open Internet.

document.xls

of 107

NumberTitle

Reference



6-6-8009

6-6-8510ES

Protect Sensitive Information Stored on Network Systems/Elements

Equipment deployed in insecure or remote locations should include intrusion detection mechanisms that enable stored critical information to be destroyed upon detection of attack.

FIPS 140-2, PUB 46-3, PUB 74, PUB 81, PUB 171, PUB 180-1, PUB 197, ANSI X9.9, X9.52, X9.17

document.xls

of 107

NumberTitle

Reference



6-6-8010OAM&P Product Security Features

ES

Implement current industry baseline requirements for OAM&P security in products -- software, network elements and management systems.



document.xls

of 107

NumberTitle

Reference



6-6-8011Request OAM&P Security Features

NO, SP

Request products from vendors that meet current industry baseline requirements for OAM&P security.



document.xls

of 107

NumberTitle

Reference



6-6-8012Secure Communications for OAM&P Traffic

NO, SP

To prevent unauthorized users from accessing OAM&P systems, Service Providers and Network Operators should use strong authentication for all users. To protected against tampering, spoofing, eavesdropping and session hijacking, Service Providers and Network Operators should use a trusted path for all important OAM&P communications between network elements, management systems and OAM&P staff. Examples of trusted paths that might adequately protect the OAM&P communications include separate private-line networks, VPNs or encrypted tunnels. Any sensitive OAM&P traffic that is mixed with customer traffic should be encrypted. OAM&P communication via TFTP and Telnet is acceptable if the whole communication path is secured. OAM&P traffic to customer premises equipment should also be via a trusted path.



document.xls

of 107

NumberTitle

Reference



6-6-8013Controls for OAM&P Management Actions

NO, SP

Authenticate, authorize, attribute and log all management actions on critical infrastructure elements and management systems. This especially applies to management actions involving security resources such as passwords, encryption keys, access control lists, time-out values, etc.



document.xls

of 107

NumberTitle

Reference



6-6-8014OAM&P Privilege Levels

NO, SP

For Operations, Administration, Management and Provisioning (OAM&P), use element and system features that provide the least-privilege for each OAM&P user to accomplish their tasks. Use role-based access controls where possible.

ftp://ftp.t1.org/t1m1/NEW-T1M1.5/2m151252.pdf NRIC V BP 5-550


document.xls

of 107

NumberTitle

Reference



6-6-8015Segmenting Management Domains

NO, SP

For OAM&P activities and operations centers, segment (compartmentalize) administrative domains with firewalls that have restrictive rules for traffic in both directions and that require authentication for traversal. In particular, segment OAM&P networks from the NO/SP's intranet and the Internet. Treat each domain as hostile to all other domains. Follow industry recommended firewall policies for protecting critical internal assets.

Need reference to robust firewall configuration and management.

NRIC V BP 5-547

document.xls

of 107

NumberTitle

Reference



6-6-8016OAM&P Security Architecture

6-6-8008NO, SP

Design and deploy an OAM&P security architecture based on industry recommendations.

ftp://ftp.t1.org/t1m1/NEW-T1M1.5/2m151252.pdfSection B.1

NRIC V BP 5-510

document.xls

of 107

NumberTitle

Reference



6-6-8017OAM&P Protocols

All

Use OAM&P protocols and their security features according to industry recommendations. Examples of protocols include SNMP, SOAP, XML, CORBA.


document.xls

of 107

NumberTitle

Reference



6-6-8018Hardening OAM&P User Access Control

All

For OAM&P applications and interfaces, harden the access control capabilities of each network element or system before deployment to remove default accounts, change default passwords, turn on checks for password complexity, turn on password aging, turn on limits on failed password attempts, turn on session inactivity timers, etc. All of this can usually be accomplished by connecting the system's access control mechanisms to a well-managed AAA server (e.g., RADIUS server) with similar features for ensuring access control quality.



document.xls

of 107

NumberTitle

Reference



6-6-8019Hardening COTS OSs for OAM&P

6-6-8004All

All devices with commercial-off-the-shelf operating systems used for OAM&P should have operating system hardening procedures applied.

Configuration guides for security from NIST, CERT, NSA, SANS, vendors, ftp://ftp.t1.org/t1m1/NEW-T1M1.5/2m151252.pdf, etc.

document.xls

of 107

NumberTitle

Reference



6-6-8020Security HyperPatching

All

Special procedures and tools should be in place to quickly patch critical infrastructure systems when important security patches are made available. HyperPatching should include expedited lab testing of the patches on how they affect the network and component devices.

document.xls

of 107

NumberTitle

Reference



6-6-8021Switched Hubs for OAM&P Networks

All

In critical networks for OAM&P, use switched network hubs so that devices in promiscuous mode are less likely to be able to see/spoof all of the traffic on that network segment.

document.xls

of 107

NumberTitle

Reference



6-6-8022Remote OAM&P Access

ISF CB53

NO, SP

External connections should be individually identified, risk assessed and formally approved. External connections should be restricted by strong authentication, firewalls, limited methods of connection, or granting access to only specified parts of the application.

document.xls

of 107

NumberTitle

Reference



6-6-8023Scanning OAM&P Infrastructure

NO, SP

Regularly scan infrastructure for vulnerabilities/exploitable conditions. Operators should understand the operating systems and applications deployed on their network and keep abreast of vulnerabilities, exploits and patches.

document.xls

of 107

NumberTitle

Reference



6-6-8024Limited Console Access

See FG1A BPs.All

Do not permit users to log on locally to the data systems or network elements. Do not permit local logon of users other than the system administrator. Some systems differentiate a local account database and network account database. Users should be authenticated onto the network using a network accounts database, not a local accounts database.

document.xls

of 107

NumberTitle

Reference



6-6-8025Protection from SCADA Networks

NO, SP

Networks for Telecom/Datacomm OAM&P should be isolated from other OAM&P networks (aka SCADA networks) such as for power, water, industrial plants, pipelines, etc.1. Isolate the SCADA network from the OAM&P network (segmentation)2. Put a very restrictive firewall as a front-end interface on the SCADA network for management access.3. Use an encryption or a trusted path to for the OAM&P network to communicate with the SCADA "front-end."4. Use SCADA-industry best practices to secure the SCADA network.

document.xls

of 107

NumberTitle

Reference



6-6-8026SNMP Mitigation

CERT

ref other BPsAll

Apply SNMP vulnerability patches to all systems on critical-infrastructure networks. Use difficult to guess community string names.

document.xls

of 107

NumberTitle

Reference



6-6-8027Software Integrity

NO, SP

Use software change management systems that control, monitor and record access to master source of software. Ensure network equipment and network management code consistency checks through digital signatures, secure hash algorithms and periodic audits.



document.xls

of 107

NumberTitle

Reference



6-6-8028Distribution of Encryption Keys

All

When encryption technology is used in the securing of network equipment and transmission facilities, cryptographic keys must be distributed using a secure protocol that, among other things i) Insures the authenticity of the recipient, ii) Does not depend upon a secure transmission facilities iii) Cannot be emulated by a non-trusted source.

document.xls

of 107

NumberTitle

Reference



6-6-8029Network Access to Critical Information

All

The networked availability of sensitive security information for critical infrastructure must be carefully controlled and monitored.* Periodic review of public and internal website, file storage sitesHTTP and FTP sites contents for strategic network information including but not limited to critical site locations, access codes. * Document sanitizing process and procedure required before uploading onto public internet or FTP site. * Ensure that all information pertaining to critical infrastructure is restricted to need-to-know and that all transmission of that information is encrypted. * Screen, limit, track, remote access to internal information resources about critical infrastructure.

document.xls

of 107

NumberTitle

Reference



6-6-8030OAM&P Session Times

All

All OAM&P applications, systems and interfaces should use session timers to disconnect, terminate or logout authenticated sessions that remain inactive past some preset (but ideally configurable) time limit that is appropriate for operational efficiency and security. "Screen savers" may help in some situations, but they generally are easily bypassed.

document.xls

of 107

NumberTitle

Reference



6-6-8031LAES Interfaces & Processes

All

Develop and communicate Lawfully Authorized Electronic Surveillance (LAES) policy. Limit the distribution of information about LAES interfaces. Conduct period risk assessments of LAES procedures. Audit LAES events for policy compliance.


NRIC V BP 5-505

document.xls

of 107

NumberTitle

Reference



6-6-8032Patching Practices

All

Design and deploy a patching process based on industry recommendations, especially for critical OAM&P systems.


document.xls

of 107

NumberTitle

Reference



6-6-8033Software Development

All

Evaluate for use industry recommendations for the secure development of critical-infrastructure software.


NRIC V BP 5-535

document.xls

of 107

NumberTitle

Reference



6-6-8034Software Patching Policy

NO, SP

Define and incorporate a formal patch/fix policy and process into the organization's security policies and processes.

document.xls

of 107

NumberTitle

Reference



6-6-8035Software Patch Testing

NO, SP

An organization's patch/fix policy and process should include steps to appropriately test all patches/fixes in a test environment prior to distribution into the production environment.

document.xls

of 107

NumberTitle

Reference



6-6-8036Exceptions to Patching

NO, SP

Systems that are not compliant with the patching policy should be noted and these particular elements should be monitored on a regular basis. These exceptions should factor heavily into the organization's monitoring strategy. Vulnerability mitigation plans should be developed and implemented in lieu of the patches. If no acceptable mitigation exists, the risks should be communicated to management.

document.xls

of 107

NumberTitle

Reference



6-6-8037System Inventory Maintenance

NO, SP

A complete inventory of elements should be maintained to ensure that patches/fixes can be properly applied across the organization. This inventory should be updated each time a patch/fix is identified and action is taken.

TBD

NRIC V BP 5-510

document.xls

of 107

NumberTitle

Reference



6-6-8038Security Evaluation Process

NO, SP

A formal process during system or service development should exist in which a review of security controls and techniques is performed by a group independent of the development group, prior to deployment. This review should be based on an organization's policies, standards and guidelines, as well as best practices. In instances where exceptions are noted, mitigation techniques should be designed and deployed and exceptions should be properly tracked.

document.xls

of 107

NumberTitle

Reference



6-6-8039Patch/Fix Verification

NO, SP

A verification process should be performed to ensure that patches/fixes are actually applied as directed throughout the organization. Exceptions should be reviewed and the proper patches/fixes actually applied.

document.xls

of 107

NumberTitle

Reference



6-6-8040Signaling General Principles

6-6-8001, 6-6-8020NO, SP

Network Operators and Service Providers can mitigate the fundamental vulnerabilities of signaling protocols by 1) Knowing and validating who you are accepting signaling information from, either by link layer controls or higher layer authentication, if the signaling protocol lacks authentication. 2) Filtering or screening the information received to only accept/propagate information that is reasonable/expected from that network element/peer. Employ guarded trust and mutual suspicion to reinforce filtering the peer/other network should have done. 3) Follow NRIC Best Practices for architectural and server hardening, and management controls to protect network elements and their management interfaces, especially elements with IP interfaces, against compromise and corruption. Vendors should make such controls and filters easy to manage and non-performance impacting. Network Operators, Service Providers and Equipment Suppliers should participate in Industry forums to define secure, authenticated signaling protocols and operational,business processes to implement them.

document.xls

of 107

NumberTitle

Reference



6-6-8041Prevent Network Element Resource Saturation

6-6-8523ES

Equipment suppliers for layer 3 switches/routers, with interfaces that mix user and control plane data, should provide filters and access lists on the header fields to protect the control plane from resource saturation to filtering out entrusted packets destined to for control plane. Measures may include: 1) Allowing the desired traffic type from the trusted sources to reach the control-data processor and discard the rest 2) separately Rate-limiting each type of traffic that is allowed to reach the control-data processor, to protect the processor from resource saturation.

document.xls

of 107

NumberTitle

Reference



6-6-8042BGP Authentication

6-6-8546NO, SP

Network Operators and Service Providers should know and validate who you are accepting routing information from, to protect against global routing table disruptions. Avoid BGP peer spoofing or session hijacking by using techniques such as but not limited to: 1) eBGP hop-count (TTL) limit to end of physical peering link, 2) MD5 session signature to mitigate route update spoofing threats.

ISP WG - BGP DNS, Scalable key distribution mechanisms, NRIC V FG 4: Interoperability

document.xls

of 107

NumberTitle

Reference



6-6-8043Prevent BGP Poisoning

6-6-8525NO, SP

Network Operator and Service Providers should use existing BGP filters to avoid propagating incorrect data: 1) Avoid route flapping DoS by implementing RIPE-229 to minimize the dampening risk to critical resources, 2) Stop malicious routing table growth due to de-aggregation by implementing Max-Prefix Limit on peering connections, 3) Employ ISP filters to permit customers to only advertise IP address blocks assigned to them, 4) Avoid disruption to networks that use documented special use addresses by ingress and egress filtering for "Martian" routes (special use address space), 5) Avoid DoS caused by un-authorized route injection (particularly from compromised customers) by egress filtering (to peers) and ingress filtering (from customers) prefixes assigned to other ISPs, 6) Stop DoS from un-allocated route injection (via BGP table expansion or latent backscatter) by filtering "bogons" (packets with unauthorized routes), not running default route or creating sink holes to advertise "bogons", 7) Employ route boundary filtering based on Internet Routing Registry lists, and 8) Employ "Murphy filter" (guarded trust and mutual suspicion) to reinforce filtering your peer should have done.

ISP WG - BGP DNS, RIPE-181, "A Route-Filtering Model for Improving Global Internet Routing Robustness" www.iops.org/Documents/routing.html

document.xls

of 107

NumberTitle

Reference



6-6-8044BGP Interoperability Testing

ISP WG - BGP DNS

NO, SP

Network Operators and Service Providers should conduct configuration inter-operability testing during peering link set-up; Encourage Equipment Suppliers to participate in interoperability testing forums and funded test-beds to discover BGP implementation bugs.

document.xls

of 107

NumberTitle

Reference



6-6-8045Protect Interior Routing Tables

6-6-8526NO

Network Operators and Service Providers should protect their interior routing tables by 1) Not allowing outsider access to internal routing protocol and filter routes imported into the interior tables 2) Implement MD5 between IGP neighbors

document.xls

of 107

NumberTitle

Reference



6-6-8046Protect DNS Servers against Compromise

6-6-6001, 6-6-8063, 6-6-8071, 6-6-8083, 6-6-8527SP

Service Providers should protect against DNS server compromise by implementing good server hygiene, which is implementing physical security, removing all unnecessary platform services, monitoring industry alert channels for vulnerability exposures, scanning DNS platforms for known vulnerabilities and security breaches, implementing intrusion detection on DNS home segments, not running the name server as root user/minimizing privileges where possible and blocking the file system from being compromised by protecting the named directory. Prepare a disaster recory plan, to implement upon DNS server compromise.

RFC-2870 ISO/IEC 15408 ISO 17799 CERT "Securing an Internet Name Server"

document.xls

of 107

NumberTitle

Reference



6-6-8047Protect Against DNS Denial of Service

6-6-8074, 6-6-8528SP

Service Providers should 1) increase DNS resiliency through redundancy and robust network connections 2) Have separate name servers for internal and external traffic as well as critical infrastructure, such as OAM&P and signaling/control networks 3) Where feasible, separate proxy servers from authoritative name servers 4) Protect DNS information by protecting master name servers with appropriately configured firewall/filtering rules, implement secondary masters for all name resolution, and using Bind ACLs to filter zone transfer requests.

RFC-2870 ISO/IEC 15408 ISO 17799 CERT "Securing an Internet Name Server"

document.xls

of 107

NumberTitle

Reference



6-6-8048Protect DNS from Poisoning

6-6-8527ES, SP

Service Providers should mitigate the possibility of DNS cache poisoning by 1) Preventing recursive queries 2) Configure short (2 day) Time-To-Live for cached data 3) Periodically refresh or verify DNS nameserver configuration data and parent pointer records. Service Providers and Equipment Suppliers should participate in forums to define an operational implementation of DNSSec.

RFC-1034 RFC-1035 RFC-2065 RFC-2181 RFC-2535 ISC BIND 9.2.1 CERT "Securing an Internet Name Server"

document.xls

of 107

NumberTitle

Reference



6-6-8049DHCP Authentication

6-6-8001, 6-6-8530NO, SP

Network Operators should employ techniques to make it difficult to send unauthorized DHCP information to customers and the DHCP servers themselves. Methods can include OS Hardening, router filters, VLAN configuration, or encrypted, authenticated tunnels. The DHCP servers themselves must be hardened, as well. Mission critical application should be assigned static addresses to protect against DHCP-based denial of service attacks.

draft-ietf-dhc-csr-07.txt, draft-aboba-dhc-domsearch-09.txt, draft-aboba-dhc-domsearch-09.txt, RFC2132, RFC1536, RFC3118

document.xls

of 107

NumberTitle

Reference



6-6-8050MPLS Configuration Security

ISP WG - Hardening, IETF RFC 2547

6-6-8531NO

Network Operators should protect the MPLS router configuration by 1) Securing machines that control login, monitoring, authentication and logging to/from routing and monitoring devices 2) Monitoring the integrity of customer specific router configuration provisioning 3) Implementing (e)BGP filtering to protect against labeled-path poisoning from customers/peers.

document.xls

of 107

NumberTitle

Reference



6-6-8051Network Access Control for SS7

NO

Network Operators should ensure that SS7 signaling interface points that connect to the IP, Private, and Corporate network interfaces are well hardened; protected with packet filtering firewalls; and enforce strong authentication. Similar safeguards should be implemented for e-commerce applications to the SS7 network. Network operators should implement rigorous screening on both internal and interconnecting signaling links and should investigate new, and more thorough screening capabilities. Operators of products built on general purpose computing products should proactively monitor all security issues associated with those products and promptly apply security fixes, as necessary. Operators should be particularly vigilant with respect to signaling traffic delivered or carried over Internet Protocol networks. Network operators that do employ the Public Internet for signaling, transport or maintenance communications and any maintenance access to Network Elements shall employ authentication, authorization, accountability, integrity and confidentiality mechanisms (e.g. digital signature and encrypted VPN tunneling).

NRIC BP 5-547, ITU SS7 Standards, “Securing SS7 Telecommunications Networks”, Proceedings of the 2001 IEEE Workshop on Information Assurance and Security, 5-6 June 2001.

document.xls

of 107

NumberTitle

Reference



6-6-8052SS7 Authentication

6-6-8532NO

Network Operators should mitigate limited SS7 authentication by enabling logging for SS7 element security related alarms on SCPs and STPs, such as: unauthorized dial up access, unauthorized logins, logging of changes and administrative access logging. Network operators should implement rigorous screening on both internal and interconnecting signaling links and should investigate new, and more thorough screening capabilities. Operators of products built on general purpose computing products should proactively monitor all security issues associated with those products and promptly apply security fixes, as necessary. Operators should establish login and access controls that establish accountability for changes to node translations and configuration. Operators should be particularly vigilant with respect to signaling traffic delivered or carried over Internet Protocol networks. Network operators that do employ the Public Internet for signaling, transport or maintenance communications and any maintenance access to Network Elements shall employ authentication, authorization, accountability, integrity and confidentiality mechanisms (e.g. digital signature and encrypted VPN tunneling). Operators making use of dial-up connections for maintenance access to Network Elements should employ dial-back modems with screening lists. One-time tokens and encrypted payload VPNs should be the minimum.NRIC BP 5-551, 5-616

NIIF Guidelines for SS7 Security

document.xls

of 107

NumberTitle

Reference



6-6-8053SS7 DoS Protection

NRIC BP 5-551

6-6-8533NO

Network Operators should establish thresholds for various SS7 message types to ensure that DoS conditions are not created. Also, alarming should be configured to monitor these types of messages to alert when DoS conditions are noted. Rigorous screening procedures can increase the difficulty of launching DDoS attacks. Care must be taken to distinguish DDoS attacks from high volumes of legitimate signaling messages. Maintain backups of signaling element data.

document.xls

of 107

NumberTitle

Reference



6-6-8054Anonymous use of SS7 signaling or SS7 controlled services

NRIC BP 5-551

6-6-8534NO

Network Operators should have defined policies and process for addition and configuration of SS7 elements to the various tables. Process should include the following: personal verification of the request (e.g., one should not simply go forward on a faxed or emailed request without verifying that it was submitted legitimately), approval process for additions and changes to SS7 configuration tables (screening tables, call tables, trusted hosts, calling card tables, etc.) to ensure unauthorized elements are not introduced into the network. Companies should also avoid global, non-specific rules that would allow unauthorized elements to connect to the network. Screening rules should be provisioned with the greatest practical depth and finest practical granularity in order to minimize the possibility of receiving inappropriate messages. Network operators should log translation changes made to network elements and record the user login associated with each change. These practices do not mitigate against the second threat mentioned below, the insertion of inappropriate data within otherwise legitimate signaling messages. To do so requires the development of new capabilities, not available in today's network elements.

document.xls

of 107

NumberTitle

Reference



6-6-8055Prevent VoIP Device Masquerades

PacketCable Security specification

6-6-8536ES, NO

Vendor supplied VoIP CPE devices need to support authentication service and integrity services as standards based solution become available. Network Operators need to turn-on and use these services in their architectures.

document.xls

of 107

NumberTitle

Reference



6-6-8056Operational VoIP Server Hardening

PacketCable Security specifications

6-6-8001, 6-6-8536NO

Network Operators should ensure that network servers have authentication, integrity, and authorization mechanisms to prevent inappropriate use of the servers.

document.xls

of 107

NumberTitle

Reference



6-6-8057VoIP Server Product Hardening

PacketCable Security specifications

6-6-8001ES

Equipment suppliers should provide authentication, integrity, and authorization mechanisms to prevent inappropriate use of the network servers. These capabilities must apply to all levels of user -- users, control and management.

document.xls

of 107

NumberTitle

Reference



6-6-8058Protect Cellular Service from Anonymous Use

6-6-8001, 6-6-8537NO

Prevent theft of service and anonymous use by enabling strong user authentication as per cellular/wireless standards. Employ fraud detection systems to detect subscriber calling anomalies (e.g. two subscribers using same ID or system access from a single user from widely dispersed geographic areas). In cloning situation remove the ESN to disable user thus forcing support contact with service provider. Migrate customers away from analog service if possible due to cloning risk.

Telcordia GR-815. Cellular Standards: GSM, PCS2000, CDMA, 1XRTT, UMTS, etc.

document.xls

of 107

NumberTitle

Reference



6-6-8059Protection of Cellular User Data Traffic

Cellular Standards: GSM, PCS2000, CDMA, 1XRTT, UMTS, etc.

NO, SP

Encourage use of IPSec VPN, wireless TLS, or other end-to-end encryption services over the Cellular/wireless network. Also, Network Operators should incorporate standards based data encryption services and ensure that such encryption services are enabled for end users. (Data encryption services are cellular/wireless technology specific).

document.xls

of 107

NumberTitle

Reference



6-6-8060Protect Cellular Management Traffic

6-6-8001, 6-6-8020, 6-6-8537NO

Network Operators should ensure strong separation of data traffic from management/signaling/control traffic, via firewalls. Network operators should ensure strong cellular network backbone security by employing operator authentication, encrypted network management traffic and logging of security events. Network operators should also ensure operating system hardenting and up-to-date security patches are applied for all network elements, element management system and management systems.

Telcordia GR-815. Cellular Standards: GSM, PCS2000, CDMA, 1XRTT, UMTS, etc.

document.xls

of 107

NumberTitle

Reference



6-6-8061IR Procedures

NO, SP

Establish a set of standards and procedures for dealing with computer security events. These procedures can and should be part of the overall business continuity/disaster recovery plan. Where possible, the procedures should be exercised periodically and revised as needed. Procedures should cover likely threats to those elements of the infrastructure which are critical to service delivery/business continuity

IETF RFC2350, CERT

NRIC V BP 5-507, 5-561, 5-585, 5-598, 5-599

document.xls

of 107

NumberTitle

Reference



6-6-8062IR Team

NO, SP

Identify and train a Computer Security Incident Response Team. This team should have access to the CSO (or functional equivalent) and should be empowered by senior management. The team should include a cadre of security and networking specialists but have the ability to augment itself with expertise from any division of the organization. Organizations that establish part-time CSIRTs should ensure representatives are detailed to the team for a suitable period of time bearing in mind both the costs and benefits of rotating staff through a specialized team.

IETF RFC2350, CMU/SEI-98-HB-001

NRIC V BP 5-537, 5-598

document.xls

of 107

NumberTitle

Reference



6-6-8063Intrusion Detection System

NO, SP

Install and actively monitor Intrusion Detection Systems (IDS). Sensor placement should afford security personnel with a view to resources critical to the delivery of service. IDS sensors should pass real-time alerts to a security event monitoring group for enterprise wide analysis and correlation. Where possible, a file integrity tool should be used to establish a “known good” profile for each mission critical system. This profile can be instrumental in determining if a system was compromised and if so, the nature and extent of the compromise. System profiles should be stored in a secure location and should be available to the Incident Response Team.

TBD

NRIC V BP 5-506, 5-608

document.xls

of 107

NumberTitle

Reference



6-6-8064Data Analysis

NO, SP

Identify critical resources within the infrastructure and ensure security relevant monitoring is enabled. Where practical, logs should be collected on a secure/trusted remote host and reviewed regularly. The use of automated scripts for the initial assessment can significantly reduce the level of effort required for the review. Event logs should be correlated with other data sources (i.e., IDS and Firewall logs) and kept in accordance with the organization's data retention policy. Where possible, all data should be passed to a central security monitoring group or fed into a correlation engine for assessment of events across time and across the enterprise. Consideration should be given to deploying a Network Time Protocol (NTP) server to ensure consistency of time stamps across data sources.

TBD

NRIC V BP 5-518

document.xls

of 107

NumberTitle

Reference



6-6-8065Sharing Information with Law Enforcement

NO, SP

Establish a protocol for releasing information to members of the law enforcement and intelligence communities and identify a single Point of Contact (POC) for coordination/referral activities. The POC must have an understanding of organizational policies on information sharing and release and should have direct access to the corporate counsel and Chief Security Officer (or functional equivalent). At a minimum, POC should consider participating InfraGard, the FBI's industry outreach program.

TBD

NRIC V BP5-561, 5-585

document.xls

of 107

NumberTitle

Reference



6-6-8066Sharing Information with Industry & Government

NO, SP

Participate in regional and national information sharing groups such as the National Coordinating Center for Telecommunications (NCC), Telecom-ISAC, and the ISP-ISAC (when chartered). Formal membership and participation will enhance the receipt of timely threat information and will provide a forum for response and coordination. Membership will also afford access to proprietary threat and vulnerability information (under NDA) that may precede public release of similar data.

TBD

document.xls

of 107

NumberTitle

Reference



6-6-8067Evidence Collection Procedures

IETF RFC3227, www.cybercrime.gov

NO, SP

Develop a set of guidelines detailing evidence collection and preservation procedures. Procedures should be approved by management/legal counsel and should be tested and trained. Organizations unable to develop a forensic computing capability should establish a relationship with a trusted 3rd party that possesses a forensic computing capability. Network Administrators should be trained on basic evidence recognition and preservation and should understand the protocol for requesting forensic services.

document.xls

of 107

NumberTitle

Reference



6-6-8068Incident Response Communications Plan

NO, SP

Develop and practice a Communications Plan as part of the broader Incident Response Plan. The communications plan should identify key players and include as a minimum - contact names, business telephone numbers, home tel. numbers, pager numbers, fax numbers, cell phone numbers, home addresses, internet addresses, permanent bridge numbers, etc. Calling trees should be developed prior to an event/incident happening where necessary. The plan should also include alternate communications channels such as alpha pagers, internet, satellite phones, VOIP, private lines, blackberries, etc. The value of any alternate communications method needs to be balanced against the security and information loss risks introduced. Communication to trusted appropriate outside entities (i.e., Telecom-ISAC) should be considered in developing the plan.

TBD

NRIC V BP 5-561, 5-585, 5-598, 5-609

document.xls

of 107

NumberTitle

Reference



6-6-8069Monitoring Requests

6-6-8031NO, SP

Network operators should identify a POC for handling requests for the installation of lawfully approved intercept devices. Once a request is reviewed and validated, the primary POC for law enforcement support should serve to coordinate the installation of any monitoring device with the appropriate legal and technical staffs. Larger carriers should consider pre-planning their level of support possibly to the point of provisioning circuits and equipment that can support both corporate and law enforcement monitoring requirements.

TBD

document.xls

of 107

NumberTitle

Reference



6-6-8070Security Reporting Contacts

All

Activities should support the email IDs listed in rfc 2142 “MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS.” These common e-mail Ids promote trouble reporting and information exchange in the Internet. Contact information should be prominently displayed on a public facing web site.

TBD

document.xls

of 107

NumberTitle

Reference



6-6-8071Threat Awareness

6-6-8034NO, SP

Subscribe to vendor patch/security mailing lists. Keep up with new vulnerabilities, viruses, and other security flaws relevant to systems deployed on the network.

TBD, List of example sources of information.

document.xls

of 107

NumberTitle

Reference



6-6-8072IDS Maintenance

NO, SP

IDS: Update IDS signatures regularly to detect current vulnerabilities. Where practical, consider deploying complementary IDS technologies (I.e., host and network, pattern matching and anomaly detection)

TBD

document.xls

of 107

NumberTitle

Reference



6-6-8073IDS Deployment

NO, SP

Intrusion Detection Systems should be deployed with an initial policy that reflects the universe of devices and services known to exist on the monitored network. Due to the ever evolving nature of threats, the IDS should be tested regularly and tuned to deliver optimum performance.

TBD

document.xls

of 107

NumberTitle

Reference



6-6-8074Denial of Service Attack - Target

NO, SP

Where possible networks should be designed to survive significant increases in both packet count and bandwidth utilization. Infrastructure supporting mission critical services should over-designed and must include network devices capable of filtering and/or rate limiting traffic. Network engineers must understand the capabilities of the devices and how to employ them to maximum effect. Where ever practical, mission critical systems should be deployed in clustered configuration allowing for load balancing of excess traffic and protected by a purpose built DoS/DDoS protection device. Operators of Critical Infrastructure should deploy DoS survivable hardware and software when ever possible.

TBD

document.xls

of 107

NumberTitle

Reference



6-6-8075Denial of Service Attack - Agent

NO, SP

Periodically scan hosts for signs of compromise. Where possible, monitor bandwidth utilization and traffic patterns for signs of anomalous behavior.

TBD

document.xls

of 107

NumberTitle

Reference



6-6-8076Denial of Service Attack - Vendor

ES

Vendors should develop or enhance DoS/DDoS survivability features for their product lines.

TBD

document.xls

of 107

NumberTitle

Reference



6-6-8077

6-6-8007NO, SP

Systems and Devices with Inherently Weak Authentication Methods

For legacy systems without adequate access control capabilities, access control lists (ACLs) should be used to restrict which machines can access the device and/or application. In order to provide granular authentication, a bastion host that logs user activities should be used to centralize access to such devices and applications, where feasible. In the long term, the vendor should be engaged to correct the issue, either by allowing the built in method to be changed periodically, or by allowing the user to add complementary authentication means that they control, hence creating a two-factor authentication.Where authentication methods must be shared, create an enforceable authentication method policy that addresses the periodic changing of the characteristics of the authentication method, and the dissemination of the method based on the principle of least privilege.If the authentication methods are shared, policy to implement least privilege access and periodic authentication characterisitc change should be developed and implemented. Consider replacement of device at end of life, especially if the device is protecting key equipment. Implement a periodic audit program to verify policy compliance.Garfinkel, Simson, and Gene Spafford. “Users and Passwords”. Practical Unix & Internet Security, 2nd ed. Sebastopol, CA: O’Reilly and Associates, Inc. 1996. 49-69King, Christopher M., Curtis E. Dalton, and T. Ertem Osmanoglu. “Applying Policies to Derive the Requirements”. Security Architecture, Design, Deployment & Operations. Berkley, CA: The McGraw-Hill Companies. 2001. 67-110National Institute of Standards and Technology. “User Account Management”. Generally Accepted Principles and Practices for Securing Information Technology Systems. September 1996

document.xls

of 107

NumberTitle

Reference



6-6-8078

All

Protect User Ids and Passwords During Network Transmission

Where practical, do not send user ids and passwords in the clear, and do not send passwords and user ids in the same message/packet.

US Government and National Security Telecommunications Advisory Committee (NSTAC) ISP Network Operations Working Group. “Short Term Recommendations”. Report of the ISP Working Group for Network Operations/Administration. May 1, 2002

document.xls

of 107

NumberTitle

Reference



6-6-8079Use Strong Passwords

All

Create an enforceable policy requiring the use of passwords when they can be used. Where feasible, use strong passwords. To assure compliance, perform regular audits of passwords on all systems.

Garfinkel, Simson, and Gene Spafford. “Users and Passwords”. Practical Unix & Internet Security, 2nd ed. Sebastopol, CA: O’Reilly and Associates, Inc. 1996. 49-69US Government and National Security Telecommunications Advisory Committee (NSTAC) ISP Network Operations Working Group. “Short Term Recommendations”. Report of the ISP Working Group for Network Operations/Administration. May 1, 2002

document.xls

of 107

NumberTitle

Reference



6-6-8080Change Passwords on a Timely Basis

All

Passwords should be changed on a periodic basis. The frequency should depend on the system's security needs. Perform periodic audits on all passwords, including priviliged passwords, on all systems and network devices. If available, activate features across the user base which force password changes on a periodic basis.

Garfinkel, Simson, and Gene Spafford. “Users and Passwords”. Practical Unix & Internet Security, 2nd ed. Sebastopol, CA: O’Reilly and Associates, Inc. 1996. 49-69US Government and National Security Telecommunications Advisory Committee (NSTAC) ISP Network Operations Working Group. “Short Term Recommendations”. Report of the ISP Working Group for Network Operations/Administration. May 1, 2002

document.xls

of 107

NumberTitle

Reference



6-6-8081Protect Authentication Methods

All

An enforceable password policy should be developed, requiring users to protect the passwords they are given or create. The policy needs to be enhanced through a security awareness program, which provides recurring education on the use and protection of passwords.

In addition, a regular physical audit of the workspaces and data centers should be conducted in order to identify areas where the policy is not being followed. Violations found during these audits should be dealt with under the corrective action process established by the organization.

Where passwords are not being properly protected, those systems or devices affected should have their passwords changed. If this is critical infrastructure, consider implementing two-factor authentication. If there is a clear violation of the policy, it should be dealt with through the corrective action process.

Garfinkel, Simson, and Gene Spafford. “Users and Passwords”. Practical Unix & Internet Security, 2nd ed. Sebastopol, CA: O’Reilly and Associates, Inc. 1996. 49-69US Government and National Security Telecommunications Advisory Committee (NSTAC) Network Security Information Exchange (NSIE). “Administration of Static Passwords and User Ids”. Operations, Administration, Maintenance, & Provisioning (OAM&P) Security Requirements for Public Telecommunications Network. Draft 2.0, August 2002

document.xls

of 107

NumberTitle

Reference



6-6-8082Properly Handle Two-Factor Authentication

All

Develop an enforceable password policy, requiring users to protect the device portion of the two-factor authentication.

If it is discovered through an audit that any element of a two-factor authentication process is not properly handled by users, those users affected should have changes made to their authentication (change passwords, re-set token, revoke certificate and issue a new one, etc.). Through a security awareness program, users should receive training on proper use of two-factor authentication, and should sign off verifying they received the training. In addition, a regular physical audit of the workspaces should be conducted in order to identify areas where the policy is not being followed. Violations found during these audits should be dealt with under the corrective action process established by the organization.

Use digital certificates as the "what you have" part in a two-factor authentication process that includes a "what you know" such as passwords or a PIN.

King, Christopher M., Curtis E. Dalton, and T. Ertem Osmanoglu. “Security Infrastructure Design Principles”. Security Architecture, Design, Deployment & Operations. Berkley, CA: The McGraw-Hill Companies. 2001. 111-140Nichols, Randall K., Daniel J. Ryan, Julie J. C. H. Ryan. "Digital Signatures and Certification Authorities - Technology, Policy, and Legal Issues". Defending Your Digital Assets Against Hackers, Crackers, Spies and Thieves. New York, NY. The McGraw-Hill Companies. 2000. 263-294McClure, Stuart, Joel Scambray, George Kurtz. "Dial-Up, PBX, Voicemail, and VPN Hacking". Hacking Exposed, Network Security Secrets and Solutions, 3rd Edition. Berkley, CA. The McGraw-Hill Companies. 2001. 393-440

document.xls

of 107

NumberTitle

Reference



6-6-8083Protect Directory Services

All

Directory Services must be protected from unauthorized access, and must be backed-up and securely stored in case they need to be restored.Filter access to the TCP and/or UDP ports serving the database at the network border. Use strong authentication for those requiring access.Prevent users from viewing all directory names down a directory tree. All directory names in a directory tree should not be seen by those users that do not have a need to access files at that directory level. The user should not have the option of exploring directories throughout the system in order to get clues of the type of information that is stored within those directories. Set permissions on directories so that users can have access down a directory tree without seeing the name of unauthorized directories. The higher up a directory hierarchy a user goes, the closer the user is to system related directories.Build a backup system in the event of loss of the primary system. Document and test procedures for backup and restoral of the directory.

Garfinkel, Simson, and Gene Spafford. “Users, Groups, and the Superuser”. Practical Unix & Internet Security, 2nd ed. Sebastopol, CA: O’Reilly and Associates, Inc. 1996. 71-137King, Christopher M., Curtis E. Dalton, and T. Ertem Osmanoglu. “Platform Hardening”. Security Architecture, Design, Deployment & Operations. Berkley, CA: The McGraw-Hill Companies. 2001. 257-284National Institute of Standards and Technology. “Secure Authentication Data as it is Entered”. Generally Accepted Principles and Practices for Securing Information Technology Systems. September 1996McClure, Stuart, Joel Scambray, George Kurtz. "Enumeration". Hacking Exposed, Network Security Secrets and Solutions, 3rd Edition. Berkley, CA. The McGraw-Hill Companies. 2001. 63-112

document.xls

of 107

NumberTitle

Reference



6-6-8084

All

Create Trusted PKI Infrastructure When Using Generally Available PKI Solutions

When using digital certificates, create a valid, trusted PKI infrastructure, using a root certificate from a recognized CA. Assure your devices and applications only accept certificates that were created from a valid PKI infrastructure. Configure your Certificate Authority to protect it from denial of service attacks.

Nichols, Randall K., Daniel J. Ryan, Julie J. C. H. Ryan. "Digital Signatures and Certification Authorities - Technology, Policy, and Legal Issues". Defending Your Digital Assets Against Hackers, Crackers, Spies and Thieves. New York, NY. The McGraw-Hill Companies. 2000. 263-294

document.xls

of 107

NumberTitle

Reference



6-6-8085Limit Validity Period of Digital Certificates

All

Certificates should have a limited period of validity, dependent upon the risk to the system, and the value of the asset. Consider the use of products that support a central revocation list to revoke certificates that are known or suspected of having been compromised.

If there are existing certificates with unlimited validity periods, and it is imprctical to replace certificates, consider using passwords (in effect creating two-factor authentication) that are required to be changed on a periodic basis.

McClure, Stuart, Joel Scambray, George Kurtz. "Dial-Up, PBX, Voicemail, and VPN Hacking". Hacking Exposed, Network Security Secrets and Solutions, 3rd Edition. Berkley, CA. The McGraw-Hill Companies. 2001. 393-440

document.xls

of 107

NumberTitle

Reference



6-6-8086Define User Access Requirements and Levels

All

Based on the principles of least access (the minimum access needed to perform the job) and separation of duties (certain users perform certain tasks), develop procedures with system stakeholders to clearly determine which users require access to a device or application, and use these to develop criteria for determining who can be authorized to access a device. Create tiered access privileges for those who receive authorization.

Garfinkel, Simson, and Gene Spafford. “Personnel Security”. Practical Unix & Internet Security, 2nd ed. Sebastopol, CA: O’Reilly and Associates, Inc. 1996. 389-395King, Christopher M., Curtis E. Dalton, and T. Ertem Osmanoglu. “Applying Policies to Derive the Requirements”. Security Architecture, Design, Deployment & Operations. Berkley, CA: The McGraw-Hill Companies. 2001. 67-110National Institute of Standards and Technology. “Access Control Mechanisms, Access Control Lists (ACLs)”. Generally Accepted Principles and Practices for Securing Information Technology Systems. September 1996Information Security Forum. “Access Control Policies”. The Forum’s Standard of Good Practice, The Standard for Information Security. November 2000

document.xls

of 107

NumberTitle

Reference



6-6-8087Use Time-Specific Access Restrictions

NO, SP

Restrict access to specific time periods (such as time of day, maintenance windows, outside critical times) for critical systems (systems that cannot be accessed outside of specified maintenance windows due to the impact on the business). Assure that all system clocks are synchronized (NTP).

Nichols, Randall K., Daniel J. Ryan, Julie J. C. H. Ryan. "Access Controls - Two Views". Defending Your Digital Assets Against Hackers, Crackers, Spies and Thieves. New York, NY. The McGraw-Hill Companies. 2000. 242-261

document.xls

of 107

NumberTitle

Reference



6-6-8088Develop Regular Access Audit Procedures

NO, SP

An independent group (outside of the administrators of the devices) should perform regular, management, and ad-hoc reviews of the audit database to determine who is gaining access and to which devices they are accessing.

The same independent group should perform a random "spot check" audit of the database to determine if there are any discrepancies from the regular audit.

As part of a regular security process, perform access audit reviews on all devices and systems. Take steps to verify and remove unauthorized users as they are found. Keep management updated on the findings of the audits.

When using an outside firm to conduct an audit, it is advisable to perform a secondary audit to confirm the findings of the outside firm.

Information Security Forum. “Security Audit/Review”. The Forum’s Standard of Good Practice, The Standard for Information Security. November 2000

document.xls

of 107

NumberTitle

Reference



6-6-8089

NO, SP

Set Authentication and Authorization Levels Commensurate to what is being protected

Along with the system owners, perform a risk assessment of all systems within your domain, and classify them by the value they have to the company, and the impact to the company if they are compromised or lost.

Based on the risk assessment, assign the appropriate controls to protect the system.

Nichols, Randall K., Daniel J. Ryan, Julie J. C. H. Ryan. "Access Controls - Two Views". Defending Your Digital Assets Against Hackers, Crackers, Spies and Thieves. New York, NY. The McGraw-Hill Companies. 2000. 242-261

document.xls

of 107

NumberTitle

Reference



6-6-8090Restrict Use of Dynamic Port Allocation Protocols

NO, SP

Dynamic port allocation protocols such as Remote Procedure Calls (RPC) and some classes of Voice-over-IP protocols (among others) should be restricted from usage, especially on mission critical assets, to prevent host vulnerabilities to code execution. Dynamic port allocation protocols should not be exposed to the internet. If used, Such protocols should be protected via a dynamic port knowledgeable filtering firewall or other similar network protection methodology.

document.xls

of 107

NumberTitle

Reference



6-6-8091Cached Encryption Keys

NO, SP

Flush all security material from system or application cache after use such as cryptographic keys, passwords, certificates, etc.

document.xls

of 107

NumberTitle

Reference



6-6-8092Adopt and enforce Acceptable Use Policy

NO, SP

The Network/Service provider should adopt a policy whereby misuse of the network would lead to a termination of services (e.g., each observed incident would constitute one of, say, three strikes). This Acceptable Use Policy should be posted and advertised on a publicly accessible web site. The AUP should include what behaviors and traffic characteristics the network/service provider will enforce with its customers.

IETF rfc3013 section 3 and NANOG ISP Resources(www.nanog.org/isp.html)

See also NRIC V BP 5-533 and NRIC VI BP 6-6-5145

document.xls

of 107

NumberTitle

Reference



6-6-8093Validate source addresses

SP

Service providers should validate the source address of all traffic sent from the customer for which they provide Internet access service and block any traffic that does not comply with expected source addresses. Service Providers typically assign customers addresses from their own address space, or if the customer has their own address space, the service provider can ask for these address ranges at provisioning. (Network operators may not be able to comply with this practice on links to upstream/downstream providers or peering links, since the valid source address space is not known).

IETF rfc3013 sections 4.3 and 4.4 and NANOG ISP Resources. www.IATF.net

document.xls

of 107

NumberTitle

Reference



6-6-8094Strong Encryption for Customer Clients

SP

Service Providers should implement customer client software that uses the strongest permissible encryption appropriate to the asset being protected.

www.securityforum.org; See also NRIC VI BP 6-6-5162

http://www.securityforum.org/

document.xls

of 107

NumberTitle

Reference



6-6-8095

NO, SP

Implement methods to limit undue consumption of system resources

Where technology allows, establish limiters to prevent undue consumption of system resources, e.g., system memory, disk space, CPU consumption, network bandwidth, in order to prevent degradation or disruption of performance of services.

document.xls

of 107

NumberTitle

Reference



6-6-8096Users should employ protective measures

NO, SP

Providers should educate service customers on the importance of, and the methods for, installing and using a suite of protective measures, e.g., strong passwords, anti-virus software, firewalls, IDS, encryption, and update as available.

www.stonybrook.edu/nyssecure www.fedcirc.gov/homeusers/HomeComputerSecurity/ Industry standard tools, e.g., LC4 See also NRIC VI BP 6-6-5165

document.xls

of 107

NumberTitle

Reference



6-6-8097Management of information dissemination

All

Ensure staff training on security awareness and ethics policies. Audit/log user events. Create an enforceable policy clearly defining who can disseminate information, and what controls are in place for the dissemination of such information. In addition, implement a consistent and clear security awareness program, where users are educated and re-educated on the awareness of and techniques to counter such issues as social engineering .

Octave Catalog of Practices, Version 2.0,CMU/SEI-2001-TR-20 (http://www.cert.org/archive/pdf/01tr020.pdf) Practice OP3.1.1& OP3.2.1; NIST Special Pub 800-12. King, Christopher M., Curtis E. Dalton, and T. Ertem Osmanoglu. “Validation and Maturity”. Security Architecture, Design, Deployment & Operations. Berkley, CA: The McGraw-Hill Companies. 2001. 443-470McClure, Stuart, Joel Scambray, George Kurtz. "Advanced Techniques". Hacking Exposed, Network Security Secrets and Solutions, 3rd Edition. Berkley, CA. The McGraw-Hill Companies. 2001. 553-590Nichols, Randall K., Daniel J. Ryan, Julie J. C. H. Ryan. "Risk Management and Architecture of Information Security (INFOSEC)". Defending Your Digital Assets Against Hackers, Crackers, Spies and Thieves. New York, NY. The McGraw-Hill Companies. 2000. 69-90. See also the following NRIC VI BPs: 6-6-5019, 6-6-5024, 6-6-5067, 6-6-5109, and 6-6-5285.

document.xls

of 107

NumberTitle

Reference



6-6-8098Management of removal of access privileges

All

Develop procedures with Human Resources (HR) and other organizations for prompt notification of a staff member's status change, and the changing or removal of access privileges. Develop HR policies and management controls for restricting access of staff members who are disciplined, have marginal performance, notified of adverse personnel actions, or exhibit signs of stress or abnormal behavior. Log and record employee patterns regarding sensitive systems or restricted areas to detect abnormalities in individual actions. Develop policy/procedures to track employee access by system and delete or restrict ID's/authorization.

Octave Catalog of Practices, Version 2.0,CMU/SEI-2001-TR-20 (http://www.cert.org/archive/pdf/01tr020.pdf) Practice OP1.3.1-OP1.3.2, OP3.2.1-OP3.3 and OP3.1.1-Op3.1.3; NIST Special Pub 800-26; OMB Circular A-130 Appendix III. US Government and National Security Telecommunications Advisory Committee (NSTAC) Network Security Information Exchange (NSIE). “Administration of Static Passwords and User Ids”. Operations, Administration, Maintenance, & Provisioning (OAM&P) Security Requirements for Public Telecommunications Network. Draft 2.0, August 2002. See NRIC VI BPs 6-6-5015 and 6-6-5016. See also Forensics Best Practice.

document.xls

of 107

NumberTitle

Reference



6-6-8099Management of hiring procedures

All

Perform background checks consistent with the sensitivity of the staff member's responsibilities to verify employment history, education, experience, and certification.

See Forensics Best Practices.

See also NRIC VI BPs 6-6-5033, 6-6-5034 and 6-6-5065.

document.xls

of 107

NumberTitle

Reference



6-6-8100Information Security training for staff

All

Establish security training programs and requirements for ensuring staff knowledge and compliance. Ensure technical staff certifications and training on hardware and software technologies remain up-to-date. Provide procedures and training to employees to report incidents, weaknesses, or suspicious events. Test and revise training/procedures as required. Employers should encourage staff to become professionally certified in information systems and cyberspace security.

Octave Catalog of Practices, Version 2.0,CMU/SEI-2001-TR-20 (http://www.cert.org/archive/pdf/01tr020.pdf) Practice SP1.2 & SP1.3. See also NRIC VI BPs 6-6-5176 and 6-6-5096.

document.xls

of 107

NumberTitle

Reference



6-6-8101Document and verify all security operational procedures

NO, SP

Ensure all security operational procedures, system processes, and security controls are well documented, and that documentation is up to date and accessible by staff. Perform gap analysis/audit of security operational procedures. Using results of analysis or audit, determine which procedures, processes, or controls need to be updated and documented.

Octave Catalog of Practices, Version 2.0,CMU/SEI-2001-TR-20 (http://www.cert.org/archive/pdf/01tr020.pdf) Practice SP1.2 & SP1.3. See also NRIC VI BPs 6-6-5025 and 6-6-5067.

document.xls

of 107

NumberTitle

Reference



6-6-8102

All

Discourage use of personal equipment to remotely access corporate resources

Discourage the use of personal equipment for telecommuting, virtual office, remote administration, etc.

document.xls

of 107

NumberTitle

Reference



6-6-8103

6-6-8548NO, SP

Protect Network/Management Infrastructure from Software Viruses

Network Operators and Service Providers should deploy Virus Protection tools and/or tools to detect unexpected changes to file systems on Network Elements and Management Infrastructure systems. Establish processes to keep virus signatures and/or cryptographic hashes of the file system current, and procedures for reacting to an infection or compromise. Service providers may choose to offer virus protection as a value-added service to their customers as part of a service offering.

www.cert.org/security-improvement/practices/p072.html, www.cert.org/security-improvement/practices/p096.html

document.xls

of 107

NumberTitle

Reference



6-6-8104Proper Wireless LAN/MAN Configurations

Where applicable, Secure Wireless WAN/LAN networks sufficiently to insure that a) monitoring of RF signals cannot lead to the obtaining of proprietary network operations information customer traffic and that b) Network access is credibly authenticated.

document.xls

of 107

NumberTitle

Reference



6-6-8105Protection of Cellular User Voice Traffic

Network Operator, SP

Network Operators should incorporate cellular voice encryption services and ensure that such encryption services are enabled for end users. (Voice encryption services depend on the wireless technology used, and are standards based).

Cellular Standards: GSM, GPRS, PCS2000, CDMA, 1XRTT, UMTS.

document.xls

of 107

NumberTitle

Reference



6-6-8106

6-6-8009, 6-P-5018Network Operator, SP

Protect 3G Cellular from Cybersecurity Vulnerabilities

Employ operating system hardening and up to date security patches for all accessible wireless servers and wireless clients. Employ strong end user authentication for wireless IP sessions. Employ logging of all wireless IP sessions to ensure traceability of user actions. In particular vulnerable network and personal data in cellular clients must be protected is handset is stolen. Apply good IP hygenie principles.

IPSec. Telcordia GR-815. Cellular Standards: GSM, PCS2000, CDMA, 1XRTT, UMTS, etc.