PREFACE: Initially I'm focusing more on note-taking, and as time permits over the course of the day I will add in personal commentary, pictures, and other more blog-like characteristics. If you're watching this blog today (Saturday 22 Nov 03), please be sure to check back in tomorrow or later for the more refined blog entries. Thanks! -Graham
02:00
Eek. Should try to get some sleep.
04:00
Must... wake... up. Good thing the alarm clock is on the other side of the room.
0500-0700
Drove to Stanford from Davis. I LOVE MY NEW CAR. It's great. Cruise control is unbeatable. Encountered only three potential Darwin Award candidates - all once I got past the Benicia Bridge.
07:05
*yawn* Got here a few minutes early. Good. Sat and watched the squirrels while listening to my new CD. It's cold out!
08:30
Argh. My iBook's wireless card's hardware address apparently hasn't been put on the "OK" list for the Stanford wireless network, so I'm seeing a full signal and the advertised SSID but am getting no love from the DHCP server. Fortunately, another Mac is available for me to do my blogging. Thanks, Jennifer.
08:40
Made a disparaging comment about Windows. Oops. I wonder if I should be more careful about what I say, since I'm volunteering for the conference organizers and at least one Microsoft employee is here. Oh well. I meant my disparaging comment in the best possible way, of course.
08:50
Jennifer Granick gives her introductory speech, talking about the critical nature of computer and network systems and the subsequent importance of security.
Touched on relevant issues, including her own recent experiences:
* security vulnerabilities treated as trade secrets
* internal e-mails showing security vulnerabilities in voting systems treated as copyright cases
[Graham: HOORAY for Jennifer Granick, the Stanford CIS Cyberlaw Clinic, and the Online Policy Group! Go, OPG, go!]
* individuals prosecuted and imprisoned for disclosing security vulnerabilities
"Full disclosure" folks argue that disclosing vulnerabilities assists everyone in patching same and facilitating effective risk management. The other side argues that such information out in the open allows wrongdoers to do wrong things.
Areas of agreement:
* Responsible disclosure helps security more than it harms it.
Areas of disagreement:
* Who makes that calculation, and what factors are considered?
* What are the long- and short-term costs? Are they worth it?
0900
Panel: Tiina Havana from Oulu University in Finland, David Litchfield from NGS Software (has published proof-of-concept code used in Slammer worm), Gerhaard Eschelbeck from Qualys (database of security information - expound)
Ms. Havana:
Talked about political aspects of security and disclosure. "[Can] we manage to get the process such that there is no need for public (regulation?)" When policy is formed, policymakers should pay careful attention to relevance and whether to be proactive or reactive. (paraphrased)
Communication about security discoveries can be very complex and therefore potentially porous. Organizational policy should address these issues.
Talked about image, identity, and reputation. Important to differentiate between the three.
Spoke about timing of information release strategy.
Mr. Litchfield:
* When a new class of security vulnerability was discovered and publicly disclosed, a number of open-source software packages which were vulnerable to this type of vulnerability were patched virtually overnight.
* Security vulnerability disclosure guidelines have been published, but many researchers and vendors do not actually adhere to said guidelines even while claiming that they are part of organizational policy. Important to stick to those guidelines, not only for obvious reasons but also because doing so will help others do the same. For example, researchers should adhere to their word if they claim they will allow the vendor two weeks to fix a vulnerability before going public. Similarly, vendors should adhere to their word if they claim that they will promptly and effectively resolve a vulnerability in a specific period of time.
Mr. Eschelbeck:
According to his research, many many vulnerabilities exist unpatched for extended periods of time.
"For a critical vulnerability, the number of vulnerable systems is reduced by 50% every 30 days."
While many people do indeed patch and patch correctly, it's clear that vulnerabilities are not being completely eradicated.
Do not need to worry in a broad sense about 10,000 vulnerabilities - it is only 10 or 15 high-profile vulnerabilities that cause all the trouble.
Coordinated response and disclosure was very effective in fighting earlier Microsoft RPC vulnerabilities.
Discussion:
Ms. Granick asked if the threat of disclosure has an effect on the speed and availability of patches. Mr. Litchfield says, in essence, yes. Points out that vendors do have difficult decisions to make when, for example, fixing this vulnerability would break other features. JG: Isn't it fictional that only vendors and researchers are aware of any given exploit/vulnerability? DL: It's mixed.
JG: Mr. Eschelbeck's data seem contradictory.
GE: Systems are constantly being modified, installed, reinstalled, which causes many vulnerabilities to reappear.
Audience member: Says that graph is comparing apples to oranges by comparing remote exploits with user exploits.
GE: Some uncertainty exists. Just because someone hasn't yet built an exploit doesn't mean that one isn't possible.
Audience member: What percentage of total number of vulnerabilities do you believe you're reporting? Obviously not all are reported.
GE: 20-25% goes unreported, while statistically [GE]'s data represent ~80% of vulnerabilities.
Audience:
GE: Only knows IP address, time, date - not necessarily operating system.
[Graham, silent: Huh? Netcraft knows OS. Nmap knows OS most of the time. How does his test/analysis work? Is that intentional, or a technological limit that I don't understand?]
Audience: If Mr. Litchfield only saved the Slammer author 20 minutes, why not release further proof-of-concept code?
DL: Because 20 minutes is still 20 minutes. Don't want to be a part of such things at all, if avoidable.
[Graham, silent: Pshaw. I don't agree with this. I guess I understand his reticence, since Slammer _was_ a really big deal, but I contributed a little bit to global warming by driving my '85 VW Vanagon around. By driving my van, I got motivated enough to learn about and install solar power and wireless networking in said van, which enabled me to serve on a UN Volunteers online advisory group talking about deploying wireless technology in developing countries. Mr. Litchfield's work contributes overall to improving security, even if once in a while it becomes used by Bad People to do Bad Things.]
Audience: Mr. Litchfield mentioned concerns about patches not working. If proof-of-concept code is not released, then how do we know how effective a patch is?
DL: If patches break production systems, obviously that's bad for everyone. Patches need to work every time - people should enjoy patching experience!
[laughter]
JG: Closing questions: What's the downside to waiting to announce a vulnerability until the patch is released? What if you're not a well-known security researcher - what do you do to be taken seriously if you've really discovered a problem? Should there be an enforcement mechanism to ensure disclosure policies are followed?