New Year Rundown

I've been away from the blog for a bit lately, mostly because of work on a couple of projects that have not necessarily taken all my free time, but they've not lent themselves cleanly to a bloggable idea.

For security experts, there's no real news here. For developers, some of these tidbits may be of interest.

• There's a big debate about whether pen-testing is dead, dying, evolving, or thriving. If you really want my opinion on the matter, pen testing is no less important than it has ever been. However, I think that enterprises need to shift focus from picking their jaw up off the floor to seeing how they can actually correct the issues. Pen testing will always find flaws that no other form of testing can. And it can provide good "shock value". But pen testing doesn't solve problems. For those who have pen testers in the enterprise, they need to understand that the pen test is not the end game - more defensive applications are the goal. In fact, I don't think the focus-shift that's necessary reduces the need for pen-testing, but rather increases the need for good pen-testers with good documentation ability.
• Gary McGraw and Brian Chess did a superb job culling metrics from nine different enterprises to develop a maturity model for where enterprises are in their application security programs. As you've seen me say before, it's time for us to get the information that's in the security experts' hands and properly translate it to developers who are responsible for fixing findings. See the report here.
• Every so often I get to work on another scenario for clickjacking. It really, really scares me. Certainly, the victim audience would be somewhat smaller than the general XSRF audience, but to think that you can use clickjacking to work around XSRF protections (including CAPTCHA) is frightening. If you're in control of it, make sure your site has some framebusting code. And even that's not 100% effective. (Considering IE can force an iframe to load at a particular security zone).
• Regarding the MD5-collision-fake-CA attack demonstrated at 25C3: It's a very cool attack. And it completely negates the purpose of CA's - to validate the authenticity of a site. But who are the victims in a successful attack? The victims would be the people who are susceptible to phishing scams or DNS poisoning, but actually verify the authenticity of certificates. Sure, the browser will be fooled, but even without properly faking a CA, how many people who fall for phishing attacks don't click "Yes, I really want to do this foolish thing" when the browser warns them?
• Regarding twishing: nifty idea. I wish it were mine. You can actually see the day that people got twished by the sudden change in their posts that have URL's in them. So why is twishing more severe than making thousands of fake twitter accounts? There are two reasons: 1) Twitter promptly disables ID's it deems to be automated spam accounts. Normal user accounts that are suddenly used for sending spam will pass more heuristics for legitimate use, and 2) real people already follow (and trust) the real users who got twished.
• Attackers are continuing to use open redirects in Flash for new phishing attacks. Yes, just like Java applets or ActiveX controls, your Flash movies need to be analyzed for potential security flaws. Although there are lots of nifty attacks involving Flash, the simplest are still the most effective.

And...oh yeah! Happy New Year! It's a delightful time to be in the security industry, and a very good time to be a developer who understands defensive programming.