Checking In

I have been neglecting this blog a bit lately as I have been completely swamped with other things. But I did want to quickly promote a couple of local security events here in Chicago. This week is ChiSec 19. An informal gathering of a bunch of like minded security people. I am hoping to make it out Wednesday to experience this for myself. If you plan on going let me know. This weeks ChiSec is at the Hop Haus and details can be found here.

Also after all the hype that is Black Hat and DefCon settle down, the Chicago OWASP chapter will be having their quarterly meetup on August 21st. Rohyt Belani of phishme.com fame will be presenting on mixing spear phishing with application security vulnerabilities. Also, Jeremiah Grossman of all things web app security fame, will be giving his Black Hat presentation “Get Rich or Die Trying - Making Money on The Web, The Black Hat Way”. This event will definitely be worth attending and a great chance to meet a lot of people dealing with these types of issues every day. All the details on the OWASP meetup including RSVP contacts can be found here. Oh yeah, and both of these events are of course FREE.

Hope you can make it out to these events if you’re in town. Mention this post, and your first drink is on me.

Introducing SPSP

I was recently invited to participate on the advisory board for the Society of Payment Security Professionals which I happily accepted. The site explains the society best:

“The Society of Payment Security Professionals’ objective is to provide individuals and organizations involved in payment security with an online community to share information and access education and certification opportunities. Society members come from a variety of businesses including card brands, merchants, acquirers, issuers, ISOs, and more.  Though their organizations may vary, they all share one purpose:  to protect consumer data using the most current, viable technologies and processes.”

They also offer a certification, Certified Payment-Card Industry Security Manager (CPISM). Mike Dahn writes about the SPSP as well the certification on his blog here, here, and here.

We are now in the process of forming a working group on application security. If you have expertise on the topic and are interested in participating you can send me an email or leave a comment here. We’re open to any and all comers. It should be noted this is NOT about PCI but rather payment security in it’s entirety.

Looking forward to my new role on the AB as well as working with the Application Security Working Group.

Your Next Magazine Subscription

Should be [IN]SECURE magazine. And best of all it’s free and online. This has quickly become one of my favorite regular reads.The new issue (Issue 17) is out and you can get it here.

Officially Unofficially endorsed by ClearText (what a ringing endorsement!). Check it out and let me know what you think.

OpenID SSO Everywhere!

UPDATE: In TechCrunch this morning there’s a post about Microsoft accepting OpenID for their HealthVault beta. They note that Microsoft is only utilizing 2 OpenID providers, TrustBearer and Verisign for authentication. The reason, of course, is security.

Healthvault is obviously a product that will store highly sensitive information and will likely be regulated in some ways. This simply reaffirms my concerns in this post from February. As a relying party of OpenID, you do not have the insight in to what security measures are taken into account for authentication. Microsoft had to perform their own due diligence and then make a manual determination on which providers they would rely on.

Simon Willison says this is a good thing in his latest blog post here. While I somewhat agree, I think the adoption of OpenID would become greater if there was a more programmatic approach to this. As a relying party, I would not want to perform due diligence on every provider out there and then limit my users based on a point-in-time review. Read more below regarding my earlier thoughts this year on meta data. Could it be that my crystal ball is actually working?

Original Post ( 2/14/2008 ) Begins Here: Over the past few weeks OpenID has gained a lot of support and momentum from some very big sites. Last week the OpenID Foundation added Google, Microsoft, IBM, Verisign, and Yahoo! to its corporate board. A number of sites have come out supporting OpenID, mainly as identity providers. While it’s clear OpenID is getting a lot more support and use across the net, I would like to see more web applications ACCEPTING (relying party) OpenID. It seems much like the plethora of social sites cropping up on the web, everyone wants to be an identity provider and own the identity and profile data of the user.

So I’ve been meaning to dig deeper into OpenID for several months and write about my findings, but as usual my life had other priorities. After finally getting around to it, I must say I’m fairly impressed. Simon Willison has a great slidecast of his presentation last year at the Future Of Web Apps here. There were a number of ideas presented on various uses of OpenID that had not even crossed my mind. For those of you thinking OpenID = SSO (like the title of this entry), it’s so much more than that. I highly encourage you to watch the presentation.

That said, there are a few issues with OpenID. Some of them discussed by Simon at the end of his presentation.One that was not discussed that still bothers me is the lack of meta data about OpenID identity providers. One enhancement that I believe would really expand the use of OpenID across the web would be meta data associated with the identity provider. Right now, as a site that accepts OpenID, I have no ability to understand the authentication rules the user had to abide by with it’s identity provider.  While you may say, that’s up to the user to decide (and you’d be right, mostly), if I require a certain level of security for my web application for whatever reason, I would like to understand what rules the id provider made the user play by. Perhaps I am regulated on how my users authenticate to my application, this shouldn’t necessarily preclude me from accepting OpenID (it would today). If OpenID providers published meta data on the authentication rules, a site could then choose whether or not to accept the OpenID for authentication. Perhaps there could even be various security levels for OpenID providers (just thinking out loud). I could see an ecommerce site that stored additional sensitive information within a user profile to require a certain level of authentication rules from OpenID providers. Financial, trading, and tax sites would require even tighter rules.Right now the competition of the OpenID provider market should help. Users given a number of choices for providers can choose one that protects the user against phishing etc. (although given a choice, a user may choose a provider with less complex authentication rules).

