Recommendations for trustmark providers

I've been slow in responding to Pete Lindstrom's (Spire Security) prompt for recommendations and solutions for trustmark (security badge) providers, beyond my typical griping about same.
I appreciate Pete's candor and perspective, and shall endeavor to make amends.
Having repetitively taken issue with trustmarks, with McAfee Secure\Hackersafe facing the brunt of it, I propose the following to ALL trustmark providers, as I did during the creation of the McAfee Secure Standard.

1) Check the arrogance and sales hype at the door.
We have no doubt that you're in business to drive conversions first and security second, so just be honest about it.
We also have no doubt that there will be vulnerabilities in your customer's sites, so cut out the "we guarantee their security" angle and opt for the "we do the best we can to contribute to the security and well being of our customers, and their customers" approach.

2) Practice transparency.
How do you scan (very specifically)? If you simply run Nessus, say so. If you make use of custom algorithms and signatures, say so.

3) Publish your standard, most importantly inclusive of your intentions on how to enforce it.
If a customer's site is not compliant, how and when, if at all, will you pull down the trustmark badge?
I can't believe I'm about to say this but McAfee Secure really has set the standard for establishing a standard. While I believe it to be lacking in areas, at least they have one.

4) Actually enforce.
So often I've found websites in flagrant violation of any feasible security standards, and yet they display a trustmark. This simply should not be. It is misleading, dishonest, and deceptive.

5) Offer resources.
As an alleged security provider, offer your customers resources. Not just the "use SSL and all is well" bunk. Real resources: OWASP, SANS Top 25, SDL, how-to, the list goes on.

6) Provide an immediately evident point of contact for your trustmark program; an abuse@, security@, and/or info@ alias to which we can report sites we determine to be vulnerable.
I have found it difficult in the past to disclose vulnerabilities; it shouldn't be.

7) Offer incentives.
People often do well with incentive. A reward system for strong security practices demonstrated by your customers will reap benefits, and adversely, so too will a punishment system for non-performers.

Note: Keep a close eye on Skeptikal.org. Mike's of the same mindset, and has applied this spirit of thinking to PCI ASVs who themselves have missed the mark on security, while holding others to the embattled PCI DSS. Look for some interesting content next week.

Finally, dear trustmark provider, think integrity. Operating from that position should lead you down the right path.

del.icio.us | digg | Submit to Slashdot

Congratulations to the Open Security Foundation

I was thrilled when I read that the Open Security Foundation (OSF) was named as SC Magazine's 2009 Editor's Choice Award recipient.
I simply can't think of a more deserving bunch.
Congratulations and well done!
OSF is the parent organization for the OSVDB and the DataLossDB.
Their accolades reminded me that OSF is a a 501(c)3 nonprofit, public foundation and as such, benefits from donations. I've been a Network for Good user for a year or so, and it occurred to me that I'd rather have donations made to OSF via my badge than any other organization.
People occasionally try to pay me for helping them out via Holisticinfosec.org; I tell them I'm paid well enough at my day job and writing gigs, and that they should instead donate to my preferred organization.
OSF is that preferred organization, please donate via my badge or straight through OSVDB, if so motivated. I just did; I'd be honored if you'd do the same.
Again, congratulations OSF!

del.icio.us | digg | Submit to Slashdot

Cloud security commentary falling down on the job

This one made me quite angry in February, but I chose to let it go, with the exception of posting a comment.
Then, recently, I stumbled across it again on Network World and PCWorld and, given that they've taken to regurgitating such inanity, I simply couldn't pass it by again.
Here's the crux of it.
At IDC's Cloud Computing Forum, much mention was made of how much security concerns in the cloud are overblown.
Really?
Brilliant commentary such as follows seemed to be in abundance:
"I think a lot of security objections to the cloud are emotional in nature, it's reflexive," said Joseph Tobolski, director for cloud computing at Accenture. "Some people create a list of requirements for security in the cloud that they don't even have for their own data center."
Yes, Joseph, but here's a secret for you. In their data center at least they can be responsible for security flaws and mitigate accordingly. In the cloud they depend on someone else to address security problems, and if that provider is slow to respond, who knows what mayhem may ensue.
Data breach anyone? Loss of customer confidence?
Yeah, go ahead and blindly trust your reputation to the cloud, complete with everyone at the IDC forum singing its praises and throwing all the key buzzwords around.
It'll be OK...good luck with with that.
Statements from Accenture such as "security objections to the cloud are emotional in nature, it's reflexive" leave me shaking my head in wonder.
Seems like Accenture is really falling down on the job here.
Wait, they really are falling down on the job here. ;-)
This Accenture swf should only load whitelisted, known good Accenture Flash video files.
But it doesn't. It loads any FLV you like, such as this one.
As I said, falling down on the job. ;-)
So, before consuming the wisdom Accenture seems to be throwing about so freely, perhaps suggest that they pay attention to their own security before telling us that cloud security fears are overblown.

