210 likes | 216 Views
This summary provides key recommendations from the ISP Working Group on Internet vulnerabilities and discusses the need for proactive progress in addressing accountability, filtering, and BGP vulnerabilities.
E N D
ISP Working Group Internet VulnerabilitySummary & Discussion Avi Freedman Akamai Technologies
ISPWG: Background (1) • In Jan 2002, Dick Clarke called a meeting of industry and government to cover Internet vulnerabilities in the hope of starting a process that would lead to identification of vulnerabilities and that would lead to recommendations for the cyberdefense plan. • Clarke’s group works for/with both the National Security Council and the Homeland Defense groups.
ISPWG: Background (2) • From Feb-Apr, different groups formed and had teleconference and list discussions of the following issues: • BGP & DNS • Hardening the peering & router infrastructure • Network ops & management • Disaster recovery • Inter-provider coordination • Enforcement nad privacy • The process was shepherded by Marj Gilbert from Dick Clarke’s staff (the PCIPB) and by Marty Lindner from CERT.
ISPWG: Background (3) • The following assumptions were made: • Poor software quality is a problem that must be addressed separately (not everyone agrees that this can be easily dismissed) • Domestic vs. international issues are not easy to solve, so focus on domestic US first • Information sharing (vulnerabilities, network data, etc) need to be protected from FOIA/kept proprietary.
Key Recommendations (1) • Establish ISP best practices • Address accountability • Filtering • Access control and authentication • Change control • Personnel policies and procedures • Standardized training • Refer to NRIC & other processes
Key Recommendations (2) • Establish secure, real-time, crisis-available ISP/Vendor/Gov’t channels • Establish policy-based network management capabilities • Have a master study to analyze and identify single points of failure (buildings, logical infrastructure, fiber) domestically and internationally • Review law enforcement procedures; amend FOIA/anti-trust, and provide immunity to ISPs for emergency disclosures and data submission, and to allow govt and industry to exchange info • Create national Internet disaster management team
Personal Summary • The “barreling down the road” issues for providers to (finally) achieve proactive progress on are: • Address accountability • Filtering • BGP vulnerabilities • These are critical because there could be a move to regulate, legislate, or fund less than wise solutions.
Working Group Summaries • The following slides present VERY excerpted summaries of the groups’ reccomendations, mostly intended to cover the critical issues and provide flavor. • One key question is how the NANOG community becomes involved and sanity-checks. Unclear that IETF-ers are the right crowd for consensus – perhaps that concept needs to find tha NANOG crowd and then interact with the gov’t.
BGP & DNS WG (1) • Leader – Steve Blumenthal, Genuity • Recommend (DNS): • Best practices for DNS (not all on one /24, etc) • Source address (packet) + ingress (route) filtering to prevent spoofing • DNS server software, network, and geo diversity • Finishing and implementing DNSSEC (+funding)
BGP & DNS WG (2) • Recommend (ctd): • Best practices (max-prefix, dampening, etc) • Explore IPSEC to sign & auth BGP routing data • Complete Secure BGP & test in an operational environment • Investigate feasibility of egress route filtering at peering points • Design routers to better withstand DoS attacks • Greater diversity of peering interconnection • MD5 on BGP4 connections (help with RST attacks) • Improve authentication of routing info
Hardening WG (1) • Leader - Avi Freedman, Akamai • Recommendations (short-term): • Education & training on default initial configs • Security at common facilities • Filtering access to management & control planes • Out-of-band access • Investigate interconnection infrastructure diversity & options (NOT regulation) • Login authentication • Investigate insider-threat issues
Hardening WG (2) • Recommendations (long-term): • Router protection: Architecture & Configuration • Continued investigation of diversity of interconnection infrastructure • Continued work on better OOB deployment • Awareness of data center devices & overlay networks • Criticality of solving source address filtering • Continued work on best practices
Net Ops WG (1) • Leader – Art Deacon, AT&T • Recommendations (short-term): • Network management should use one-time keys, crypto sums on software upgrades, strong AAA methods, avoid static passwords, and use encrypted management traffic with strong authentication • Repetitive tasks should be automated and APIs such as SNMP/XML for configuration should be available • Protection of management flows via ACLs etc; logged and auditable management traffic/sessions • Documented network access policy
Net Ops WG (2) • Recommendations (long-term): • Continue work on policy-based network management capabilities • IETF should work on requirement and standards for interoperability • Address accountability is essential • Migrate from SNMPv1 to SNMPv3 • Need to improve incident disclosure to help operators and vendors
Disaster Recovery WG (1) • Leader – Surprise surprise (Sean Donelan, SBC) • Recommendations: • Set criteria for gov’t invovement • Work on simulation & modeling • Deal with vulnerabilities proactively • Perform vulnerability assessments • Work with NSTAC/NRIC • Share information • Define and practice the “Plan”
Disaster Recovery WG (2) • Recommendations (ctd): • Define skill sets needed • Create “contact list” and methods • Establish 24x7 Internet emergency management office • Get ISPs involved with emergency preparedness • Funding is needed • Undecided issues: • Priority communications for key individuals • Restoration priorities • Load shedding during periods of capacity shortages
Coordination WG (1) • Leader – Kelly Cooper, Genuity • Recommendations: • Major: Establish and standardize communication channels between Internet-supporting sectors • ISPs: Inter-ISP real-time communications, contact info, best practices forum, collect/maintain info (?ISP-ISAC, ?NCC-ISAC, ?NIST) • Gov’t: Single focal point, contact info across ISPs and vendors, long-term plans, info-sharing network, continuity of operations (?IRC, ?NCC/NCS)
Coordination WG (2) • Recommendations (ctd): • Vendors (equipment): Single forum, operational best practices, reporting standards, common feature sets, timely communicaftions, training (NCC-ISAC, IT-ISAC) • Independents • Disseminate best practices, provide advance notice of issues, pass vulnerability info, establish trusted ISP and “correct sector” contacts
Enforcement & Privacy WG (1) • Leader – John Ryan, AOL • Recommendations: • Meaningful info sharing is critical for dealing with any widespread threats, but legal impediments must be resolved: • FOIA & Sunshine Laws • Discovery provisions • Lack of immunity for emergency disclosures & voluntary surveillance under USA/Patriot Act • Statutory environments do not limit liability • Coordination may require central training, investigative unit, access to states of resources, and simulation and cyber gaming
Summary • A lot of government interest in Internet infrastructure vulnerabilities. • Awareness of BGP limitations and of issues with lack of filtering. • Please get involved and seek info/provide input. • It’s critical that we as a community address filtering (packet & route) and route authentication before solutions are imposed in some way (i.e. government requiring solution from all vendors). In particular, is there a lightweight in-addr based method that could be set up for describing authorized origin AS(s) for prefixes? Other lightweight solutions?
Personal Summary (Revisit) • Real IGP work done to prevent BGPOSPF leading to catastrophe would be a great step. • Having community support for assembling a ‘net-wide Origin-AS Prefix mapping database is key to any route/packet filtering work. Real progress here could help stave off a S-BGP “before its time” push. • NOT talking about SWIP-type info • NOR about IRR-type policy info? • Store in in-addr? • Something good enough to start is key.