1 / 24

Enhancing Protocol Security: Recommendations for Standards Bodies

Explore the fundamentals, types, and examples of security vulnerabilities in protocols, with expert recommendations for standards bodies. Address immediate actions for improved protocol security. Learn from past errors and vulnerabilities to safeguard against threats. This thesis covers key aspects of security risks, threats, and vulnerabilities in protocols, highlighting lessons learned and essential security measures. The material presented in this workshop is crucial for understanding and mitigating protocol vulnerabilities effectively to uphold system and data security standards.

fredferguson
Download Presentation

Enhancing Protocol Security: Recommendations for Standards Bodies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security Vulnerabilities in Protocols Dr. Greg Shannon Security Standards Manager Lucent Technologies

  2. Thesis • Standards bodies have a unique ability and responsibility to address security vulnerabilities in protocols. • There are immediate and relatively simple actions standards bodies can take to improve the security of all protocols currently being standardized. ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  3. Outline • Security Vulnerability Basics • Types & Examples of Security Vulnerabilities in Protocols • Recommendations for Standards Bodies ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  4. What Is a Security Vulnerability? • A security vulnerability is:A flaw or weakness in a system’s design, implementation or operation that could be exploited to violate the system’s security (RFC 2828). • A security vulnerability is not:a risk, a threat, or an attack. ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  5. Vulnerabilities, Threats and Risks • A security vulnerability combined with a security threat creates a security risk. Vulnerability + Threat  Risk • Example: Overflow Bug + Hacker Knowledge & Tools & Access  Risk of Webserver Attack ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  6. The High-Impact of Protocol Security Vulnerabilities • Threats change, but security vulnerabilities exist throughout the life of a protocol. • With standardized protocols, protocol-based security risks can be very large – global in scale. ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  7. Outline • Security Vulnerability Basics • Types & Examples of Security Vulnerabilities in Protocols • Recommendations for Standards Bodies ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  8. Threat Model New threats from those originally considered. SS7 Design & Specification Errors make the protocol inherently vulnerable. BGP Implementations Errors create unexpected vulnerabilities. SNMP, ASN.1, BER Usage & Configuration Improper usage opens or magnifies security vulnerabilities. 802.11b, BGP Protocol Security Vulnerability Types ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  9. A Simple Protocol Vulnerability Model Security Vulnerabilities Security Threats Security Risks • Hackers • Insiders • Terrorists • Vandals • Organized crime • State sponsored • Data loss • Data corruption • Privacy loss • Fraud • Down-time • Public loss of confidence • Confusion + + + +     Threat Model Design & Specification Implementation Operations & Configuration ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  10. New Threat ModelSS7 • Old Model • Designed for a closed network of well-known service providers of fixed services. • No interface to IP-based networks. • Software extensively tested. • New Model • Rogue providers may be malicious. • Software and protocols for new services may be poorly tested or a poor fit with SS7. • Network convergence puts IP interfaces on SS7-capable elements. ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  11. Design & Specification ErrorsBGP (RFC1771) • Design implies an ASN of 0 is illegal. • Specification allows 0 (and 65535). • What happens when an ASN of 0 is advertised? • Different implementations probably handle this differently. • Such protocol inconsistencies are at the root of many attacks on specific implementations. ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  12. Implementation ErrorsSNMP, ASN.1, BER • SNMP security depends on proper parsing of ASN.1 and BER. • Some ASN.1 and BER parsers are not robust and make mistakes or allow buffer overflows. • Limited specifics on SNMP error handling lead to unpredictable behaviors across implementations. ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  13. Usage or Configuration Errors802.11b, BGP • In 802.11b, a stream cipher is misused so that there is very little privacy protection. • 802.11b operators often turn off even the basic security features. • BGP operators turn off the authentication mechanisms. Errors and rogue messages can then easily propagate through core networks. ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  14. Lessons Learned • Standards bodies have accepted protocols with serious vulnerabilities. • Security depends on the whole protocol. • Protocol vulnerabilities last a long time. • Threats change over time. • Implicit assumptions are often violated. • Application layer protocols also have security vulnerabilities. • Inattention to security issues creates vulnerable protocols. ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  15. Outline • Security Vulnerability Basics • Types & Examples of Security Vulnerabilities in Protocols • Recommendations for Standards Bodies ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  16. Recommendationsfor Discussion • Openly discuss with security experts the security algorithms and mechanisms used in protocols. • Establish simple but effective security guidelines for protocol authors. • Initiate a systematic root-cause study of protocol vulnerabilities. ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  17. Open Security Discussions • The security community has learned that two elements improve security: • Exposure of the details to a wide audience • Time to analyze and discuss the details. • Secrecy does not improve security. • Standards bodies should promote: • Open discussion of security algorithms and mechanisms. • Engagement with security experts on every standard. ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  18. Security Guidelines for Protocol Authors • Early attention to security is best. • Guidelines provide a way to quickly improve the process. • Standards bodies should issue guidelines in four areas for all protocol authors: • Specify Threat Models • Protocol Designs & Specifications • Secure Implementation Issues • Operational & Configuration Issues ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  19. Example ProtocolGuidelines I • Threat Model • What is the initial model? • What are the security assumptions? • What is the trust model? • Design & Specification • Address unexpected messages. • Anticipate DoS attacks. • Limit data in debugging messages. • Fully specify state machines ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  20. Example ProtocolGuidelines II • Implementation • Fully specify error handling for malformed or unexpected messages. • Separate processing for signaling and traffic when possible. • Operations & Configuration • How robust is the protocol when all security features are turned off? • Provide guidelines to vendors and operators for new protocol versions. ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  21. Root-Cause Analysis • Incident analysis usually focuses on threat reduction and prosecution. • The root cause(s) of an enabling vulnerability are usually not found. • Standards bodies should: • Systematically analyze the root causes of serious protocol vulnerabilities. • Understand how their decisions and processes produce security vulnerabilities. ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  22. Summary • Security vulnerabilities in important protocols have created serious security risks that were avoidable. • Standards bodies should: • Promote open security discussions. • Provide protocol security guidelines. • Identify root causes of vulnerabilities. ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  23. Contact InformationDr. Greg Shannon • Please contact me about: • Other work in this area • Further discussion of this material • Examples of protocol vulnerabilities • Email: Greg.Shannon@lucent.com • Phone: 1-614-860-4517 • Mail: 6100 East Broad Street, Columbus, Ohio, 43212, USA ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

  24. Acronyms & References 802.11b – IEEE Wireless Local Area Network Standard BGP – Border Gateway Protocol Version DoS - Denial of Service (attack) IETF – Internet Engineering Task Force IEEE - Institute of Electronic and Electrical Engineers IP – Internet Protocol MPLS – Multi-protocol Label Switching SNMP – Simple Network Management Protocol SS7 – Signaling System #7 IETF ID draft-rescorla-sec-cons-05.txt, Guidelines for Writing RFC Text on Security Considerations IETF RFC #2828, Internet Security Glossary Lorenz, Moore, Manes, Hale, Shenoi. “Securing SS7 Telecommunications Networks.” Proceedings of the 2001 IEEE Workshop on Information Assurance and Security. Sharp. Principles of Protocol Design. Prentice Hall, 1995. ITU-T Workshop on Security - Seoul(Korea), 13-14May 2002

More Related