del.icio.us | digg | Submit to Slashdot

So long Zango, thanks for all the phish

Oh, the joy...trumpets on high, banners waving in the wind!
Zango has been declared dead.
Good riddance, bugger off, may the fleas of a thousand camels infest your...well, you get the point.
As I've been heckling Zango for years, it gives my real pleasure to fire a parting shot. Or two, perhaps three.
Zango, this is for you.
The rest, dear reader, are for your viewing pleasure.
You'll recall that Hotbar is a Zango "product"?

Enjoy...

Props to John Leyden of El Reg for the best title of the day, via a tidy IFRAME.
http://tinyurl.com/c22sxn

An end to SPAM, thanks to Zango and Hotbar...really, I mean it.
http://tinyurl.com/cxhm79

A nod to Maestro Grossman's excellent book via manipulated Hotbar Flash.
http://tinyurl.com/cg7uke

To quote the mighty Marcus Fenix, "Sucks to be them."

Cheers.

del.icio.us | digg | Submit to Slashdot

The IT Infrastructure Threat Modeling Guide

After reading a toolsmith article I'd written on PTA: Practical Threat Analysis, Frank Simorjay, a local ISSA chapter member, friend, and co-worker reached out to a peer team in the Microsoft Solutions Accelerators (SA) group and suggested the prospect of something similar to be added to the SA roster.
After meeting with the SA Security & Compliance team, and a couple months of excellent collaborative effort with the likes of SDL expert Adam Shostack, group PM Kelly Hengesteg, editor Steve Wacker, and contributor Jeff Sigman, I authored the IT Infrastructure Threat Modeling Guide, now released in beta on the Connect site.
Sign up for the beta program here, then bookmark this.

Threat modeling has been well applied during the software development process, but there has been a noteworthy, Internet-wide lack of documentation and guidance with regard to applying threat modeling methodology to infrastructure. While many people and organizations threat model infrastructure in some form or fashion, we believed it was time to create a unified process that anyone from a small, one person IT shop, to a major enterprise could follow, and thus improve their security posture.

The IT Infrastructure Threat Modeling Guide provides an easy-to-understand method that enables you to develop threat models for your environments and prioritize your investments in IT infrastructure security. This guide describes and considers the existing Microsoft Software Development Lifecycle (SDL) threat modeling process and uses it to establish a threat modeling process for IT infrastructure.

Please feel free to give it a close look and submit feedback, we really do welcome it.

It is the intent and hope of this guidance that the benefits of choosing to develop a threat model for your IT infrastructure will be many, and that a holistic state of security becomes commonplace for those who undertake the process.

del.icio.us | digg | Submit to Slashdot

Online finance flaw: Recession humor at Citibank's expense

It should come as no surprise that Citibank would turn up in the Online Finance Flaws series.
Given their active role as root cause participant in our current economic downturn, Citibank has managed to invoke the ire of more than one critic.
The lesson I'll offer here is a simple one, unrelated to economics.
If you outsource development, and fail to manage the process, including the security development lifecycle (SDL), or lack thereof, you put your enterprise at risk.
I admit I am assuming outsourcing in this scenario, but I believe given that the vulnerability was found in a Citibank Hungary offering, I don't think I'm off the mark.
Citibank ignored me entirely so I decided to pass the findings off to the Microsoft Vulnerability Research (MSVR) program and see if the team could make contact with the right folks. The MSVR program is both very young, and in a current state of transition, but they obviously had success as the following vulnerability has been repaired. Hopefully I'll be able to provide more detail on this program in the future.
Citibank Hungary suffered from a cross-site scripting (XSS) vulnerability at the from variable as submitted to the form.jsp script.

It afforded me ample opportunity to inject a little humor (pun intended).
Here's the video if you'd like the long version; please note all the "security" references I capture prior to finding the site to be in complete contradiction to those references.

