Search
1098 matching practices
| Number | Best Practice |
|---|---|
| 13-8-8912 | Service Providers should make reasonable efforts to communicate with other operators and security software providers, by sending and/or receiving abuse reports via manual or automated methods. These efforts could include information such as implementation of "protective measures" such as reporting abuse (e.g., spam) via feedback loops (FBLs) using standard message formats such as Abuse Reporting Format (ARF). Where feasible, ISPs should engage in efforts with other industry participants and other members of the internet ecosystem toward the goal of implementing more robust, standardized information sharing in the area of botnet detection between private sector providers. |
| 13-8-8913 | Service Providers should maintain methods to detect likely bot/malware infection of customer equipment. Detection methods will vary widely due to a range of factors. Detection methods, tools, and processes may include but are not limited to: external feedback, observation of network conditions and traffic such as bandwidth and/or traffic pattern analysis, signatures, behavior techniques, and forensic monitoring of customers on a more detailed level. |
| 13-8-8914 | Service Providers should use a tiered approach to botnet detection that first applies behavioral characteristics of user traffic (cast a wide net), and then applies more granular techniques (e.g., signature detection) to traffic flagged as a potential problem. |
| 13-8-8915 | Service Providers should ensure that detection methods do not block legitimate traffic in the course of conducting botnet detection, and should instead employ detection methods which seek to be non-disruptive and transparent to their customers and their customers’ applications. |
| 13-8-8916 | Service Providers should ensure that bot detection and the corresponding notification to end users be timely, since such security problems are time-sensitive. If complex analysis is required and multiple confirmations are needed to confirm a bot is indeed present, then it is possible that the malware may cause some damage, to either the infected host or remotely targeted system (beyond the damage of the initial infection) before it can be stopped. Thus, an ISP must balance a desire to definitively confirm a malware infection, which may take an extended period of time, with the ability to predict the strong likelihood of a malware infection in a very short period of time. This 'definitive-vs.-likely' challenge is difficult and, when in doubt, ISPs should err on the side of caution by communicating a likely malware infection while taking reasonable steps to avoid false notifications. |
| 13-8-8917 | Service Providers should develop and maintain critical notification methods to communicate with their customers that their computer and/or network has likely been infected with malware. This should include a range of options in order to accommodate a diverse group of customers and network technologies. Once an ISP has detected a likely end user security problem, steps should be undertaken to inform the Internet user that they may have a security problem. An ISP should decide the most appropriate method or methods for providing notification to their customers or internet users, and should use additional methods if the chosen method is not effective. The range of notification options may vary by the severity and/or criticality of the problem. Examples of different notification methods may include but are not limited to: email, telephone call, postal mail, instant messaging (IM), short messaging service (SMS), and web browser notification. |
| 13-8-8918 | Service Providers should ensure that botnet notifications to subscribers convey critical service information rather than convey advertising of new services or other offers. |
| 13-8-8919 | Service Providers should maintain an awareness of cyber security threat levels and, when feasible, cooperate with other organizations during significant cyber incidents, helping to gather and analyze information to characterize the attack, offer mitigation techniques, and take action to deter or defend against cyber attacks as authorized by applicable law and policy. |
| 13-8-8920 | Service Providers should consider temporarily quarantining a subscriber account or device if a compromised device is detected on the subscribers’ network and the network device is actively transmitting malicious traffic. Such quarantining should normally occur only after multiple attempts to notify the customer of the problem (using varied methods) have not yielded resolution. In the event of a severe attack or where an infected host poses a significant present danger to the healthy operation of the network, then immediate quarantine may be appropriate. In any quarantine situation and depending on the severity of the attack or danger, the Service Provider should seek to be responsive to the needs of the customer to regain access to the network. Where feasible, the Service Provider may quarantine the attack or malicious traffic and leave the rest unaffected. |
| 13-8-8921 | Service Providers should either directly or indirectly, provide a web site to assist customers with malware remediation. Remediation of malware on a host means to remove, disable, or otherwise render a malicious bot harmless. For example, this may include but is not limited to providing a special web site with security-oriented content that is dedicated for this purpose, or suggesting a relevant and trusted third-party web site. This should be a security-oriented web site to which a user with a bot infection can be directed to for remediation. This security web site should clearly explain what malware is and the threats that it may pose. Where feasible, there should be a clear explanation of the steps that the user should take in order to attempt to clean their host, and there should be information on how users can strive to keep the host free of future infections. The security web site may also have a guided process that takes non-technical users through the remediation process, on an easily understood, step-by-step basis. The site may also provide recommendations concerning free as well as for-fee remediation services so that the user understands that they have a range of options, some of which can be followed at no cost. |
| 13-8-8922 | Service Providers should ensure that all such technical measures address customers’ privacy, and comply and be consistent with all applicable laws and corporate privacy policies to (a) detect compromised end-user devices, (b) notify end-users of the security issue, and (c) assist in addressing the security issue, may result in the collection of customer information (including possibly “personally identifiable information” and other sensitive information, as well as the content of customer communications). |
| 13-8-8923 | Service Providers should pursue a multi-prong strategy in designing technical measures for identification, notification, or other response to compromised end-user devices (“technical measures”), to protect the privacy of customers’ information, including but not limited to the following: a) ISPs should design technical measures to minimize the collection of customer information; b) In the event that customer information is determined to not be needed for the purpose of responding to security issues, the information should promptly be discarded; c) Any access to customer information collected as a result of technical measures should at all times be limited to those persons reasonably necessary to implement the botnet-response security program of the ISP, and such individuals’ access should only be permitted as needed to implement the security program; d) In the event that temporary retention of customer information is necessary to identify the source of a malware infection, to demonstrate to the user that malicious packets are originating from their broadband connection, or for other purposes directly related to the botnet-response security program, such information should not be retained longer than reasonably necessary to implement the security program (except to the extent that law enforcement investigating or prosecuting a security situation, using appropriate procedures, has requested that the information be retained); and e) The ISP’s privacy compliance officer, or another person not involved in the execution of the security program, should verify compliance by the security program with appropriate privacy practices. |
| 13-9-0400 | Network Operators, Service Providers, and Public Safety should establish measurements to monitor their network performance. |
| 13-9-0401 | Network Operators, Service Providers, and Public Safety should monitor their network to enable quick response to network issues. |
| 13-9-0402 | Network Operators, Service Providers and Public Safety should where appropriate, design networks (e.g., Time Division Multiplexing (TDM) or Internet Protocol (IP)) to minimize the impact of a single point of failure (SPOF). |
| 13-9-0403 | Network Operators, Service Providers, and Public Safety should communicate maintenance windows to appropriate entities so proper methods of procedures can be invoked. |
| 13-9-0405 | Network Operators, Service Providers, and Public Safety should periodically examine and review their networks to ensure that they meet the current design specifications. |
| 13-9-0406 | Network Operators, Service Providers and Public Safety should where appropriate, establish a process to ensure that spares inventory is kept current to at least a minimum acceptable release (e.g., hardware, firmware or software version). |
| 13-9-0412 | Network Operators, Service Providers and Public Safety should to enhance security, by default, disable ICMP (Internet Control Message Protocol) redirect messages and IP source routing. |
| 13-9-0414 | Network Operators, Service Providers, and Public Safety should establish plans for internal communications regarding maintenance activities and events that impact customers. |
Download matching Best Practices
Next results