Overall, OpenID is a really good idea, but I think it requires a few enhancements to expand its use beyond the social and email sites that seem to make up the majority of its use today. What do you think? Are you using OpenID today? I’d love to hear your thoughts in the comments section of this blog (which also acts as one of my OpenID’s, by the way) or send me an emal.

White List vs. Black List

Jeremiah Grossman posted an entry on his blog yesterday about why most WAF’s are not currently implemented in blocking mode. To steal from Jeremiah who borrows from Dan Geer,

“When you know nothing, permit-all is the only option. When you know something, default-permit is what you can and should do. When you know everything, default-deny becomes possible, and only then.”

I think both Jeremiah and Dr. Dan are right on with their analysis. In fact, I would take this a step further and say this is ultimately how developers end up deciding whether to use a black list or white list approach when doing things like input validation. If you cannot fully document and articulate EVERYTHING about your site(s), it becomes impossible to create a valid whitelist. While knowing and understanding the majority of your site allows you to create a fairly effective black list, and of course, if you know nothing about your site you must allow all and pray.

To read a much more in-depth explanation of how this plays out in security, check out Dr. Dan Geer’s book. He delves into one of this blog’s favorite topics, the economics of information security and the trade-offs associated with it. Happy Reading!

Front Range OWASP Conference

Quick reminder that registration is now open for the Front Range OWASP conference in Denver and it’s free. Conference page here. Register here.

Serving the Twits

A quick warning: this post is a bit off topic and not directly related to the usual security content of this blog.

It seems Twitter is being used more and more as a customer service and brand monitoring tool for a variety of companies big and not-so-big. A few weeks ago, Chris Hoff twittered his painful experience with Southwest Airlines and bad weather in the north east. Low and behold, he received a very personalized tweet back from SWA apologizing for his rough travels and an additional follow-up tweet upon his return.

Yesterday, Mark Hendrickson on TechCrunch wrote about a company, Get Satisfaction, that is performing brand monitoring and customer service within the Twittersphere for companies such as Comcast. I am not sure how personal the service is, it was clear the tweets from SWA were not a bot but an actual person.

A few days ago I was experiencing a lot of browser crashing with the new FireFox RC1 release. Amidst my frustration I had twittered about the issue and, low and behold, I received a tweet back from @firefox_answers with some helpful debugging suggestions that actually solved my problem.

There has been a lot of talk lately about Twitter’s issues with uptime as well as a great debate yesterday about it: See twitout versus twitter love. It’s likely they will get these issues resolved, especially with the rumors going around this week of their additional round of funding. If done well, this could be a great channel for customer service and brand loyalty. Of course, if done wrong, it could come across as creepy and big-brotherish.

Now back to Security.

My New Browser!

OK, well not quite, I’m going to need an OS X version before I fully switch… but this is REALLY good to see.

Some CS researchers (Chris Grier, Shuo Tang, and Samuel T. King) at the University of Illinois have designed a new browser from the ground up with security in mind. While the new versions of Firefox and IE are beginning to build more security on top of their existing software, they are fundamentally flawed. There is so much tied together with the existing browsers that the trust model is broken.

The number of threats that are at least partially due to how the internet browsers are built is getting ridiculous. Whether it is trust issues with plug-ins like Flash and RealPlayer, or domain policy issues that lead to cross site scripting, the number of these vulnerabilities and exploits are piling up. The mere fact that malware can be downloaded, installed and started simply by opening a web page with a browser is a great indication that the situation is completely out of hand. According to the paper, there were 205 reported security vulnerabilities within the major browsers and an additional 301 security vulnerabilities within various browser plug-ins within the past year. The current browsers, for all intents and purposes, are broken.

The OP web browser partitions itself into subsystems and enforces security policies within the small kernel. This is very much how operating systems are designed, which means that even if a plug-in is compromised, the browser is not. To quote the abstract:

“To show the utility of our browser architecture, we design and
implement three novel security features. First, we develop novel
and flexible security policies that allows us to include plugins
within our security framework. Our policy removes the burden
of security from plugin writers, and gives plugins the flexibility
to use innovative network architectures to deliver content while
still maintaining the confidentiality and integrity of our browser,
even if attackers compromise the plugin. Second, we use formal
methods to prove that the address bar displayed within our
browser user interface always shows the correct address for the
current web page. Third, we design and implement a browser-
level information-flow tracking system to enable post-mortem
analysis of browser-based attacks. If an attacker is able to
compromise our browser, we highlight the subset of total activity
that is causally related to the attack, thus allowing users and
system administrators to determine easily which web site lead to
the compromise and to assess the damage of a successful attack.”

The OP browser currently runs on Linux with KHTML as the layout engine. They plan to create a cross-platform Webkit version and release it to the open-source community. Perhaps Mozilla could help out with this project .

Go read the paper and let me know what you think.

Two Places You Need To Be

Register for both now. Hope to see you soon.

1. The Front Range OWASP Conference
2. The Workshop on the Economics of Information Security - 2008

Rocky Mountain High

I have signed up with the OWASP Denver and Boulder chapters to give the opening keynote at the Front Range Web Application Security Summit in June. This is turning into a great event. A lot of excellent speakers are going to be there including Robert Hansen (RSnake) and Mike Zusman.

I am honored to be included in such company and am very much looking forward to it. Watch the site for more updates as I hear rumblings of participation from some additional great web app sec speakers. If you find yourself in Denver on June 10th, definitely try and attend this one.

UPDATE: Jeremiah Grossman from Whitehat Security will be presenting on business logic flaws.