The following screen shot captures the essence of the message.



Here's the string resulting in the above screen shot, to give you injection context.



All security implications apply here: phishing, PCI, damage to brand and reputation, risk to consumers, etc.
That said, it appear that just a few of the kabillions of bailout dollars bestowed upon Citibank might have gone to a web application protection mechanism applied globally to all Citibank sites.
I'd love to say it came on the heels of this vulnerability being disclosed to them, but alas, I'll likely never know.
As I poked about to see what sort of results the old vulnerabilities generated, as well as poking for any other lapses, I universally received this URL.
It shows a 404, but the implications are something WAF-like is nailing common Javascript strings, given that the URL declares /domain/spoof/intercept.
Makes me feel good to see my tax dollars hard at work. ;-)

Cheers.

del.icio.us | digg | Submit to Slashdot

A follow-up on SaaS & cloud risk

When I recently discussed SaaS & cloud risk, with particular regard to Baynote, it received some attention, both positive and negative.
Having made Dr. Deviant's list for “stating the bleedin’ obvious” ;-), I must say it's hard to disparage the man's view.
Yet, there is a key point that eludes those detractors of my view that SaaS and the cloud present enhanced risk.
Yes, lots of software, operating systems, browsers, wikis, yada yada yada, ad infinitum, exhibit flaws and put users at risk of compromise. But most often, those resources at risk are also under those user's near or immediate control.
Not so of SaaS or cloud offerings.
When you commit your enterprise to the cloud, you yield control, plain and simple.
To which I can only offer, ask the right questions before doing so.
A recent comment on the heels of El Reg's coverage of the Baynote flaw discussion was written as if from my own keyboard (I assure you it wasn't), and I will use it to close, with my compliments to Raife Edwards:
The difference is that... IF... you own, and run, your own servers, or systems/software... AND, a "common vulnerability" exists, and is exploited... You MAY be vulnerable... you MAY have a security issue... you MAY be targeted... you MAY not have adequately protected your system... you MAY be hit by the problem... you MAY have issues, and losses... possibly.
If, however, you are dependent upon any, EXTERNAL, single point-of-attack/vulnerable-point... then you WILL be hit... you WILL be affected... you WILL have losses... and you WILL be totally-dependent upon EXTERNAL-interests in "fixing", and recovering... based upon THEIR competence, and on THEIR time-table... and, to suit THEIR perception of THEIR interests.
In other words, ALL YOUR EGGS in [SOMEONE ELSES] basket.

Precisely.

del.icio.us | digg | Submit to Slashdot

Tamper Data: CSRF examined

I've been picking on web applications with CSRF vulnerabilities a great deal lately, and in so doing thought it timely to discuss one of my favorite tools for the task in a toolsmith article.
Tamper Data: CSRF Examined explores Adam Judson’s Tamper Data, the Firefox add-on, as one of the best tools for sniffing out CSRF holes. It allows you to quickly note the absence of token/formkey use, and uncover variables useful in crafting scripts to present vendors and vulnerability clearinghouses with proofs of concept.
Jeremiah Grossman referred to CSRF as the sleeping giant years ago but apparently no one's listened. ;-)
I can tell you, my research indicates that it remains a prevailing flaw. It's also difficult vulnerability to scan for, so most PCI ASVs miss it completely. If you have doubts about CSRF holes and PCI compliance (see PCI DSS 1.2 6.5.5) you need only read Mike Bailey's perspective over at skeptikal.org where he discussed the issue in cPanel almost a year ago and has since exposed the issue in Zen Cart, after a discussion we had regarding CSRF issues in osCommerce.
The following are all CSRF (and other vulnerabilities) discovered with Tamper Data, and disclosed via advisories employing responsible disclosure practices.
HIO-2008-1005 CompactCMS 1.1 XSS & CSRF
HIO-2008-1022-1 RateMe 1.3.3 XSS & CSRF
HIO-2009-0128 osCommerce CSRF
HIO-2009-0305 e107 Multiple e107_admin CSRF & XSS Vulnerabilities
HIO-2009-0308 dotProject 2.1.2 CSRF & multiple XSS
I also have many more similar vulnerabilities waiting in the pipeline for vendor repairs.

If you don't use it already, may I suggest installing Tamper Data at your earliest convenience?

del.icio.us | digg | Submit to Slashdot