Salsa Call Thu 29-Nov-2007

*Attending*
Chris Misra, U. Mass (chair)
Doug Pearson, Indiana
Joe St. Sauver, Internet2/U. Oregon
Mike Van Norman, UCLA
Ken Klingenstein, Internet2
Rodney Petersen, Educause
Renee Frost, Internet2
Chas DiFatta, CMU
Mark Poepping, CMU
Jack Suess, UMBC
Steve Olshansky, Internet2 (scribe)

*Discussion*

- FWNA Update
Continued discussion in the TNC area, not much progress to date. Guest issues are not on the front burner, most campuses have a solution of some kind and are not very motivated to work on this at the moment.

Q: What effect do trust fabrics have in this?
A: A loosely federated approach between regional campuses is often incorporated into system-wide solutions, but there haven't really been any drivers from gov't. agencies or InCommon. The U. California system is now looking at a federated wireless solution utilizing the UC-Trust federation.

Most of the solutions available allow configuration for what hosts unauthenticated guest users are able to access. Including multiple WAYFs in this may be a management issue, but probably not a big deal. Many systems dump guests into a dedicated VLAN with limited access to internal systems and primarily outside Internet access. If systems allow unregistered hosts to have full web access this would address some of the management issues.

Ultimately the practical solution likely lies in a mix of federated and non-federated approaches.

How important is guest system scanning (NAC)? This has been largely mitigated by the systems now available, and the trend now is to scan and confirm the posture all connected hosts instead just hosts upon first contact.

[AI] {All} update the effective practices wiki with issues around scanning and NAC, and shifting security landscapes around event handling

Q: How can we improve the sharing of Snort rules between campuses? REN-ISAC held a tech burst on Snort today, and this question arose. There is a fair bit of communication potential about this within the secure REN-ISAC community. Sharing known bad sites would be valuable if it could be shared in real time, or something close to it. Is there a BGP-based solution that would be effective?

As with spam BLs, the question arises of vetting contributed bad sites to ensure they should really be blocked. In practice the number of bad sites can be quite large, thus monitoring it can be problematic.

- DR Update
There was a well-attended meeting at Educause, but not much activity in the WG lately.

- CSI2 Update
Not much activity lately due to holiday conflicts...

- CAMP: Bridging Security and Identity Management
February 13-15, Tempe, AZ
http://www.educause.edu/camp081

Agenda is online, and this looks to be a great hybrid program and will likely be followed by others with a similar blend.

- JT/NetGuru
January 20-25, Honolulu
http://www.hawaii.edu/tip2008/

Tom Zeller (Indiana) is coordinating the NetGuru agenda with help from Mark. Discussions about the agenda and meeting planning are underway. There is not a separate JT registration for this meeting, it is being handled via the NetGuru list.

JT is open to suggestions for security topics. They are looking at having US-Cert and Team Cymru speakers. http://www.us-cert.gov/ http://www.cymru.com/

Vista network discovery and WinDNS network issues might interesting topics if we can get a Microsoft speaker.

- Repackaging discussion for new audiences (NITLE, NWACC - NorthWest Academic Computing Consortium, CLAC - Consortium of Liberal Arts Colleges, WICHE - Western Interstate Commission for Higher Education)
http://www.nitle.org/ http://www.nwacc.org/
http://www.liberalarts.org/
http://www.wiche.edu/

We are in the process of repackaging much of the IdM work for secondary audiences, and it would be useful to look at something similar in the security area. Some of this would be just outreach and education about existing resources like Effective Practices, but there may be room for more content focused on smaller schools. It may well be that the needs here call for a more geographic regional approach, but role and mission would still seem to be key elements. Many smaller schools don't typically attend meetings that require more than one day's drive.

- Top ten prioritized security items discussion
We have an opportunity to suggest themes to be presented to security researchers in future solicitations coming out of CISE. Discuss ideas via the list, and we can take this up at the next Salsa dinner at the I2MM in April... http://events.internet2.edu/2008/spring-mm/

- AP-less WEP Cracking
(ref Joe's mail to Salsa list 12-Nov)
Physical access to the AP is not necessary for a compromise, just access to a host that has connected to it in the past. This is a bigger vulnerability than people appreciate, very effective MITM attacks can be staged as a result. More than ever this reinforces the need for all organizations to stop using WEP anywhere, anytime. Bad encryption gives lay users a false sense of security, worse than none at all...

Note that the PCI DSS standard is promoting WPA but doesn't prohibit WEP. Specifically:

PCI DSS specification 1.1, section 2.1.1: "For wireless environments, change wireless vendor defaults, including but not limited to, wired equivalent privacy (WEP) keys, default service set identifier (SSID), passwords, and SNMP community strings. Disable SSID broadcasts. Enable WiFi protected access (WPA and WPA2) technology for encryption and authentication when WPA-capable."

PCI DSS specification 1.1, section 4.1.1: "For wireless networks transmitting cardholder data, encrypt the transmissions by using WiFi protected access (WPA or WPA2) technology, IPSEC VPN, or SSL/TLS. Never rely exclusively on wired equivalent privacy (WEP) to protect confidentiality and access to a wireless LAN. If WEP is used, do the following:
- Use with a minimum 104-bit encryption key and 24 bit-initialization value
- Use ONLY in conjunction with WiFi protected access (WPA or WPA2) technology, VPN, or SSL/TLS
- Rotate shared WEP keys quarterly (or automatically if the technology permits)
- Rotate shared WEP keys whenever there are changes in personnel with access to keys
- Restrict access based on media access code (MAC) address."

https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf

[AI] Joe will summarize this and send a note out to the Educause Security list. Next Call: 13-Dec-2007