Review of the RSA Conference,
San Francisco, CA
February 14-18, 2005
Review by Jeremy Epstein
Senior Director, Product Security & Performance
March 3, 2005
This was my first time attending, and I expected to be unimpressed, as
I usually am at conferences that have lots of trade show / PR aspects.
To my surprise, there were a lot of good talks, as well as goodies on
the show floor.
The organizers claimed over 13,000 attendees, and it felt that way trying to
find a seat in some of the tracks, or find somewhere to sit down to talk to
Predominant technologies in the trade show were:
Authentication devices - 2 factor, challenge response, biometrics, etc.
Anti-spam software, appliances, services, etc.
Security assessment services, including for regulatory compliance
Fair amount of IDS & IPS, with less hype than in the past
Wireless crypto devices
Security testing via static and dynamic testing
I didn't see anything radically new and exciting on the show floor. I asked
several people I know what excited them the most, and heard "nothing much".
There's a lot more focus on getting confidence that systems are built
Everyone understands that web services have a lot of potential dangers,
but many users are ignoring them and moving forward with implementation
The security field is progressing very slowly, and keeps making the same
There's a lot of talk about the SHA-1 break, but it's not practical at
Bill Gates may be rich as Croesus, but he's also a mediocre speaker
Some of the highlights....
The cryptographers panel focused on predictions for the future, as well as
looking at prior predictions. Video clips showed previous predictions, and
the panelists were asked to comment on how their views had changed and what
they got right and wrong.
Passwords won't go away - the real reason IT wants to get rid of passwords
isn't security, but rather password sharing. For many applications,
passwords are good enough.
RFID tags are still coming. An interesting usage is in libraries to find
mis-filed books, which are effectively lost forever if not found.
Provable security isn't much closer than it was 12 years ago, when it was
predicted to be 10 years away.
Anonymous electronic money, which was predicted as a key technology for
the Internet 10 years ago, is never going anywhere; the real progress is in
online credit cards. [There was an article in the Washington Post about
small value transactions a few weeks ago. See
Fraud isn't as big a problem as was expected.
Hardware cryptanalysis may start getting interesting - the new multi-core
chips have the potential for allowing one thread to do cryptanalysis of what
another chip is doing, by watching the timing and processor state. This is
critical for Digital Rights Management (DRM).
There was a discussion of the new SHA-1 security break found by a group of
Chinese cryptographers who had been totally unknown until a year ago. Their
progress is really surprising, because they don't come out of any recognized
cryptographic community. They can find collisions in 2^69 tries rather than
2^80 as would be expected. It's not severe enough to change things, but
cause for caution. SHA-256, SHA-384, and SHA-512 will increase the work
factors enough to be safe for now.
Web services security
There were a number of presentations on web services hacking, mostly
pointing out that the same issues that apply in any other application apply
to web services. Just because something is behind the firewall doesn't mean
it's safe. There are SQL injection attacks, cross-site scripting, etc.,
plus a few unique ones such as recursive XML using DTDs to cause the XML
processor to (effectively) perform a DoS attack on itself. WSDL and UDDI
are great things that make web services useful, but they also give an
attacker lots of information about what an attack should look like. Some
companies are responding by keeping their WSDL proprietary (a security
through obscurity attack).
What was both enlightening and alarming is that the few actual customer
presentations on use of web services were just using SSL and
username/password authentication, with the assumption that trading partners
are entirely benign so they make minimal efforts to protect against attacks
once you're authenticated. The one bit of good news is that since every web
services installation is relatively unique (offering different web
services), an attacker will need to go after each web service individually
(as opposed to firewalls or operating systems, that are multiple instances
of the same thing).
Regulation for improved security
This debate has been covered pretty extensively in the media, so I'll
summarize it by noting that the breakdown was mostly Bruce Schneier and Dick
Clarke (arguing that government has to force more security) vs. Harris
Miller from ITAA & Rick White (who think the free market does fine and
regulation is inherently evil). A hot topic of debate was the Choicepoint
case (theft of credit information) which happened the day before. Schneier
pointed out that companies need to be actually responsible, not just give
lip service to security. Specifically, Choicepoint's customers aren't the
people whose information was stolen, but rather other companies - so
Choicepoint has little non-regulatory incentive to do a better job. He
recognizes that regulation *will* stifle innovation, but we need to make the
tradeoff for the good of society. His summary was "When we have
self-regulation, security becomes a PR issue". Dick Clarke also suggested
that disclosure might work as a substitute for regulation, just as Y2K
regulations forced companies to disclose, not to fix. Right now, accounting
companies are setting the security bar via SOX compliance - is that really
what we want?
Ten Bugs that Cost Our Customer Billions
There were several talks around static analysis, generally of source code.
There's been a fair amount of progress of commercial products (several of
which were exhibited on the show floor), although this field is in its
infancy as far as being practical. Most of the academic research is in
finding potential problems, which is making good progress. However, the
really critical parts are figuring out which of the potential problems are
actual vulnerabilities and need to be fixed vs. which can be safely ignored,
and then to tell the user what's wrong and how to fix it. It's also harder
than just analysis of a program because modern systems are built out of a
mish-mash of technologies in n-tier architectures that include C/C++, Java,
HTML, Perl, JSPs, etc., and the problems can be from a combination of pieces
that are individually "safe".
Ben Jun from Cryptography Research gave perhaps the most amusing talk. He
reviewed systemic problems that cost $100M+ each.
Bug #10: DVD CSS failure (trivially cracked) caused by bad crypto
selection (no reason to do any other types of attack, because the crypto
failure is so bad). Lesson learned: bad crypto is inexcusable
- Bug #9: Pachinko stored value fraud (Japanese electronic stored value
cards, easily duplicated/forged). Loss was $600M+ from fraudulent cards
exchanged for cash. Merchants were indemnified against fraudulent cards, so
they had no motivation to watch for fraud. Some indications that North
Korea was behind this. Regulators weren't technically savvy, and corporate
culture was not to report bad news. Lesson learned: even though fraud can't
be eliminated, it needs to be managed. Lesson learned: security field
should have equivalent of "morbidity and mortality" meetings in hospitals to
review what went wrong, without fear of lawsuits.
Bug #8: Y2K: This was not a security problem, but costs were huge. Testing
failed when products were originally built - should have had tests for date
rollovers. Lesson learned: try testing data fields more thoroughly.
Bug #7: Napster/P2P: Lesson learned: improved delivery mechanisms simplify
content attacks. Countermeasures include new systems that include code to
decode content, making the job of the attacker harder.
Bug #6: Spam: Email wasn't designed for a hostile environment. The
economic disparity, similar to telemarketers, where it costs the sender much
less than the receiver make spam hard to fix. Lesson learned:
Infrastructure retrofits are hard & expensive.
Bug #5: Mag stripe skimming: ATM card fronting/cloning is easy. Lesson
learned: Need to replace dumb cards with chip-based cards.
Bug #4: Pay TV hacking: The international boundary system (TV regions)
generates demand, because can't get programs from certain countries. As a
result, attackers are willing to spend $1M to duplicate/crack systems.
Lesson learned: don't need to make the system bulletproof, but need to make
Bug #3: The PC platform: Saltzer & Schroeder identified the principal of
least privilege in 1975, but their results are still largely ignored. Most
users run as administrator on Windows boxes, which makes them more
vulnerable to attack. We need firewalls inside computers, and use of all
the rings (not just kernel vs. application). Lesson learned: Don't sidestep
Bug #2: 802.11b (WEP): Lousy usage of crypto algorithms, no key management
resulted in corporate rollouts being delayed ~18 months. There are real
exploits, including database theft. Real threat is for non-PCs (i.e., PDAs,
watches). Lesson learned: Make it hard for users to make security mistakes;
get expert assistance.
Bug #1: The unknown bug: How do we fail less than we have in the past?
Learn from the Risk and Insurance Management Society.